Last Comment Bug 503286 - (CVE-2009-2477) browser crash when search suggestions show [@ js_Interpret ] [@ js_Execute]
(CVE-2009-2477)
: browser crash when search suggestions show [@ js_Interpret ] [@ js_Execute]
Status: VERIFIED FIXED
[sg:critical] fixed-in-tracemonkey
: crash, crashreportid, regression, testcase, verified1.9.1.1
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: 1.9.1 Branch
: All All
: -- critical with 1 vote (vote)
: mozilla1.9.2a1
Assigned To: Blake Kaplan (:mrbkap)
:
Mentors:
http://www.aport.ru
: 504001 504237 504298 504810 507075 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-09 04:45 PDT by zbyte
Modified: 2013-03-11 11:22 PDT (History)
38 users (show)
mbeltzner: blocking1.9.1.1+
dveditz: wanted1.9.0.x-
choller: in‑testsuite-
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Fairly minimized, standalone, no russion, no httprequest. (7.27 KB, text/html)
2009-07-09 13:10 PDT, u348128
no flags Details
testcase, reduced a bit more. (1.81 KB, text/html)
2009-07-09 14:14 PDT, Nochum Sossonko [:Natch]
no flags Details
debug session (6.57 KB, text/plain)
2009-07-09 14:34 PDT, Nochum Sossonko [:Natch]
no flags Details
Reduces a little bit more, not much. (1.14 KB, text/html)
2009-07-09 14:52 PDT, u348128
no flags Details
even slightly more reduced (1.07 KB, text/html)
2009-07-09 15:08 PDT, Aaron Train [:aaronmt]
no flags Details
Final minimize. (412 bytes, text/html)
2009-07-09 15:29 PDT, u348128
no flags Details
Debugging patch (4.97 KB, patch)
2009-07-09 17:59 PDT, Blake Kaplan (:mrbkap)
no flags Details | Diff | Splinter Review
Fix Andreas came up with (2.31 KB, patch)
2009-07-09 18:03 PDT, Blake Kaplan (:mrbkap)
jorendorff: review+
Details | Diff | Splinter Review
For 1.9.1 (3.13 KB, patch)
2009-07-14 01:27 PDT, Blake Kaplan (:mrbkap)
mrbkap: review+
mbeltzner: approval1.9.1.1+
Details | Diff | Splinter Review

