Last Comment Bug 857883 - (CVE-2013-1690) Crash with onreadystatechange and reload
(CVE-2013-1690)
: Crash with onreadystatechange and reload
Status: VERIFIED FIXED
[adv-main22+][adv-esr1707+]
: csectype-uaf, sec-critical, testcase
Product: Core
Classification: Components
Component: Document Navigation (show other bugs)
: unspecified
: x86_64 Windows 7
: -- normal (vote)
: mozilla24
Assigned To: Olli Pettay [:smaug] (high review load, please consider other reviewers)
:
Mentors:
Depends on:
Blocks: 901365
  Show dependency treegraph
 
Reported: 2013-04-03 18:53 PDT by Nils
Modified: 2014-11-19 19:47 PST (History)
27 users (show)
ryanvm: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
wontfix
+
wontfix
+
verified
+
verified
verified
22+
verified
22+
fixed
wontfix
affected
fixed


Attachments
testcase (requires an empty test.html) (548 bytes, text/plain)
2013-04-03 18:53 PDT, Nils
no flags Details
patch? (1.57 KB, patch)
2013-05-07 10:44 PDT, Olli Pettay [:smaug] (high review load, please consider other reviewers)
bzbarsky: review+
akeybl: approval‑mozilla‑aurora+
akeybl: approval‑mozilla‑beta+
lukasblakk+bugs: approval‑mozilla‑release-
akeybl: approval‑mozilla‑esr17+
akeybl: approval‑mozilla‑b2g18+
abillings: sec‑approval+
Details | Diff | Review

Description Nils 2013-04-03 18:53:23 PDT
Created attachment 733151 [details]
testcase (requires an empty test.html)

Crashes with the following stack trace when trying to execute unmapped memory. Testcase is attached, requires an empty test.html in the same directory. The testcase is very timing dependent, it works almost every time from a file://. I had it reproducing remotely a couple of times after quite a few reloads.

