Closed Bug 979109 Opened 6 years ago Closed 6 years ago

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

Categories

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

x86_64
Windows 7
defect
Not set

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
==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)
Attached patch crash.patch (obsolete) — Splinter Review
Attachment #8385181 - Flags: review?(bugs)
Flags: needinfo?(amarchesini)
Attached patch crash.patchSplinter 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+
landed on central -> https://hg.mozilla.org/mozilla-central/rev/cfe94189b993
Status: NEW → RESOLVED
Closed: 6 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.