Description zbyte 2009-07-09 04:45:53 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; ru; rv:1.9.1) Gecko/20090624 Firefox/3.5 (.NET CLR 3.5.30729) AutoPager/0.5.2.2 (http://www.teesoft.info/)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; ru; rv:1.9.1) Gecko/20090624 Firefox/3.5 (.NET CLR 3.5.30729) AutoPager/0.5.2.2 (http://www.teesoft.info/)

If start type search request in main form browser crash immediately. Crash only on some requests.

Reproducible: Always

Steps to Reproduce:
1. Go to www.aport.ru
2. In input form type one charater: 't'
3. Browser crash immediately.
Actual Results:  
Browser crash immediately.

Expected Results:  
Search suggestions showed
Comment 1 Ria Klaassen (not reading all bugmail) 2009-07-09 05:04:50 PDT
Confirmed on Windows Vista. I'll try to find some bug history.
Comment 2 Ria Klaassen (not reading all bugmail) 2009-07-09 05:10:34 PDT
http://crash-stats.mozilla.com/report/index/da9a7b5d-113b-4416-b512-d8bbf2090709?p=1
Comment 3 Ria Klaassen (not reading all bugmail) 2009-07-09 05:29:07 PDT
Regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fb5635f0d184&tochange=4a34c6235bb7
Comment 4 Ria Klaassen (not reading all bugmail) 2009-07-09 05:36:01 PDT
Trunk crash ID: http://crash-stats.mozilla.com/report/index/2afc6ae4-a95d-424d-b079-ef6fc2090709?p=1
Comment 5 u348128 2009-07-09 11:04:23 PDT
Can confirm this on Windows XP. Highly reproducible.
Comment 6 Aaron Train [:aaronmt] 2009-07-09 11:41:51 PDT
Confirmed on OSX with 3.5 and latest 1.9.2 trunk

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090709 Minefield/3.6a1pre
Comment 7 u348128 2009-07-09 13:10:06 PDT
Created attachment 387713 [details]
Fairly minimized, standalone, no russion, no httprequest.

A first minimized version. Not completely minimized, but without referenced files and without HttpRequest.
Comment 8 Nochum Sossonko [:Natch] 2009-07-09 13:13:39 PDT
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5
bp-f8062a2b-f1bd-4a43-90b3-322de2090709
Comment 9 u348128 2009-07-09 13:38:35 PDT
Title of bug is incorrect now. No AJAX involved. Javascript with string processing and innerHTML.
Comment 10 Ria Klaassen (not reading all bugmail) 2009-07-09 13:44:36 PDT
Problem is still present in the latest tracemonkey.
Comment 11 Nochum Sossonko [:Natch] 2009-07-09 14:14:16 PDT
Created attachment 387727 [details]
testcase, reduced a bit more.
Comment 12 Nochum Sossonko [:Natch] 2009-07-09 14:23:08 PDT
FTR, the line numbers for strict warnings and errors are totally borked for that file. Also, it dies in the function escapeData right after the "avto ??????" entry. I couldn't really reduce it anymore, anything I do stops crashing.
Comment 13 Nochum Sossonko [:Natch] 2009-07-09 14:34:38 PDT
Created attachment 387732 [details]
debug session

Looks like the content sink might be at fault here...
Comment 14 Blake Kaplan (:mrbkap) 2009-07-09 14:41:07 PDT
This is a JS engine bug dealing with deep bailing not properly restoring the return value from the result of the (fast native) escape function. We then try to do something with the uninitialized memory and crash in the interpreter.
Comment 15 Aaron Train [:aaronmt] 2009-07-09 14:45:45 PDT
(In reply to comment #13)
> Created an attachment (id=387732) [details]
> debug session
> 
> Looks like the content sink might be at fault here...

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x4000003b
0x00177d5c in JS_HashTableRawRemove ()
(gdb) bt 
#0  0x00177d5c in JS_HashTableRawRemove ()
#1  0x00184fcd in js_FreeStack ()
#2  0x0013354b in JS_EvaluateUCScriptForPrincipals ()
#3  0x014e5f67 in std::__adjust_heap<__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > >, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, nsRefPtr<imgCacheEntry> const&)> ()
...
Comment 16 u348128 2009-07-09 14:52:42 PDT
Created attachment 387739 [details]
Reduces a little bit more, not much.

Removed a little bit, but crash is now very sensitive for more removal.
Comment 17 Aaron Train [:aaronmt] 2009-07-09 15:08:48 PDT
Created attachment 387744 [details]
even slightly more reduced
Comment 18 u348128 2009-07-09 15:29:15 PDT
Created attachment 387752 [details]
Final minimize.

Now document lookup anymore. Just string processing.
Comment 19 Blake Kaplan (:mrbkap) 2009-07-09 16:29:58 PDT
You guys rock. I was able to hack the shell into crashing with the last testcase!
Comment 20 Blake Kaplan (:mrbkap) 2009-07-09 17:59:44 PDT
Created attachment 387786 [details] [diff] [review]
Debugging patch

Here's the patch I used to make the shell crash on Lucas' testcase. Andreas: don't look!
Comment 21 Blake Kaplan (:mrbkap) 2009-07-09 18:03:21 PDT
Created attachment 387787 [details] [diff] [review]
Fix Andreas came up with

Andreas mostly came up with this patch. I sort of followed along and verified that it fixes the crash. It also makes sense to me.

I don't have any clue how to make a trace-test for this... We can use Lucas' testcase as a mochitest, though.
Comment 22 Blake Kaplan (:mrbkap) 2009-07-09 18:03:40 PDT
(of course, when I say mochitest up there, I mean crashtest.)
Comment 23 u348128 2009-07-10 16:35:25 PDT
Since this bug is memory corruption and the 'escape' function is not exotic, other crashes could be in fact this bug (this bug is pretty serious).

I suspect bug 503144 being a duplicate of this. And I have seen another crash report, which could be a duplicate of this (I have to look that up).

Lucas
Comment 24 Aaron Train [:aaronmt] 2009-07-10 16:39:28 PDT
(In reply to comment #23)
> Since this bug is memory corruption and the 'escape' function is not exotic,
> other crashes could be in fact this bug (this bug is pretty serious).
> 
> I suspect bug 503144 being a duplicate of this. And I have seen another crash
> report, which could be a duplicate of this (I have to look that up).
> 
> Lucas

Right, the trend with this recent spill of JS crashes are all foreign sites making use of escape();
Comment 25 u348128 2009-07-13 11:39:17 PDT
Just a question. Could the same bug appear with other builtin functions, like unescape? Or, does the patch solve all builtin function problems?

I was searching in crash sites and found something with an 'unescape' but without an 'escape'.

Lucas
Comment 26 Jason Orendorff [:jorendorff] 2009-07-13 15:26:21 PDT
Comment on attachment 387787 [details] [diff] [review]
Fix Andreas came up with

Is the declaration of deepBailSp missing?

r=me assuming that's the only thing.
Comment 27 Blake Kaplan (:mrbkap) 2009-07-13 15:59:40 PDT
http://hg.mozilla.org/tracemonkey/rev/dc402f0a1122
Comment 28 Blake Kaplan (:mrbkap) 2009-07-13 16:00:32 PDT
(In reply to comment #25)
> Just a question. Could the same bug appear with other builtin functions, like
> unescape? Or, does the patch solve all builtin function problems?

The patch fixes all builtin functions.
Comment 29 Nochum Sossonko [:Natch] 2009-07-13 20:55:20 PDT
*** Bug 504001 has been marked as a duplicate of this bug. ***
Comment 30 WD 2009-07-13 21:01:22 PDT
From the duped bug 504001 , 
This bug has reliable exploit code on milw0rm that results in code execution.
http://milw0rm.com/exploits/9137
Comment 31 Mike Beltzner [:beltzner, not reading bugmail] 2009-07-13 21:07:40 PDT
Can we get the fix merged over to m-c, bitte?
Comment 32 Andreas Gal :gal 2009-07-13 21:10:38 PDT
Not sure what the internal policy is on publicly known exploits and hiding bugs or not. Someone versed in policy stuff please decide whether to unhide or not :)
Comment 33 Andreas Gal :gal 2009-07-13 21:23:18 PDT
Looking at the exploit code and our test cases, I think this is self-inflicted and we should have hidden the bug earlier. But this is very hard to judge to be hones.t I wouldn't entire exclude fuzzing or random heap spraying as method of discovery. Maybe someone with more experience on how such exploits are discovered wants to weigh in.
Comment 34 WD 2009-07-13 21:44:01 PDT
It would seem that the milw0rm exploit code is based on the testcases for this bug.   When you look at the crash details in a debugger, it's pretty clear that it's exploitable with a heap spray to the access violation address in question.
Comment 36 David Tran 2009-07-13 21:46:02 PDT
I don't know know anything about the usual policy for hiding bugs, but in general, whether or not you publish something like that, security by obscurity in general is bad. There are always hackers out there trying to make a name for themselves and they'll throw every combination of fuzzers to find an exploit and make a name for themselves. Even if these testcases weren't visible, it was just a matter of time before someone would have gotten lucky and found the exploit.
Comment 37 Gary Kwong [:gkw] [:nth10sd] 2009-07-13 21:53:14 PDT
(In reply to comment #36)
> I don't know know anything about the usual policy for hiding bugs, but in
> general, whether or not you publish something like that, security by obscurity
> in general is bad. There are always hackers out there trying to make a name for
> themselves and they'll throw every combination of fuzzers to find an exploit
> and make a name for themselves. Even if these testcases weren't visible, it was
> just a matter of time before someone would have gotten lucky and found the
> exploit.

True - but the _speed_ of fuzzers won't be faster than just heading to a not-yet-hidden-but-exploit-is-there-for-the-taking bug and taking the code to create an exploit. Note that the code in question apparently is identical to the testcase (if true), per comment #34.

The delay created by security through obscurity is bad, but it has its merits by providing some sort of delay, which is better than no delay at all (as in this case). Here we have an exploit created from a known bug that should have been hidden from the onset, reflecting probably on our shortcoming in some way, no one's mistake in particular.

But I digress...
Comment 38 Robert Sayre 2009-07-13 21:59:23 PDT
yeah, well, linking the bugzilla bugs from crash-stats.mozilla.com is certainly an optimization, no matter how you look at it.
Comment 39 Rob Arnold [:robarnold] 2009-07-13 23:46:54 PDT
Stack trace from Windows 7:
js3250.dll!js_Interpret(JSContext * cx=0x050b8450)  Line 4007 + 0x73 bytes
js3250.dll!js_Execute(JSContext * cx=0x050b8450, JSObject * chain=0x02881720, JSScript * script=0x051d0c78, JSStackFrame * down=0x00000000, unsigned int flags=0x00000000, int * result=0x00000000)  Line 1661 + 0x9 bytes
js3250.dll!JS_EvaluateUCScriptForPrincipals(JSContext * cx=0x050b8450, JSObject * obj=0x02881720, JSPrincipals * principals=0x04e6d4a4, const unsigned short * chars=0x068a1738, unsigned int length=0x00000139, const char * filename=0x004d1570, unsigned int lineno=0x00000003, int * rval=0x00000000)  Line 5157 + 0x19 bytes
gklayout.dll!nsJSContext::EvaluateString(const nsAString_internal & aScript={...}, void * aScopeObject=0x02881720, nsIPrincipal * aPrincipal=0x04e6d4a0, const char * aURL=0x004d1570, unsigned int aLineNo=0x00000003, unsigned int aVersion=0x00000000, nsAString_internal * aRetValue=0x00000000, int * aIsUndefined=0x001ae590)  Line 1682 + 0x42 bytes
gklayout.dll!nsScriptLoader::EvaluateScript(nsScriptLoadRequest * aRequest=0x06676380, const nsString & aScript={...})  Line 686 + 0x7a bytes
gklayout.dll!nsScriptLoader::ProcessRequest(nsScriptLoadRequest * aRequest=0x06676380)  Line 600 + 0x13 bytes
gklayout.dll!nsScriptLoader::ProcessScriptElement(nsIScriptElement * aElement=0x066ef95c)  Line 554 + 0x17 bytes
gklayout.dll!nsScriptElement::MaybeProcessScript()  Line 193 + 0x13 bytes
gklayout.dll!nsHTMLScriptElement::MaybeProcessScript()  Line 547 + 0xb bytes
gklayout.dll!nsHTMLScriptElement::DoneAddingChildren(int aHaveNotified=0x00000001)  Line 485
gklayout.dll!HTMLContentSink::ProcessSCRIPTEndTag(nsGenericHTMLElement * content=0x066ef938, int aMalformed=0x00000000)  Line 3096 + 0x12 bytes
gklayout.dll!SinkContext::CloseContainer(nsHTMLTag aTag=eHTMLTag_script, int aMalformed=0x00000000)  Line 1014 + 0x12 bytes
gklayout.dll!HTMLContentSink::CloseContainer(nsHTMLTag aTag=eHTMLTag_script)  Line 2376 + 0x11 bytes
gkparser.dll!CNavDTD::CloseContainer(nsHTMLTag aTag=eHTMLTag_script, int aMalformed=0x00000000)  Line 2762 + 0x26 bytes
gkparser.dll!CNavDTD::HandleEndToken(CToken * aToken=0x04cddca8)  Line 1641 + 0x13 bytes
gkparser.dll!CNavDTD::HandleToken(CToken * aToken=0x04cddca8)  Line 721 + 0xc bytes
gkparser.dll!CNavDTD::BuildModel(nsITokenizer * aTokenizer=0x004d1168, int aCanInterrupt=0x00000001, int aCountLines=0x00000001, const nsCString * __formal=0x0525137c)  Line 304 + 0xc bytes
gkparser.dll!nsParser::BuildModel()  Line 2452 + 0x5f bytes
gkparser.dll!nsParser::ResumeParse(int allowIteration=0x00000001, int aIsFinalChunk=0x00000000, int aCanInterrupt=0x00000001)  Line 2333 + 0xe bytes
gkparser.dll!nsParser::OnDataAvailable(nsIRequest * request=0x050ea158, nsISupports * aContext=0x00000000, nsIInputStream * pIStream=0x050eb0a8, unsigned int sourceOffset=0x00000000, unsigned int aLength=0x0000019c)  Line 2981 + 0x17 bytes
docshell.dll!nsDocumentOpenInfo::OnDataAvailable(nsIRequest * request=0x050ea158, nsISupports * aCtxt=0x00000000, nsIInputStream * inStr=0x050eb0a8, unsigned int sourceOffset=0x00000000, unsigned int count=0x0000019c)  Line 306 + 0x30 bytes
necko.dll!nsBaseChannel::OnDataAvailable(nsIRequest * request=0x004ebf80, nsISupports * ctxt=0x00000000, nsIInputStream * stream=0x050eb0a8, unsigned int offset=0x00000000, unsigned int count=0x0000019c)  Line 708 + 0x52 bytes
necko.dll!nsInputStreamPump::OnStateTransfer()  Line 508 + 0x40 bytes
necko.dll!nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream * stream=0x050eb0a8)  Line 398 + 0xb bytes
xpcom_core.dll!nsInputStreamReadyEvent::Run()  Line 112
xpcom_core.dll!nsThread::ProcessNextEvent(int mayWait=0x00000001, int * result=0x001af010)  Line 527 + 0x19 bytes
xpcom_core.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x00414cc8, int mayWait=0x00000001)  Line 230 + 0x16 bytes
gkwidget.dll!nsBaseAppShell::Run()  Line 170 + 0xc bytes
tkitcmps.dll!nsAppStartup::Run()  Line 193 + 0x1c bytes
xul.dll!XRE_main(int argc=0x00000004, char * * argv=0x009cb0a0, const nsXREAppData * aAppData=0x009cfe70)  Line 3369 + 0x25 bytes
firefox.exe!NS_internal_main(int argc=0x00000004, char * * argv=0x009cb0a0)  Line 156 + 0x12 bytes
firefox.exe!wmain(int argc=0x00000004, wchar_t * * argv=0x009cc758)  Line 110 + 0xd bytes
firefox.exe!__tmainCRTStartup()  Line 583 + 0x19 bytes
firefox.exe!wmainCRTStartup()  Line 403
kernel32.dll!75df3f39() 	
[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]	
ntdll.dll!776d0409() 	
ntdll.dll!776d03dc() 	

jsinterp.c:4007
if (!JSVAL_IS_PRIMITIVE(lval))
        DEFAULT_VALUE(cx, -2, JSTYPE_VOID, lval);
    if (!JSVAL_IS_PRIMITIVE(rval))
-->     DEFAULT_VALUE(cx, -1, JSTYPE_VOID, rval);
    if ((cond = JSVAL_IS_STRING(lval)) || JSVAL_IS_STRING(rval)) {
        if (cond) {
            str = JSVAL_TO_STRING(lval);
            str2 = js_ValueToString(cx, rval);
Comment 40 Rob Arnold [:robarnold] 2009-07-14 00:48:39 PDT
Not able to run calc.exe via the exploit posted on Windows 7 RC.
Comment 41 Vladimir Vukicevic [:vlad] [:vladv] 2009-07-14 00:52:07 PDT
This patch needs to get into 1.9.1 ASAP.
Comment 42 Blake Kaplan (:mrbkap) 2009-07-14 01:25:16 PDT
Comment on attachment 387787 [details] [diff] [review]
Fix Andreas came up with

This patch doesn't apply cleanly to the 1.9.1 branch.
Comment 43 Blake Kaplan (:mrbkap) 2009-07-14 01:27:53 PDT
Created attachment 388437 [details] [diff] [review]
For 1.9.1

The merge was pretty trivial, though!
Comment 44 Blake Kaplan (:mrbkap) 2009-07-14 02:01:18 PDT
I'm not sure what's going on with flags/keywords... But I landed http://hg.mozilla.org/releases/mozilla-1.9.1/rev/a1a6b17a22da (with a crashtest) and also http://hg.mozilla.org/mozilla-central/rev/ddb8d512ede1 on trunk.
Comment 45 Rob Campbell [:rc] (:robcee) 2009-07-14 05:31:38 PDT
just ran this from last night's nightly, and still crashing on the testcase.
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.1/

mac.dmg dated 04:45, July 13th, 2009.

Did this not get picked up by the builder?
Comment 46 Rob Campbell [:rc] (:robcee) 2009-07-14 05:44:19 PDT
verified fixed in latest hourly build.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1pre) Gecko/20090714

from:
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/f223409207c0

looking at the time I pasted above, it's not surprising the fix was not in that build (checkin was 11 hours later).
Comment 47 Mike Beltzner [:beltzner, not reading bugmail] 2009-07-14 08:53:43 PDT
I asked Ben to respin 1.9.1 nightlies.

Blake: can you also land this on GECKO191_20090623_RELBRANCH in case we decide to minibranch?
Comment 48 u348128 2009-07-14 11:00:07 PDT
I made the first test case, but I am not from Mozilla. If a good reproducible crash is sufficient to turn the security flag on, then bug 502648 (flash bug) should also get the security flag on. A bug no one is working on, yet.

Lucas
Comment 49 Jesse Ruderman 2009-07-14 11:27:53 PDT
If it's reproducible and the stack trace shows signs of exploitability, yes.  Bug 502648 looks like a null deref, which is not exploitable.  See http://www.squarefree.com/2006/11/02/determining-whether-a-crash-looks-exploitable/ for how I evaluate crash stacks.
Comment 50 u348128 2009-07-14 11:37:11 PDT
I only volunteer to make some test cases. Someone from Mozilla should have done this check and added it to bug 502648 (I will copy this info now).
Comment 51 Daniel Veditz [:dveditz] 2009-07-14 11:40:03 PDT
A good, reproducible testcase is sufficient to run through a debugger and get a good idea whether it's exploitable or not. Comment 14 is around when this turned into a security bug.

bug 502648 looks like a null dereference which are not exploitable (usually -- sometimes the particular testcase results in a near-null but the bug might behave differently in other cases).
Comment 52 Daniel Veditz [:dveditz] 2009-07-14 11:43:27 PDT
(In reply to comment #50)
> I only volunteer to make some test cases.

And it's much appreciated!! Once we have a testcase everything else is easy (often including the fix). Just keep sticking the testcase keyword up there when you do and it shows up in our triage queries.
Comment 53 u348128 2009-07-14 13:46:08 PDT
Maybe off topic, but I don't know where to ask.

The site:

http://crash-stats.mozilla.com/

Has crashed per URL, but only for FF3.1b2. I can't get a list for FF3.5. Is this deliberate (for security)?

I managed to produce bug 502648 from that list, but I don't have any reproduction work now. There is nothing interesting in bugzilla anymore.

Lucas
Comment 54 Samuel Sidler (old account; do not CC) 2009-07-14 20:04:29 PDT
*** Bug 504237 has been marked as a duplicate of this bug. ***
Comment 55 Ludovic Hirlimann [:Usul] 2009-07-15 05:49:57 PDT
*** Bug 504298 has been marked as a duplicate of this bug. ***
Comment 56 Mike Beltzner [:beltzner, not reading bugmail] 2009-07-15 08:28:46 PDT
(In reply to comment #53)
> Has crashed per URL, but only for FF3.1b2. I can't get a list for FF3.5. Is
> this deliberate (for security)?

No, it's non-deliberate, it's a bug with the site. :)
Comment 57 Aakash Desai [:aakashd] 2009-07-15 10:25:47 PDT
verified FIXED on builds:

...for Shiretoko
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1pre) Gecko/20090715 Shiretoko/3.5.1pre (.NET CLR 3.5.30729) ID:20090715044728

and

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090613 Shiretoko/3.5pre ID:20090613031011

...for trunk
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090714 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090714054201

and

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090715 Minefield/3.6a1pre ID:20090715031744
Comment 58 Andreas Gal :gal 2009-07-15 23:15:07 PDT
Verified FIXED with MacOSX 3.5.1 candidate build.
Comment 59 Fernando Hartmann 2009-07-16 13:12:53 PDT
I just installed the 3.5.1 (bild1) from the beta channel, and tested against
the exploit code, and the crash don't happened in my Windows Vista machine.
The exploit seems to be solved.
Comment 60 Blake Kaplan (:mrbkap) 2009-07-17 11:12:29 PDT
*** Bug 504810 has been marked as a duplicate of this bug. ***
Comment 61 Aakash Desai [:aakashd] 2009-07-17 13:16:20 PDT
*** Bug 504810 has been marked as a duplicate of this bug. ***
Comment 62 Daniel Veditz [:dveditz] 2009-07-17 15:05:50 PDT
For bug searching ease, both http://www.milw0rm.com/exploits/9158 and http://www.milw0rm.com/exploits/9181 exploit this bug and are fixed in Firefox 3.5.1 (and never affected Firefox 3.0.x or earlier).
Comment 63 Daniel Veditz [:dveditz] 2009-07-17 15:21:55 PDT
I meant http://www.milw0rm.com/exploits/9137 and http://www.milw0rm.com/exploits/9181 -- 9158 is an unrelated DoS bug.
Comment 64 Samuel Sidler (old account; do not CC) 2009-07-28 19:40:29 PDT
*** Bug 507075 has been marked as a duplicate of this bug. ***
Comment 65 Christian Holler (:decoder) 2013-03-11 11:22:38 PDT
Filter on qa-project-auto-change:

Bug in removed tracer code, setting in-testsuite- flag.

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