Stack on windows:
0x7099e938
xul!nsRefPtr<nsXULPrototypeDocument>::nsRefPtr<nsXULPrototypeDocument>(class nsRefPtr<nsXULPrototypeDocument> * aSmartPtr = 0x70472e30)+0xe
xul!nsDocumentViewer::Stop(void)+0x61
xul!nsDocShell::Stop(unsigned int aStopFlags = 3)+0x3f
xul!nsDocShell::InternalLoad(class nsIURI * aURI = 0x081f2500, class nsIURI * aReferrer = 0x00000000, class nsISupports * aOwner = 0x06267080, unsigned int aFlags = 0, wchar_t * aWindowTarget = 0x00000000 "", char * aTypeHint = 0x706cb730 "", class nsAString_internal * aFileName = 0x706d73b4, class nsIInputStream * aPostData = 0x00000000, class nsIInputStream * aHeadersData = 0x00000000, unsigned int aLoadType = 2, class nsISHEntry * aSHEntry = 0x0803e150, bool aFirstParty = true, class nsIDocShell ** aDocShell = 0x00000000, class nsIRequest ** aRequest = 0x00000000)+0x76b
xul!nsDocShell::LoadHistoryEntry(class nsISHEntry * aEntry = 0x0803e150, unsigned int aLoadType = 2)+0x290
xul!nsDocShell::Reload(unsigned int aReloadFlags = 0)+0xf6
xul!nsLocation::Reload(bool aForceget = false)+0x39
xul!NS_InvokeByIndex(class nsISupports * that = 0x0adb2940, unsigned int methodIndex = 0x14, unsigned int paramCount = 1, struct nsXPTCVariant * params = 0x0013d4c8)+0x27
xul!XPC_WN_CallMethod(struct JSContext * cx = 0x07ef8e00, unsigned int argc = 0, class JS::Value * vp = 0x04d900c8)+0x739
xul!xpc::WrapperFactory::Rewrap(struct JSContext * cx = <Memory access error>, class JSObject * existing = <Memory access error>, class JSObject * obj = <Memory access error>, class JSObject * wrappedProto = <Memory access error>, class JSObject * parent = <Memory access error>, unsigned int flags = <Memory access error>)+0x2f3
mozjs!JSCompartment::wrap(struct JSContext * cx = 0x00000000, class JS::MutableHandle<JS::Value> vp = class JS::MutableHandle<JS::Value>, class JS::Handle<JSObject *> existingArg = class JS::Handle<JSObject *>)+0x2cc
0x56eb5a0
0xffffff86
Comment 1 Olli Pettay [:smaug] (high review load, please consider other reviewers) 2013-04-06 04:04:52 PDT
Can't reproduce, but in debug build there is an (bogus-looking) assertion in contentsink.
Comment 2 Andrew McCreight [:mccr8] 2013-04-10 10:25:46 PDT
Well, trying to execute unmapped memory sounds bad, so I'm going to mark this sec-critical.
Comment 3 Daniel Veditz [:dveditz] 2013-04-11 13:15:53 PDT
Olli: I assume you weren't using windows? That might affect a lot of timings
Comment 4 David Bolter [:davidb] 2013-04-18 13:06:56 PDT
Mat agreed to try to reproduce. \o/
Comment 5 Matt Wobensmith [:mwobensmith][:matt:] 2013-04-18 14:20:53 PDT
ASan build on Mac for 2013-04-18 is not happy. :(


==85605== ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x000104a7ebb6 sp 0x7fff5fbde4b0 bp 0x7fff5fbde4d0 T0)
AddressSanitizer can not provide additional info.
    #0 0x104a7ebb5 in nsContentSink::DidBuildModelImpl(bool) (in XUL) + 565
    #1 0x1056efba8 in nsHtml5TreeOpExecutor::DidBuildModel(bool) (in XUL) + 328
    #2 0x10567ec96 in nsHtml5Parser::Terminate() (in XUL) + 326
    #3 0x10500458f in nsHTMLDocument::StopDocumentLoad() (in XUL) + 143
    #4 0x1044d9951 in nsDocumentViewer::Stop() (in XUL) + 241
    #5 0x105d59c7e in nsDocShell::Stop(unsigned int) (in XUL) + 382
    #6 0x105d5bba9 in nsDocShell::Destroy() (in XUL) + 1129
    #7 0x105d5c0ff in non-virtual thunk to nsDocShell::Destroy() (in XUL) + 15
    #8 0x104b78773 in nsFrameLoader::Finalize() (in XUL) + 211
    #9 0x104b16ef9 in nsDocument::MaybeInitializeFinalizeFrameLoaders() (in XUL) + 585
    #10 0x104b16c45 in nsDocument::EndUpdate(unsigned int) (in XUL) + 373
    #11 0x10500f97f in nsHTMLDocument::EndUpdate(unsigned int) (in XUL) + 79
    #12 0x10467e29f in mozAutoDocUpdate::~mozAutoDocUpdate() (in XUL) + 127
    #13 0x104bbd1b0 in nsINode::ReplaceOrInsertBefore(bool, nsINode*, nsINode*, mozilla::ErrorResult&) (in XUL) + 1424
    #14 0x106c2e779 in mozilla::dom::NodeBinding::appendChild(JSContext*, JS::Handle<JSObject*>, nsINode*, unsigned int, JS::Value*) (in XUL) + 649
    #15 0x106c27fdd in mozilla::dom::NodeBinding::genericMethod(JSContext*, unsigned int, JS::Value*) (in XUL) + 813
    #16 0x1081dba04 in js::InvokeKernel(JSContext*, JS::CallArgs, js::MaybeConstruct) (in XUL) + 820
    #17 0x1081cf01f in js::Interpret(JSContext*, js::StackFrame*, js::InterpMode, bool) (in XUL) + 79551
    #18 0x1081bb69d in js::RunScript(JSContext*, js::StackFrame*) (in XUL) + 1229
    #19 0x1081dbb63 in js::InvokeKernel(JSContext*, JS::CallArgs, js::MaybeConstruct) (in XUL) + 1171
    #20 0x10839ede1 in js::Invoke(JSContext*, js::InvokeArgsGuard&, js::MaybeConstruct) (in XUL) + 65
    #21 0x1081dca20 in js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value*, JS::Value*) (in XUL) + 1024
    #22 0x1082ae2f8 in js::DirectProxyHandler::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (in XUL) + 680
    #23 0x10844b979 in js::CrossCompartmentWrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (in XUL) + 873
    #24 0x1082c8364 in js::Proxy::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (in XUL) + 468
    #25 0x1082cebd6 in proxy_Call(JSContext*, unsigned int, JS::Value*) (in XUL) + 326
    #26 0x1081dbdee in js::InvokeKernel(JSContext*, JS::CallArgs, js::MaybeConstruct) (in XUL) + 1822
    #27 0x10839ede1 in js::Invoke(JSContext*, js::InvokeArgsGuard&, js::MaybeConstruct) (in XUL) + 65
    #28 0x1081dca20 in js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value*, JS::Value*) (in XUL) + 1024
    #29 0x10801e07b in JS_CallFunctionValue(JSContext*, JSObject*, JS::Value, unsigned int, JS::Value*, JS::Value*) (in XUL) + 651
    #30 0x106a58b1e in mozilla::dom::EventHandlerNonNull::Call(JSContext*, JSObject*, nsDOMEvent&, mozilla::ErrorResult&) (in XUL) + 510
    #31 0x105479bdc in JS::Value mozilla::dom::EventHandlerNonNull::Call<nsISupports*>(nsISupports* const&, nsDOMEvent&, mozilla::ErrorResult&, mozilla::dom::CallbackObject::ExceptionHandling) (in XUL) + 268
    #32 0x105478235 in nsJSEventListener::HandleEvent(nsIDOMEvent*) (in XUL) + 981
    #33 0x104d5ba52 in nsEventListenerManager::HandleEventSubType(nsListenerStruct*, mozilla::dom::CallbackObjectHolder<mozilla::dom::EventListener, nsIDOMEventListener> const&, nsIDOMEvent*, mozilla::dom::EventTarget*, nsCxPusher*) (in XUL) + 594
    #34 0x104d5bf35 in nsEventListenerManager::HandleEventInternal(nsPresContext*, nsEvent*, nsIDOMEvent**, mozilla::dom::EventTarget*, nsEventStatus*, nsCxPusher*) (in XUL) + 1093
    #35 0x104dafe8b in nsEventTargetChainItem::HandleEvent(nsEventChainPostVisitor&, bool, nsCxPusher*) (in XUL) + 523
    #36 0x104dacfae in nsEventTargetChainItem::HandleEventTargetChain(nsEventChainPostVisitor&, nsDispatchingCallback*, bool, nsCxPusher*) (in XUL) + 942
    #37 0x104dae662 in nsEventDispatcher::Dispatch(nsISupports*, nsPresContext*, nsEvent*, nsIDOMEvent*, nsEventStatus*, nsDispatchingCallback*, nsCOMArray<mozilla::dom::EventTarget>*) (in XUL) + 3922
    #38 0x104daee7d in nsEventDispatcher::DispatchDOMEvent(nsISupports*, nsEvent*, nsIDOMEvent*, nsPresContext*, nsEventStatus*) (in XUL) + 573
    #39 0x104bbb5f0 in nsINode::DispatchEvent(nsIDOMEvent*, bool*) (in XUL) + 352
    #40 0x104a9c250 in nsContentUtils::DispatchEvent(nsIDocument*, nsISupports*, nsAString_internal const&, bool, bool, bool, bool*) (in XUL) + 512
    #41 0x104a9c03d in nsContentUtils::DispatchTrustedEvent(nsIDocument*, nsISupports*, nsAString_internal const&, bool, bool, bool*) (in XUL) + 29
    #42 0x104dac4fe in nsAsyncDOMEvent::Run() (in XUL) + 798
    #43 0x104aa1443 in nsContentUtils::AddScriptRunner(nsIRunnable*) (in XUL) + 259
    #44 0x104b2e7c1 in nsDocument::SetReadyStateInternal(nsIDocument::ReadyState) (in XUL) + 513
    #45 0x104a7ea01 in nsContentSink::DidBuildModelImpl(bool) (in XUL) + 129
    #46 0x1056efba8 in nsHtml5TreeOpExecutor::DidBuildModel(bool) (in XUL) + 328
    #47 0x10567ec96 in nsHtml5Parser::Terminate() (in XUL) + 326
    #48 0x10500458f in nsHTMLDocument::StopDocumentLoad() (in XUL) + 143
    #49 0x1044d9951 in nsDocumentViewer::Stop() (in XUL) + 241
    #50 0x105d59c7e in nsDocShell::Stop(unsigned int) (in XUL) + 382
    #51 0x105d7995d in nsDocShell::InternalLoad(nsIURI*, nsIURI*, nsISupports*, unsigned int, unsigned short const*, char const*, nsAString_internal const&, nsIInputStream*, nsIInputStream*, unsigned int, nsISHEntry*, bool, nsIDocShell**, nsIRequest**) (in XUL) + 16557
    #52 0x105d82926 in nsDocShell::LoadHistoryEntry(nsISHEntry*, unsigned int) (in XUL) + 1734
    #53 0x105d5968b in nsDocShell::Reload(unsigned int) (in XUL) + 859
    #54 0x10532061b in nsLocation::Reload(bool) (in XUL) + 619
    #55 0x10705f3e6 in NS_InvokeByIndex (in XUL) + 870
    #56 0x105c33876 in XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) (in XUL) + 11094
    #57 0x105c46ef3 in XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) (in XUL) + 1107
    #58 0x1081dba04 in js::InvokeKernel(JSContext*, JS::CallArgs, js::MaybeConstruct) (in XUL) + 820
    #59 0x10839ede1 in js::Invoke(JSContext*, js::InvokeArgsGuard&, js::MaybeConstruct) (in XUL) + 65
    #60 0x1081dca20 in js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value*, JS::Value*) (in XUL) + 1024
    #61 0x1082ae2f8 in js::DirectProxyHandler::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (in XUL) + 680
    #62 0x10844b979 in js::CrossCompartmentWrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (in XUL) + 873
    #63 0x1082c8364 in js::Proxy::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (in XUL) + 468
    #64 0x1082cebd6 in proxy_Call(JSContext*, unsigned int, JS::Value*) (in XUL) + 326
    #65 0x1081dbdee in js::InvokeKernel(JSContext*, JS::CallArgs, js::MaybeConstruct) (in XUL) + 1822
    #66 0x1081cf01f in js::Interpret(JSContext*, js::StackFrame*, js::InterpMode, bool) (in XUL) + 79551
    #67 0x1081bb69d in js::RunScript(JSContext*, js::StackFrame*) (in XUL) + 1229
    #68 0x1081de880 in js::ExecuteKernel(JSContext*, JS::Handle<JSScript*>, JSObject&, JS::Value const&, js::ExecuteType, js::AbstractFramePtr, JS::Value*) (in XUL) + 752
    #69 0x1081dedba in js::Execute(JSContext*, JS::Handle<JSScript*>, JSObject&, JS::Value*) (in XUL) + 826
    #70 0x10801b742 in JS::Evaluate(JSContext*, JS::Handle<JSObject*>, JS::CompileOptions, unsigned short const*, unsigned long, JS::Value*) (in XUL) + 1442
    #71 0x10526e65a in nsJSContext::EvaluateString(nsAString_internal const&, JSObject&, JS::CompileOptions&, bool, JS::Value*) (in XUL) + 2042
    #72 0x1052dce19 in nsGlobalWindow::RunTimeoutHandler(nsTimeout*, nsIScriptContext*) (in XUL) + 1641
    #73 0x1052ca631 in nsGlobalWindow::RunTimeout(nsTimeout*) (in XUL) + 1857
    #74 0x1052dc548 in nsGlobalWindow::TimerCallback(nsITimer*, void*) (in XUL) + 152
    #75 0x107029cfe in nsTimerImpl::Fire() (in XUL) + 2142
    #76 0x10702a4c6 in nsTimerEvent::Run() (in XUL) + 486
    #77 0x10701d16b in nsThread::ProcessNextEvent(bool, bool*) (in XUL) + 2139
    #78 0x106f5ceae in NS_ProcessPendingEvents(nsIThread*, unsigned int) (in XUL) + 254
    #79 0x1063b7cd3 in nsBaseAppShell::NativeEventCallback() (in XUL) + 451
    #80 0x10633088a in nsAppShell::ProcessGeckoEvents(void*) (in XUL) + 490
    #81 0x7fff87abfb30 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ (in CoreFoundation) + 16
    #82 0x7fff87abf454 in __CFRunLoopDoSources0 (in CoreFoundation) + 244
    #83 0x7fff87ae27f4 in __CFRunLoopRun (in CoreFoundation) + 788
    #84 0x7fff87ae20e1 in CFRunLoopRunSpecific (in CoreFoundation) + 289
    #85 0x7fff89f08eb3 in RunCurrentEventLoopInMode (in HIToolbox) + 208
    #86 0x7fff89f08c51 in ReceiveNextEventCommon (in HIToolbox) + 355
    #87 0x7fff89f08ae2 in BlockUntilNextEventMatchingListInMode (in HIToolbox) + 61
    #88 0x7fff8348e562 in _DPSNextEvent (in AppKit) + 684
    #89 0x7fff8348de21 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] (in AppKit) + 127
    #90 0x10632f0d5 in -[GeckoNSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] (in XUL) + 245
    #91 0x7fff834851d2 in -[NSApplication run] (in AppKit) + 516
    #92 0x106331469 in nsAppShell::Run() (in XUL) + 185
    #93 0x105ee6c87 in nsAppStartup::Run() (in XUL) + 311
    #94 0x103c5a8d4 in XREMain::XRE_mainRun() (in XUL) + 4308
    #95 0x103c5b884 in XREMain::XRE_main(int, char**, nsXREAppData const*) (in XUL) + 580
    #96 0x103c5bd62 in XRE_main (in XUL) + 146
    #97 0x100002b88 in 0x200002b88
    #98 0x100001e3d in 0x200001e3d
    #99 0x1000013c3 in 0x2000013c3
    #100 0x1 in 0x0000000100000001 (in firefox-bin)
Stats: 527M malloced (398M for red zones) by 927747 calls
Stats: 63M realloced by 26275 calls
Stats: 481M freed by 714135 calls
Stats: 429M really freed by 643557 calls
Stats: 361M (92435 full pages) mmaped in 606 calls
  mmaps   by size class: 7:282555; 8:98256; 9:26598; 10:11242; 11:9690; 12:4480; 13:1984; 14:640; 15:384; 16:736; 17:468; 18:34; 19:36; 20:22; 21:5; 22:2; 24:2;
  mallocs by size class: 7:576916; 8:193656; 9:67878; 10:39461; 11:28352; 12:9320; 13:4892; 14:2505; 15:967; 16:1712; 17:1882; 18:98; 19:59; 20:35; 21:9; 22:2; 24:5;
  frees   by size class: 7:438971; 8:138755; 9:55433; 10:35677; 11:26420; 12:8073; 13:4309; 14:2116; 15:808; 16:1537; 17:1856; 18:81; 19:52; 20:32; 21:8; 22:2; 24:5;
  rfrees  by size class: 7:393148; 8:123452; 9:50992; 10:33042; 11:25288; 12:7486; 13:3960; 14:2024; 15:787; 16:1409; 17:1801; 18:77; 19:48; 20:30; 21:8; 22:2; 24:3;
