209080 - invalid HTTP headers crash mozilla

Status: RESOLVED WORKSFORME

(Core :: Networking: HTTP, defect)

Description

[bradfitz]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030519 Mozilla Firebird/0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030519 Mozilla Firebird/0.6

I can reliably crash Mozilla with a certain type of bogus HTTP response headers.



Reproducible: Always

Steps to Reproduce:
1. working on mod_perl app and printed debugging to stdout, and not stderr
2. loaded URL in browser, mozilla crashed.


Actual Results:  
Crashed.

Expected Results:  
Not crash.

If I run a packet capture on the client, Mozilla doesn't crash.  (maybe putting
the interface into promisicous mode changes the packet ordering/size?)

However, I was able to run a packet capture on the server and save its results
during a crash.

I'll be attaching a tcpdump file showing what caused the crash.

Here's a snippet, though:

GET /~brad/9117.html HTTP/1.1
Host: papag.danga.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030519
Mozilla Firebird/0.6
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate,compress;q=0.9
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://papag.danga.com/~brad/
Cookie: ljsession=ws:brad:1:iPcUVhH8oj:.FS; langpref=en_LJ/1055348568;
BMLschemepref=xcolibur; langpref=en_LJ/1055348568; BMLschemepref=xcolibur;
ljsession=ws:brad:1:iPcUVhH8oj:.FS

HTTP/1.1 200 OK
Date: Wed, 11 Jun 2003 19:59:40 GMT
X-Cache: MISS from www.lj.com
Connection: close
Transfer-Encoding: chunked
Content-Type: text/plain; charset=iso-8859-1

9c0
          'picture_keyword' => 'pimping',
          'poster_ip' => '10.0.0.10'
        };
set 56: $VAR1 = {
          'picture_keyword' => 'pimping',
          'poster_ip' => '10.0.0.10'
        };
HTTP/1.1 200 OK
Date: Wed, 11 Jun 2003 19:59:40 GMT
Server: Apache/1.3.26 (Unix) Debian GNU/Linux mod_ssl/2.8.9 OpenSSL/0.9.6g
mod_perl/1.26
Cache-Control: private, proxy-revalidate
Content-Encoding: gzip
Vary: Accept-Encoding
Content-length: 1982
Connection: close
Content-Type: text/html; charset=utf-8

[binary gzip data]

Comment 1

[bradfitz]

Attachment: tcpdump log

log of HTTP headers which make moz crash

Comment 2

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Do you have a testpage we could use?

Comment 3

[Darin Fisher]

Attachment: complete text of HTTP transaction, including binary characters

Comment 4

[Darin Fisher]

the response header block is totally normal:

  HTTP/1.1 200 OK
  Date: Wed, 11 Jun 2003 19:59:40 GMT
  X-Cache: MISS from www.lj.com
  Connection: close
  Transfer-Encoding: chunked
  Content-Type: text/plain; charset=iso-8859-1

maybe this has something to do with the chunk encoding... reporter: did talkback
run when mozilla crashed?

Comment 5

[Darin Fisher]

so timing must really matter because i just put the same data stream on an
internal server and could not repro the crash.  here's my attempt at repro'ing it:

http://unagi/bugs/bug_209080/nph-test.cgi

Comment 6

[bradfitz]

Darin,

I don't have a trackback build.  I straced some crashes, though.  Here's a snippet:

read(4, "\372", 1)                      = 1
ioctl(3, FIONREAD, [0])                 = 0
gettimeofday({1055288349, 458211}, NULL) = 0
poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN, revents=POLLIN}], 2, 0) = 1
gettimeofday({1055288349, 458407}, NULL) = 0
read(4, "\372", 1)                      = 1
ioctl(3, FIONREAD, [0])                 = 0
gettimeofday({1055288349, 458694}, NULL) = 0
poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN, revents=POLLIN}], 2, 0) = 1
gettimeofday({1055288349, 458889}, NULL) = 0
read(4, "\372", 1)                      = 1
ioctl(3, FIONREAD, [0])                 = 0
gettimeofday({1055288349, 459176}, NULL) = 0
poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, 0) = 0
gettimeofday({1055288349, 459367}, NULL) = 0
write(3, "5\30\4\0S\2\340\1>\0\0\0\21\0\21\0;\3\5\0\313\0\340\1\0"..., 492) = 492
read(3, "\1\2\16K\0\0\0\0.\0\340\1\0\0\0\0\4\0\0\0\0\0\0\0(\377"..., 32) = 32
write(3, ";\3\5\0\10\0\340\1\0\0\0\0\0\0\0\0\20\0\20\0008\0\5\0\10"..., 416) = 416
read(3, "\1\2#K\0\0\0\0.\0\340\1\0\0\0\0\4\0\0\0\0\0\0\0(\377\237"..., 32) = 32
write(3, "5\30\4\0T\2\340\1>\0\0\0\20\0\20\0005\1\4\0U\2\340\1>\0"..., 1788) = 1788
read(3, "\1\2HK\0\0\0\0.\0\340\1\0\0\0\0\4\0\0\0\0\0\0\0(\377\237"..., 32) = 32
write(3, ";\3\5\0\t\0\340\1\0\0\0\0\1\0\362\1\16\0\16\0008\2\5\0"..., 500) = 500
read(3, "\1\2aK\0\0\0\0.\0\340\1\0\0\0\0\4\0\0\0\0\0\0\0(\377\237"..., 32) = 32
write(3, ";\3\5\0\t\0\340\1\0\0\0\0X\3\362\1\16\0\16\0008\2\4\0\t"..., 484) = 484
read(3, "\1\2zK\0\0\0\0.\0\340\1\0\0\0\0\4\0\0\0\0\0\0\0(\377\237"..., 32) = 32
write(3, ";\3\5\0\t\0\340\1\0\0\0\0\16\0\362\1\307\0\16\0008\2\4"..., 404) = 404
read(3, "\1\2\220K\0\0\0\0.\0\340\1\0\0\0\0\4\0\0\0\0\0\0\0(\377"..., 32) = 32
brk(0)                                  = 0x8939000
brk(0x8943000)                          = 0x8943000
write(3, ">\3\7\0X\2\340\1M\2\340\1\303\0\340\1\0\0\0\0\0\0\0\0h"..., 2048) = 2048
write(3, "\232\27\n\0\3\2\340\1\306\0\340\1Z\2\340\1.\0\0\0Q\2\340"..., 2028) = 2028
write(3, "\232\30\261\1\3\2\340\1\306\0\340\1Z\2\340\1.\0\0\0R\2"..., 2036) = 2036
write(3, "\232\27\n\0\3\2\340\1\306\0\340\1Z\2\340\1.\0\0\0Q\2\340"..., 1844) = 1844
write(3, "\1\27\n\0\25\0\310\0\202\0\340\1\377\2\340\1\0\0\0\0R\2"..., 2036) = 2036
write(3, "\232\27\n\0\3\0\310\0\306\0\340\1Z\2\340\1.\0\0\0Q\2\340"..., 2028) = 2028
write(3, "\232\30\324\0\3\0\310\0\306\0\340\1Z\2\340\1.\0\0\0R\2"..., 2040) = 2040
write(3, "\232\27\n\0\3\0\310\0\306\0\340\1Z\2\340\1.\0\0\0Q\2\340"..., 2028) = 2028
write(3, "\232\27\n\0\3\0\310\0\306\0\340\1Z\2\340\1.\0\0\0Q\2\340"..., 956) = 956
write(3, "\1\27\n\0\10\0*\1w\6\340\1\377\2\340\1\0\0\0\0P\2\340\1"..., 2048) = 2048
write(3, "\377\27\n\0\0\0\0\0P\2\340\1\2\2\340\1\r\0\0\0\216\0\v"..., 784) = 784
write(3, "\20\27\n\0\10\0008\1\314\0P\0\25\0#\0 \0\265\0\314\0\25"..., 1888) =
-1 EPIPE (Broken pipe)
--- SIGPIPE (Broken pipe) @ 0 (0) ---
write(2, "The application \'MozillaFirebird"..., 159) = 159
unlink("/raid/bradfitz/.phoenix/default/luk5ltf1.slt/lock") = 0
write(9, "\200\0\33@\2\0\0\0\1\0\0\0\260$x@X\212Y@8p\35\10\0 x@\320"..., 148) = 148
rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0
rt_sigsuspend([] <unfinished ...>
--- SIGRTMIN (Real-time signal 0) @ 0 (0) ---
<... rt_sigsuspend resumed> )           = -1 EINTR (Interrupted system call)
sigreturn()                             = ? (mask now [RTMIN])
wait4(4836, NULL, __WCLONE, NULL)       = 4836
munmap(0x4001f000, 8192)                = 0
exit_group(1)                           = ?


I was going to make a test case, but clicking attachment 125446 [details] [diff] [review] above causes my
current mozilla (Firebird 0.6) to crash.  Therefore, I'll assume you guys don't
need a test case, since that's a pretty good one already.

I'll test some other builds and see how far this dates back.

Comment 7

[Darin Fisher]

how about trying a more recent version of mozilla?  can you download and test
today's build in fact?  thx!

Comment 8

[bradfitz]

Darin,

Can you attach your .cgi to this bug so I can test it outside your firewall? 
nph- isn't always nph- in my experience.  I tried using Apache's mod_asis to
make a test case for you guys, but Apache cleaned enough to stop the crash. 

I agree it has something to do with timing, as I can consistently crash it
without putting my network interface in promisicous mode, but once I do, I just
get garbage on the screen (as expected with those headers).  This is why I had
to do the tcpdump on the server.

If your nph cgi doesn't crash for me, I'll attach a perl script acting as a mini
HTTP server just to send the bogus headers.

Comment 9

[bradfitz]

With Linux 2003061108 I don't crash clicking on the second attachment above.

That's not to say the bug/race is gone, but maybe the timing's different now.

I guess this could be closed, but unless somebody's explicitly fixed this at
some point (or cleaned up the chunking code), I imagine the bug's still lurking.

Comment 10

[Darin Fisher]

also, if you can repro this using a more recent nightly build, then please also
generate a HTTP log using these steps:

  http://www.mozilla.org/projects/netlib/http/http-debugging.html

thanks!

Comment 11

[Darin Fisher]

Attachment: test cgi script

Comment 12

[Darin Fisher]

Attachment: stream.txt

stream.txt that goes with nph-test.cgi

Comment 13

[Darin Fisher]

bradfitz: what about with your original testcase?  the newer build loads it as
well without any problems?

Comment 14

[Daniel Veditz [:dveditz]]

Checking bug status
 - can we confirm?
 - can we close it?
 - can we eliminate the confidential flag since there's
   no hint the crash is exploitable? (we don't normally
   mark potential DOS attacks confidential.)

Comment 15

[Daniel Veditz [:dveditz]]

WFM from comment 9. If it comes back we'll try to catch it in a new bug with
more details hopefully.