Closed
Bug 131761
Opened 22 years ago
Closed 22 years ago
'cursor' points to freed memory during multipart header parsing
Categories
(Core :: Networking, defect)
Core
Networking
Tracking
()
VERIFIED
DUPLICATE
of bug 100595
People
(Reporter: jonathan, Assigned: darin.moz)
References
()
Details
We've been investigating a problem that seems to occur whenever Netscape 6.0 or Mozilla Gecko 5.0 receive Multipart/Mixed information, that appears to be a buffer overflow or in the code. At the very least, there appears to be a condition allowing a partial memory dump to the screen. Please view the screenshot at http://www.networkdweebs.com/screenbug.gif and you will notice that prior to any useful text in the window is a couple lines of junk text. This text appears to be random every time, and in fact, some of the text that was actually sent as the HTML code is not even being displayed. After thoroughly testing our code, as well as Apache's web server code, we've come to the conclusion that the cause of this must be the web browser itself. Netscape v4.x does not experience this problem nor do any versions of MSIE. I've included a snippett of the packet data taken from a snoop, which shows that the data being sent to the web browser is correct and does not contain this junk information. For a complete transcript of the packet data, see http://www.networkdweebs.com/screenbug.txt I've tried contacting netscape but to no avail. This problem seems to affect both Linux and Windows web browsers. [SNIP] 0: 00d0 7d04 2ba3 00e0 1807 1aed 0800 4500 ..}.+.........E. 16: 0072 1dd5 4000 4006 4d74 d133 8842 a228 .r..@.@.Mt.3.B.( 32: d39e 1f90 6fbd bd69 718b d56b 9e94 8018 ....o..iq..k.... 48: 8218 66a8 0000 0101 080a 032c efa8 0000 ..f........,.... 64: f5cb 4854 5450 2f31 2e31 2032 3030 0a43 ..HTTP/1.1 200.C 80: 6f6e 7465 6e74 2d74 7970 653a 206d 756c ontent-type: mul 96: 7469 7061 7274 2f6d 6978 6564 3b62 6f75 tipart/mixed;bou 112: 6e64 6172 793d 424c 4148 424c 4148 0a0a ndary=BLAHBLAH.. 0: 00d0 7d04 2ba3 00e0 1807 1aed 0800 4500 ..}.+.........E. 16: 00da 1dd6 4000 4006 4d0b d133 8842 a228 ....@.@.M..3.B.( 32: d39e 1f90 6fbd bd69 71c9 d56b 9e94 8018 ....o..iq..k.... 48: 8218 7593 0000 0101 080a 032c efa9 0000 ..u........,.... 64: f5cb 3c48 544d 4c3e 3c42 4f44 5920 4247 ..<HTML><BODY BG 80: 434f 4c4f 523d 4646 4646 4646 2054 4558 COLOR=FFFFFF TEX 96: 543d 3030 3030 3030 204c 494e 4b3d 3030 T=000000 LINK=00 112: 3838 4646 2056 4c49 4e4b 3d46 4638 3846 88FF VLINK=FF88F 128: 463e 0a2d 2d42 4c41 4842 4c41 480a 436f F>.--BLAHBLAH.Co 144: 6e74 656e 742d 7479 7065 3a20 7465 7874 ntent-type: text 160: 2f68 746d 6c0a 0a3c 4854 4d4c 3e3c 424f /html..<HTML><BO 176: 4459 2042 4743 4f4c 4f52 3d46 4646 4646 DY BGCOLOR=FFFFF 192: 4620 5445 5854 3d30 3030 3030 3020 4c49 F TEXT=000000 LI 208: 4e4b 3d30 3038 3846 4620 564c 494e 4b3d NK=0088FF VLINK= 224: 4646 3838 4646 3e0a FF88FF>. 0: 00d0 7d04 2ba3 00e0 1807 1aed 0800 4500 ..}.+.........E. 16: 01e9 1dd9 4000 4006 4bf9 d133 8842 a228 ....@.@.Kù.3.B.( 32: d39e 1f90 6fbd bd69 726f d56b 9e94 8018 ....o..iro.k.... 48: 8218 1bff 0000 0101 080a 032c efb3 0000 ...........,.... 64: f5cb 3c46 4f4e 5420 4641 4345 3d41 5249 ..<FONT FACE=ARI 80: 414c 2053 495a 453d 2b31 3e3c 423e 426f AL SIZE=+1><B>Bo 96: 623c 2f46 4f4e 543e 3c2f 423e 205b 3c46 b</FONT></B> [<F 112: 4f4e 5420 434f 4c4f 523d 424c 5545 206f ONT COLOR=BLUE o 128: 6e4d 6f75 7365 4f76 6572 3d22 7374 796c nMouseOver="styl 144: 652e 666f 6e74 5765 6967 6874 3d27 626f e.fontWeight='bo [SNIP]
Reporter | ||
Comment 1•22 years ago
|
||
To reproduce this, please visit http://www.networkdweebs.com:8080/cgi-bin/nph- test This is a simple perl script: #!/usr/bin/perl $|=1; print <<_end; HTTP/1.1 200 Content-type: multipart/mixed;boundary=BLAHBLAH <HTML><BODY BGCOLOR=FFFFFF TEXT=000000 LINK=0088FF VLINK=FF88FF> --BLAHBLAH Content-type: text/html _end print <<_end; <HTML><BODY BGCOLOR=FFFFFF TEXT=000000 LINK=0088FF VLINK=FF88FF> _end for(1..20) { print "$_<BR>\n"; sleep 1; }
Comment 2•22 years ago
|
||
cannot reproduce with BRANCH_099 on Mandrake 8.2 Linux, no crash and no junk on screen on http://www.networkdweebs.com:8080/cgi-bin/nph-test
Comment 3•22 years ago
|
||
wfm using build 2002031803 on Win2k. I don't see any junk. Severity -> Critical (buffer overflow, security issue). Reporter, are you using any proxy ? Can you take a screenshot with junk you see using URL http://www.networkdweebs.com:8080/cgi-bin/nph-test ?
Severity: normal → critical
Comment 4•22 years ago
|
||
Reporter, what build ID are you using ? If not 0.9.9 or above, please either try 0.9.9 or latest nightly build: http://ftp.mozilla.org/pub/mozilla/nightly/latest/
Comment 5•22 years ago
|
||
->security
Assignee: asa → mstoltz
Component: Browser-General → Security: General
QA Contact: doronr → bsharma
Reporter | ||
Comment 6•22 years ago
|
||
After doing some additional testing, it looks like the following are affected: - Netscape 6.0 - 6.21 (Tested on Windows XP and RedHat 7.2) - Mozilla Build 2001090111 (Included with RedHat 7.2) And the following are not affected: - Mozilla 0.9.9 (Tested on RedHat 7.1, 7.2, and Debian) I'm hoping someone at Mozilla can confirm that it was truly fixed in 0.9.9 and not just accidentally changed where it could pop up somewhere else. I don't see this bug reported anywhere on securityfocus.
this needs to be looked at by the networking people.
Assignee: mstoltz → darin
Component: Security: General → Networking: HTTP
QA Contact: bsharma → tever
Assignee | ||
Comment 9•22 years ago
|
||
if this bug has been fixed in mozilla 0.9.9, then all that is necessary is to test this bug against a recent nightly build of mozilla, and then if it still seems fixed, we can go ahead and mark it fixed.
Comment 10•22 years ago
|
||
I'm going to mark this bug Security-Sensitive. That means that only those people on the Mozilla security group, plus everyone CC'd on the bug, will be able to view it. If anyone objects, please send mail to security-group@mozilla.org and we will reconsider.
Group: security?
Reporter | ||
Comment 11•22 years ago
|
||
Netscape 6.21 on Linux; downloaded today. Screenshot at http://www.networkdweebs.com/netscape.gif I can provide a Windows XP shot if anyone needs it.
Updated•22 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 12•22 years ago
|
||
see bug 100595, which fixed this on the trunk. the patch is attachment 55804 [details] [diff] [review]
Assignee: badami → darin
Component: Networking: HTTP → Networking: FTP
Comment 13•22 years ago
|
||
The phrase "buffer overflow bug" is a very specific class of bug. The bug listed here (when reproduced) appears to be "junk" in a buffer. The most common cause of this class of bug would be an uninitialized variable, or read from uninitialized memory. There is no evidence that there is a "buffer overflow" from the description given. *IF* there was a buffer overflow, I would expect to see evidence of a crash, induced by a large attacker provided string. I don't (yet?) see mention of such things. As a result, it is hard for me to see the potential for a security breach as significant as what might come from a true buffer overrun. Do folks in the know with a "fix" believe this is a buffer overrun problem? Can an attacker control that incoming (overrunning) buffer?
Assignee | ||
Comment 14•22 years ago
|
||
I do not believe that this is a buffer overrun. Instead, the problem here is that we read from the address of some memory which has been freed. We try to parse the data at that address. The only thing written to this freed memory are some null bytes and newline characters. Data supplied from the server is NOT written to this freed memory. The patch (attachment 55804 [details] [diff] [review]) causes the variable |cursor| to be updated to point to the newly allocated buffer instead of the recently freed buffer. Parsing happens at |cursor|. This bug occurs when the server does not send the boundary token as the first bit of data in the http response body. The code attempts to write the boundary on behalf of the server. It does so correctly, without buffer overrun. However, the code simply fails to update its |cursor| afterwards. This bug can easily manifest itself as a crash (see bug 100595).
Reporter | ||
Comment 15•22 years ago
|
||
Is there any possibility that this could be attacked in the same fashion as a race condition? e.g. an attacker could somehow be able to predict what behavior would result in a certain piece of code being present in that freed memory? And if so, could an attacker use this to execute said arbitrary code? Also, is it possible under any circumstances that this freed memory could be a username or password sent previously via HTTP authentication or a CGI? If neither of these are possible then I agree this is more of a junk buffer bug than a security flaw. We weren't sure, which is why we plopped a question mark at the end of the topic.
Reporter | ||
Comment 16•22 years ago
|
||
To elaborate on my previous message, I ask because I've seen words such as 'value' and 'google' and 'chrome://navig2' whatever that is appear as part of the junk text, most likely from sites I previously visited.
Comment 17•22 years ago
|
||
Yeah.... anything is possible... but if we treated every read of unused memory asa security bug, we'd never have anything to ship. It is IMO a waste of time to hypothesize ways that junk reading could turn into security breaches, unless we have a concrete example. ...but I think this bug can have its subject line fixed to *not* include the phrase buffer-overrun. Once that is done, the bug is "just another bug" that should be fixed as schedule permits, and based on prioritization of impact and probability of appearance.
Assignee | ||
Comment 18•22 years ago
|
||
hmm.. interesting. it is completely possible that the freed memory could be recycled and reused for some other purpose while |cursor| is still pointing to it and while the multipart header parsing is happening. this is a small window; however, and there is little to no predictability as to how and when the freed memory will be recycled for some other purpose. there is likewise no way of predicting what that other purpose will be. perhaps there is a very slim possibility that the freed buffer will be recycled and used by some part of the application that stores usernames or passwords; however, IMO such a senario is extremely unlikely. it is certainly not something a hackor could predict. the only opportunity for something like this might be if some work was being done on a background thread that involved sensitive data. in the case of mozilla, this might correspond to some simultaneous SSL transaction. but, this still doesn't correspond to giving the server some means to execute code.
Comment 19•22 years ago
|
||
Yes, but is that data ever executed? I doubt it - the errant pointer is not a function pointer. Maybe there's some way to populate the junk data with some script code, as in <SCRIPT>...</SCRIPT>, and I don't think that gets the attacker anything.
Comment 20•22 years ago
|
||
Ignore my last comment - mid-air collision. Changing the summary as Jim suggested. Forgive my ignorance, but WRT Darin's last comment, there's no way the memory pointed to by |cursor| could be re-used for code instead of data, is there? In other words, while there's a slim chance of |cursor| giving access to confidential information, is there any chance of it being used to modify code that will be executed later on?
Summary: Buffer Overflow in Geck/Netscape 5.0/6.0? → 'cursor' points to freed memory during multipart header parsing
Updated•22 years ago
|
Component: Networking: FTP → Networking
Comment 21•22 years ago
|
||
I'am unable to reproduce this bug with a trunk build.
Assignee | ||
Comment 22•22 years ago
|
||
mstoltz: right, i don't think there is any way the data at |cursor| could be executed.
Assignee | ||
Comment 23•22 years ago
|
||
*** This bug has been marked as a duplicate of 100595 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Updated•22 years ago
|
Group: security?
You need to log in
before you can comment on or make changes to this bug.
Description
•