Stats: malloc large: 4886 small slow: 11606
==85605== ABORTING
Comment 6 David Bolter [:davidb] 2013-04-25 13:03:46 PDT
Marking what we we know, trunk affected. Matt agreed to check branches. \o/
Comment 7 Matt Wobensmith [:mwobensmith][:matt:] 2013-04-30 15:33:50 PDT
Crashes 17esr, 21, 22 and 23. Doesn't appear to crash currently shipping 20.
Comment 8 Doug Turner (:dougt) 2013-05-01 21:16:59 PDT
matt, does that mean 18 and 19 don't crash?
Comment 9 Olli Pettay [:smaug] (high review load, please consider other reviewers) 2013-05-02 03:17:57 PDT
If that is the case, we need regression range.
Comment 10 David Bolter [:davidb] 2013-05-02 12:53:10 PDT
Cool! Matt can you further narrow down the regression range between 20 and 21?
Comment 11 Matt Wobensmith [:mwobensmith][:matt:] 2013-05-02 17:20:02 PDT
My bad. I had tried shipping (opt) FF20 and no crash, but this does in fact crash all debug FF20 builds.

I also went back to a FF19 debug ASan build I had from 2012-11-19, and it also crashes with same call stack as comment 5.

So, safe to say this has been there for some time. Also, it seems to always crash debug builds on affected branches; only occasionally does it crash a release build of the same branch/date.

