Closed Bug 979109 Opened 11 years ago Closed 11 years ago

out-of-bounds read in mozilla::dom::Console::ProcessArguments

Categories

(Core :: DOM: Core & HTML, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla30
Tracking Status
firefox29 --- unaffected
firefox30 + verified
firefox-esr24 --- unaffected

People

(Reporter: inferno, Assigned: baku)

References

Details

(Keywords: csectype-bounds, regression, sec-low)

Attachments

(2 files, 1 obsolete file)

Attached file Testcase (deleted) —
==11385==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6140003569c4 at pc 0x7ff548705ac2 bp 0x7ffff6495d50 sp 0x7ffff6495d48 READ of size 2 at 0x6140003569c4 thread T0 #0 0x7ff548705ac1 in operator* objdir-ff-asan/dom/base/../../dist/include/nsStringIterator.h:77 #1 0x7ff548705ac1 in mozilla::dom::Console::ProcessArguments(JSContext*, nsTArray<JS::Heap<JS::Value> > const&, mozilla::dom::Sequence<JS::Value>&) dom/base/Console.cpp:1086 #2 0x7ff548701763 in mozilla::dom::Console::ProcessCallData(mozilla::dom::ConsoleCallData*) dom/base/Console.cpp:972 #3 0x7ff548700f1e in mozilla::dom::Console::Notify(nsITimer*) dom/base/Console.cpp:917 #4 0x7ff54542c402 in nsTimerImpl::Fire() xpcom/threads/nsTimerImpl.cpp:554 #5 0x7ff54542ca9b in nsTimerEvent::Run() xpcom/threads/nsTimerImpl.cpp:635 #6 0x7ff545423b63 in nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp:643 #7 0x7ff5452f88aa in NS_ProcessNextEvent(nsIThread*, bool) xpcom/glue/nsThreadUtils.cpp:263 #8 0x7ff545b9df09 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp:95 #9 0x7ff545b47e80 in RunInternal ipc/chromium/src/base/message_loop.cc:226 #10 0x7ff545b47e80 in RunHandler ipc/chromium/src/base/message_loop.cc:219 #11 0x7ff545b47e80 in MessageLoop::Run() ipc/chromium/src/base/message_loop.cc:193 #12 0x7ff54827e802 in nsBaseAppShell::Run() widget/xpwidgets/nsBaseAppShell.cpp:164 #13 0x7ff54af46d23 in nsAppStartup::Run() toolkit/components/startup/nsAppStartup.cpp:276 #14 0x7ff54adbf25e in XREMain::XRE_mainRun() toolkit/xre/nsAppRunner.cpp:4006 #15 0x7ff54adc00b8 in XREMain::XRE_main(int, char**, nsXREAppData const*) toolkit/xre/nsAppRunner.cpp:4073 #16 0x7ff54adc10cd in XRE_main toolkit/xre/nsAppRunner.cpp:4283 #17 0x48b8c7 in do_main browser/app/nsBrowserApp.cpp:282 #18 0x48b8c7 in main browser/app/nsBrowserApp.cpp:643 #19 0x7ff55367076c in __libc_start_main /build/buildd/eglibc-2.15/csu/libc-start.c:226 #20 0x48ad9c in _start 0x6140003569c4 is located 0 bytes to the right of 324-byte region [0x614000356880,0x6140003569c4) allocated by thread T0 here: #0 0x472f61 in malloc _asan_rtl_ #1 0x7ff54c2ba77d in js_malloc objdir-ff-asan/js/src/../../dist/include/js/Utility.h:134 #2 0x7ff54c2ba77d in malloc_ js/src/vm/MallocProvider.h:53 #3 0x7ff54c2ba77d in pod_malloc<char16_t> js/src/vm/MallocProvider.h:105 #4 0x7ff54c2ba77d in JSFlatString* js_NewStringCopyN<(js::AllowGC)0>(js::ExclusiveContext*, char16_t const*, unsigned long) js/src/jsstr.cpp:4006 SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 ?? Shadow bytes around the buggy address: 0x0c2880062ce0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c2880062cf0: 00 00 00 00 00 00 00 00 00 00 02 fa fa fa fa fa 0x0c2880062d00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2880062d10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c2880062d20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0c2880062d30: 00 00 00 00 00 00 00 00[04]fa fa fa fa fa fa fa 0x0c2880062d40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2880062d50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c2880062d60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c2880062d70: 00 00 00 00 00 00 00 00 00 00 00 00 fa fa fa fa 0x0c2880062d80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Contiguous container OOB:fc ASan internal: fe ==11385==ABORTING
Flags: needinfo?(amarchesini)
Blocks: 965860
Keywords: regression
Attached patch crash.patch (obsolete) (deleted) — Splinter Review
Attachment #8385181 - Flags: review?(bugs)
Flags: needinfo?(amarchesini)
Attached patch crash.patch (deleted) — Splinter Review
Attachment #8385257 - Flags: review?(bugs)
Attachment #8385181 - Attachment is obsolete: true
Attachment #8385181 - Flags: review?(bugs)
Assignee: nobody → amarchesini
Comment on attachment 8385257 [details] [diff] [review] crash.patch Could you test also %.123 and %. cases
Attachment #8385257 - Flags: review?(bugs) → review+
Status: NEW → RESOLVED
Closed: 11 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
Flags: sec-bounty?
Andrea: Not sure if this is your first security bug, but if it is I'd like to remind you that before landing security bugs we have a sec-approval process. In this case as a recent regression this fix did not require approval to land so no worries, I just couldn't tell if you'd seen it. https://wiki.mozilla.org/Security/Bug_Approval_Process How serious is this as a security bug? We still need to determine that in order to decide on any potential bug bounty award. I can see that we're overreading the string so there's the possibility of slurping random memory into the output. Can the web page get the console output back out? I don't know of a way so maybe there's not much chance of info leakage. What about the destination: does that buffer grow as required, or does this over-read pose a risk of over-WRITE on a too-small destination buffer
Flags: needinfo?(amarchesini)
The web page can't get the console log message back out. However, if this over-read reads random bytes that follow the string, the web page might be able to detect some characters that follow '%' bytes, by passing a bunch of object arguments to this method and seeing whether toString or valueOf is called on them...
Sorry Daniel for landing this bug before a sec-approval process. I think bz already answered to your question. I don't think we expose the risk of over-write the destination buffer.
Flags: needinfo?(amarchesini)
Unless Inferno has some tricks up his sleeve this appears non-exploitable (but if he has said tricks we'd be happy to pay a bounty to learn them).
Flags: sec-bounty? → sec-bounty-
Keywords: sec-low
Summary: Heap-buffer-overflow in mozilla::dom::Console::ProcessArguments → out-of-bounds read in mozilla::dom::Console::ProcessArguments
Confirmed crash in 2014-03-01, ASan Fx30. Verified fixed in 2014-04-17, ASan Fx30.
Status: RESOLVED → VERIFIED
Group: core-security
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: