Closed Bug 131761 Opened 22 years ago Closed 22 years ago

'cursor' points to freed memory during multipart header parsing

Categories

(Core :: Networking, defect)

defect
Not set
critical

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]
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;
}

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
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
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/
->security
Assignee: asa → mstoltz
Component: Browser-General → Security: General
QA Contact: doronr → bsharma
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
-> badami for investigation
Assignee: darin → badami
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.
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?
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
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?
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).
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. 

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.
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.
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.
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.
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
Component: Networking: FTP → Networking
I'am unable to reproduce this bug with a trunk build.
mstoltz: right, i don't think there is any way the data at |cursor| could be
executed.

*** This bug has been marked as a duplicate of 100595 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Group: security?
VERIFIED:dupe
Status: RESOLVED → VERIFIED
QA Contact: tever → benc
You need to log in before you can comment on or make changes to this bug.