Do we need a pre-FF20 regression window? Or does this answer some of the questions?
Comment 12 Olli Pettay [:smaug] (high review load, please consider other reviewers) 2013-05-02 17:22:34 PDT
I guess no need to check older builds (unless someone can prove this is a regression after all).
Comment 13 David Bolter [:davidb] 2013-05-03 07:12:59 PDT
(In reply to Olli Pettay [:smaug] from comment #12)
> I guess no need to check older builds (unless someone can prove this is a
> regression after all).

Agreed.

Thanks for catching that Matt. I've updated the relevant flag.
Comment 14 Daniel Veditz [:dveditz] 2013-05-03 12:17:47 PDT
Still happening in current nightlies, executing random memory, so needs an owner.  bp-c1609e3c-bd88-41b9-81bc-dd30b2130503

Debug build asserts
Assertion failure: mDocument->GetReadyStateEnum() == nsIDocument::READYSTATE_LOADING (Bad readyState), at c:/Users/std/dev/nightly/content/base/src/nsContentSink.cpp:1444
Comment 15 Olli Pettay [:smaug] (high review load, please consider other reviewers) 2013-05-07 10:44:41 PDT
Created attachment 746514 [details] [diff] [review]
patch?

Still haven't managed to reproduce, but based on the dveditz' crash report and code inspection, this probably fixes the problem. Or fixes certainly some
similar problem.

The assert fix is not pretty, but good enough for now. I'll file a bug about that
and cc hsivonen.
Comment 16 Daniel Veditz [:dveditz] 2013-05-07 11:32:17 PDT
I applied this patch to a debug build and did not get the assertion nor did it crash.
Comment 17 Boris Zbarsky [:bz] (Out June 25-July 6) 2013-05-07 11:37:06 PDT
Comment on attachment 746514 [details] [diff] [review]
patch?

r=me
Comment 18 Olli Pettay [:smaug] (high review load, please consider other reviewers) 2013-05-07 11:42:46 PDT
Comment on attachment 746514 [details] [diff] [review]
patch?

[Security approval request comment]
How easily could an exploit be constructed based on the patch?
Somewhat easily

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?
Well, the patch is rather obvious kungfuDeathGrip thing

Which older supported branches are affected by this flaw?
all

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?
The patch seems to apply everywhere (esr17 etc)

How likely is this patch to cause regressions; how much testing does it need?
close to zero risk
 
String or UUID changes made by this patch:
NA
Comment 19 Kyle Huey [:khuey] (khuey@mozilla.com) 2013-05-07 13:12:20 PDT
I was able to reproduce before the patch and unable to reproduce after.
Comment 20 Al Billings [:abillings] 2013-05-07 15:39:53 PDT
Comment on attachment 746514 [details] [diff] [review]
patch?

sec-approval+ (for m-c) after 5/14. Please make and nominate patches for affected branches.
Comment 21 Lukas Blakk [:lsblakk] use ?needinfo 2013-05-10 15:57:11 PDT
Comment on attachment 746514 [details] [diff] [review]
patch?

Bumping back the beta nom, we can take this for 22 beta.
Comment 22 Olli Pettay [:smaug] (high review load, please consider other reviewers) 2013-05-15 05:28:56 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/b44ef132d8a9
Comment 23 Ryan VanderMeulen [:RyanVM] 2013-05-15 18:37:08 PDT
https://hg.mozilla.org/mozilla-central/rev/b44ef132d8a9
Comment 26 Ioana (away) 2013-05-23 07:07:17 PDT
I managed to reproduce this issue constantly on Ubuntu 13.04 32bit with a Firefox 21 debug beta. Ergo, I verified the fix on the same OS with the latest Firefox 22 debug beta. Firefox doesn't crash anymore.
Comment 27 Matt Wobensmith [:mwobensmith][:matt:] 2013-06-17 17:02:07 PDT
Confirmed crash in 17.0.6esr as well as m-c in comment 5.
Confirmed fixed in 17.0.6esrpre, 2013-06-17.
Confirmed fixed in ASan FF23 Aurora, 2013-06-14.
Confirmed fixed in ASan FF24 m-c, 2013-06-14.
Comment 28 Jason Smith [:jsmith] 2013-08-06 10:43:40 PDT
http://hg.mozilla.org/releases/mozilla-b2g18_v1_1_0_hd/file/f0e9fcb591c2/docshell/base/nsDocShell.cpp#l4587

indicates that the patch was included here to fix this bug.
Comment 29 chris hofmann 2013-08-06 16:41:45 PDT
hey Nils, interested in if you discovered this in your ASAN testing, or via some other route.
Comment 30 Nils 2013-08-06 16:49:53 PDT
Hey Chris, this was me fuzzing on Windows. So no ASAN, just windbg attached.
Comment 31 Raymond Forbes[:rforbes] 2013-08-06 17:08:00 PDT
were you using !exploitable?
Comment 32 Mark S. Miller 2013-08-06 17:12:01 PDT
Since this bug is not publicly visible, but has been publicly exploited (the recent Tor compromise, allegedly by the FBI), I'm wondering: 

Was it already publicly known how to exploit this vulnerability? I'd guess yes, but if not, is there anything about the recent exploit that would help us determine whether it was based on the non-public knowledge represented by this bug-thread?
Comment 33 Nils 2013-08-06 17:14:51 PDT
No, manually looking at output. It crashed on an unmapped EIP value, which is a good indicator for exploitability.
Comment 34 Nils 2013-08-06 17:19:16 PDT
Mark: I had a brief look at the testcase from the exploit and it doesn't have a lot of similarity with the testcase from this bug. The patch does not give away a lot of information either.

My guess would be that someone else found this using a fuzzer.

Can we use the crash-stat information to find out whether unsuccessful exploitation attempts took place before the patch?

Note You need to log in before you can comment on or make changes to this bug.