Closed Bug 1445238 Opened 7 years ago Closed 2 years ago

IPC: BUS crash [@mozilla::ipc::Shmem::OpenExisting]

Categories

(Core :: IPC, defect, P3)

defect

Tracking

()

RESOLVED WONTFIX
Tracking Status
firefox61 --- affected

People

(Reporter: posidron, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: crash)

// static already_AddRefed<Shmem::SharedMemory> Shmem::OpenExisting(IHadBetterBeIPDLCodeCallingThis_OtherwiseIAmADoodyhead, const IPC::Message& aDescriptor, id_t* aId, bool /*unused*/) { size_t size; RefPtr<SharedMemory> segment = ReadSegment(aDescriptor, aId, &size, sizeof(uint32_t)); if (!segment) { return nullptr; } // this is the only validity check done in non-DEBUG builds * if (size != static_cast<size_t>(*PtrToSize(segment))) { return nullptr; } return segment.forget(); } [Faulty] Process type = 2 [Faulty] Fuzz probability = 20 [Faulty] Random seed = 396659296 [Faulty] Strategy: pickle = enabled [Faulty] Strategy: pipe = disabled [Faulty] Process: 2 | Size: 40 | ProcessLink::SendMessage => PContent::Msg_BackUpXResources [Faulty] pickle field {size_t} of value: 16384 changed to: 65535 ASAN:DEADLYSIGNAL ================================================================= ==6626==ERROR: AddressSanitizer: BUS on unknown address 0x7fbbe48f8ffc (pc 0x7fbc05d4a2cb bp 0x7ffcd3a49290 sp 0x7ffcd3a49140 T0) #0 0x7fbc05d4a2ca in mozilla::ipc::Shmem::OpenExisting(mozilla::ipc::Shmem::IHadBetterBeIPDLCodeCallingThis_OtherwiseIAmADoodyhead, IPC::Message const&, int*, bool) /home/posidron/dev/mozilla/mozilla-inbound/ipc/glue/Shmem.cpp:455:35 #1 0x7fbc05d49a60 in mozilla::ipc::IToplevelProtocol::ShmemCreated(IPC::Message const&) /home/posidron/dev/mozilla/mozilla-inbound/ipc/glue/ProtocolUtils.cpp:789:38 #2 0x7fbc06774f72 in mozilla::dom::PContentParent::OnMessageReceived(IPC::Message const&) /home/posidron/dev/mozilla/mozilla-inbound/obj/ff-asan-release/ipc/ipdl/PContentParent.cpp:7257:20 #3 0x7fbc05d38379 in mozilla::ipc::MessageChannel::DispatchAsyncMessage(IPC::Message const&) /home/posidron/dev/mozilla/mozilla-inbound/ipc/glue/MessageChannel.cpp:2133:25 #4 0x7fbc05d34c67 in mozilla::ipc::MessageChannel::DispatchMessage(IPC::Message&&) /home/posidron/dev/mozilla/mozilla-inbound/ipc/glue/MessageChannel.cpp:2063:17 #5 0x7fbc05d367f9 in mozilla::ipc::MessageChannel::RunMessage(mozilla::ipc::MessageChannel::MessageTask&) /home/posidron/dev/mozilla/mozilla-inbound/ipc/glue/MessageChannel.cpp:1909:5 #6 0x7fbc05d37148 in mozilla::ipc::MessageChannel::MessageTask::Run() /home/posidron/dev/mozilla/mozilla-inbound/ipc/glue/MessageChannel.cpp:1942:15 #7 0x7fbc04b37ad6 in nsThread::ProcessNextEvent(bool, bool*) /home/posidron/dev/mozilla/mozilla-inbound/xpcom/threads/nsThread.cpp:1040:14 #8 0x7fbc04b5e330 in NS_ProcessNextEvent(nsIThread*, bool) /home/posidron/dev/mozilla/mozilla-inbound/xpcom/threads/nsThreadUtils.cpp:517:10 #9 0x7fbc05d4091a in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) /home/posidron/dev/mozilla/mozilla-inbound/ipc/glue/MessagePump.cpp:97:21 #10 0x7fbc05bf9278 in RunInternal /home/posidron/dev/mozilla/mozilla-inbound/ipc/chromium/src/base/message_loop.cc:326:10 #11 0x7fbc05bf9278 in RunHandler /home/posidron/dev/mozilla/mozilla-inbound/ipc/chromium/src/base/message_loop.cc:319 #12 0x7fbc05bf9278 in MessageLoop::Run() /home/posidron/dev/mozilla/mozilla-inbound/ipc/chromium/src/base/message_loop.cc:299 #13 0x7fbc0d02f2fa in nsBaseAppShell::Run() /home/posidron/dev/mozilla/mozilla-inbound/widget/nsBaseAppShell.cpp:157:27 #14 0x7fbc11b1cd1b in nsAppStartup::Run() /home/posidron/dev/mozilla/mozilla-inbound/toolkit/components/startup/nsAppStartup.cpp:288:30 #15 0x7fbc11d5a762 in XREMain::XRE_mainRun() /home/posidron/dev/mozilla/mozilla-inbound/toolkit/xre/nsAppRunner.cpp:4679:22 #16 0x7fbc11d5d679 in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) /home/posidron/dev/mozilla/mozilla-inbound/toolkit/xre/nsAppRunner.cpp:4814:8 #17 0x7fbc11d5eac5 in XRE_main(int, char**, mozilla::BootstrapConfig const&) /home/posidron/dev/mozilla/mozilla-inbound/toolkit/xre/nsAppRunner.cpp:4906:21 #18 0x51bbd5 in do_main /home/posidron/dev/mozilla/mozilla-inbound/browser/app/nsBrowserApp.cpp:231:22 #19 0x51bbd5 in main /home/posidron/dev/mozilla/mozilla-inbound/browser/app/nsBrowserApp.cpp:304 #20 0x7fbc258521c0 in __libc_start_main /build/glibc-itYbWN/glibc-2.26/csu/../csu/libc-start.c:308 #21 0x424409 in _start (/home/posidron/dev/mozilla/mozilla-inbound/obj/ff-asan-release/dist/bin/firefox+0x424409) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: BUS /home/posidron/dev/mozilla/mozilla-inbound/ipc/glue/Shmem.cpp:455:35 in mozilla::ipc::Shmem::OpenExisting(mozilla::ipc::Shmem::IHadBetterBeIPDLCodeCallingThis_OtherwiseIAmADoodyhead, IPC::Message const&, int*, bool) ==6626==ABORTING [Child 6676, Chrome_ChildThread] WARNING: pipe error (27): Connection reset by peer: file /home/posidron/dev/mozilla/mozilla-inbound/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 353 ASAN:DEADLYSIGNAL
I think what happened here is that the child process sent a shared memory segment with an out-of-band length greater than the file's actual length; the parent process mapped the file with the provided (hostile, wrong) length, then accessed the end of the mapping to read an in-band length field. This wouldn't be an out-of-bounds access (it's inside the intended memory mapping), but it's past the end of the file and raises SIGBUS. On Unix we could detect this by fstat()ing the file and checking that against the provided length, but that wouldn't accomplish much in terms of security because the child process can hold a descriptor and race to change the file's size between time of check and time of use. (Also, this should just be a denial-of-service attack, and there are easier ways to do that.) But that kind of check might be useful in fuzzing mode to paper over these mismatches and continue fuzzing.
Priority: -- → P3
The following message with the name "SHMEM_CREATED_MESSAGE" caused the crash: $ hexdump -C /tmp/faulty/message.30330.845 00000000 18 00 00 00 ff ff ff 7f fb ff 00 00 03 00 00 00 |................| 00000010 00 00 00 00 ff ff ff ff ff ff ff ff 00 00 00 00 |................| 00000020 f8 e0 ff 6d 00 6a 18 d1 00 00 00 00 00 00 00 00 |...m.j..........| 00000030 01 00 00 00 00 00 00 00 |........| 00000038
QA Whiteboard: qa-not-actionable
Severity: major → S2

I don't think we're actively fuzzing shmem anymore, and this crash isn't exploitable, and only occurs if the process providing the shmem is hostile and creates a malicious shmem. There's not much we can do to avoid a situation like this, so I'm inclined to close it as incomplete. ni? decoder to see if this is still causing fuzzing issues.

Severity: S2 → S3
Flags: needinfo?(choller)

Not seeing this and considering it wontfix until it becomes a problem. If this ever happens to be one, we should consider adding checks for fuzzing like Jed suggested earlier.

Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(choller)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.