278086 - Crash when reloading POST query on SSL/HTTPS page [@ ssl3_SendRecord ]

Status: RESOLVED DUPLICATE of bug 336501

(Core :: Security: PSM, defect, P1)

Description

[Christian Schmidt]

Firefox sometimes crashes when reloading an HTTPS page that is the result of a 
POST query containing a file.

Steps to reproduce:
1. Open an SSL page with a <form> containing a file upload control
2. Select a file to upload and press Submit
3. On the new page, press Reload
4. When Firefox asks whether you want to resend your POSTDATA, press OK

Actual result:
Firefox crashes

Talkback-ids: TB3021456K, TB3021271W, TB3021270Y

Comment 1

[Christian Schmidt]

Attachment: Testcase

BTW I am using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6)
Gecko/20050111 Firefox/1.0+. I also see this bug using Firefox 1.0.

Comment 2

[timeless]

Incident ID: 3021270
Stack Signature	ssl3_SendRecord 807579f8
Product ID	FirefoxTrunk
Build ID	2005011107
Trigger Time	2005-01-12 04:36:42.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	ssl3.dll + (00001c19)
URL visited	
User Comments	
Since Last Crash	73 sec
Total Uptime	6026 sec
Trigger Reason	Access violation
Source File, Line No.
c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/security/nss/lib/ssl/ssl3con.c,
line 1727
Stack Trace 	
ssl3_SendRecord 
[c:/builds/tinderbox/firefox/WINNT_5.0_Clobber/mozilla/security/nss/lib/ssl/ssl3con.c,
line 1727]

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

Neil, can you reproduce this?

Comment 4

[Eric Balsa]

This is exactly what's happening to me on 1.0.2

Comment 5

[Wan-Teh Chang]

On the aviary 1.0.1 branch, ssl3con.c hasn't changed
since Firefox 1.0.

The crash of comment 2 occurs in the PORT_Memcpy call
at line 1727:

  1716          /* This variable records
  1717           * the actual size of the buffer we allocated above. Some
  1718           * algorithms (FORTEZZA) will expand the number of bytes it needs to
  1719           * send data. If we only supply the output buffer with the same
number
  1720           * of bytes as the input buffer, we will fail.
  1721           */
  1722          bufSize = contentLen + SSL3_BUFFER_FUDGE;
  1723
  1724          /*
  1725           * null compression is easy to do
  1726           */
=>1727          PORT_Memcpy(write->buf + SSL3_RECORD_HEADER_LENGTH, buf,
contentLen);
  1728          buf   += contentLen;
  1729          bytes -= contentLen;
  1730          PORT_Assert( bytes >= 0 );
  1731
  1732          ssl_GetSpecReadLock(ss);        /********************************/
  1733
  1734          cwSpec = ss->ssl3->cwSpec;

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

I have not yet been able to reproduce this crash using the testcase
supplied in this bug.  So I have this request for people who can 
reproduce it.

Please try the NSS 3.10 Beta 2 binaries and see if you can still
reproduce the problem with them.  Here are steps to follow.
(If there is any step below that you don't understand, please don't
try any of them.)

1. Download NSS 3.10 Beta 2 binaries in the zip file from this URL
ftp://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_10_BETA2/WIN954.0_DBG.OBJ/nss-3.10beta2.zip

2. Exit your mozilla/FF/TB programs.
3. Go to the directory where your FF .exe lives.  
4. Make a new directory called "NSS-SAVE".
5. Move these 4 files from your FF directory to that new save directory:
   nss3.dll      smime3.dll    softokn3.dll  ssl3.dll
6. unzip those 4 files from the zipfile you downloaded.  They're in the "lib"
   directory of that zip file.  Copy them into your FF directory where the
   above 4 files were originally.
7. restart FF, and see if the problem still occurs.  
8. Let us know.

If things go wrong, put back the original 4 files.  

Comment 7

[Wan-Teh Chang]

I can't reproduce this crash using the attached
test case, either.

Nightly builds of Mozilla and Firefox on 2005-03-30
or later use NSS 3.10 Beta 2, so you can also just
use the latest nightly builds.

Comment 8

[Christian Schmidt]

I can still reproduce the crash using either of these configurations:
 - A recent nightly (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2)
Gecko/20050406 Firefox/1.0+)
 - A recent nightly with the four files from NSS 3.10 Beta 2
 - Firefox 1.0 with the four files from NSS 3.10 Beta 2

Talkback didn't kick in for the recent nightly, but using Firefox 1.0 I got this
Talkback ID: TB4886656E

Comment 9

[Neil Williams]

(In reply to comment #3)
> Neil, can you reproduce this?

I can't reproduce this on Firefox 1.0 (S10). Tried with a 371 byte file and one
150k. No crashes.

Comment 10

[Christian Schmidt]

I can still reproduce this on Deer Park Alpha 1 on Windows XP (but not on Linux).

Talkback IDs: TB6624070W and TB6624045Y

Comment 11

[Christian Schmidt]

This still happens with Firefox 1.5 RC1.

Comment 12

[Neil Williams]

Attachment: testcase2

Comment 13

[Neil Williams]

Attachment: testcase2

Comment 14

[Neil Williams]

Comment on attachment 201789 [details]
testcase2

I just tried to reproduce this bug with FF 1.5 RC 1 using the file from the testcase attachment. I did not experience the problem. Perhaps we some more detail here? 
Christian, was upload.html the file you uploaded to reprodcue the problem? Can you capture the SSL <FORM> page and post it?

Comment 15

[Nelson Bolyard (seldom reads bugmail)]

Since we NSS dedvelopers have been unable to reproduce this, perhaps those
who can reproduce it can give more information about how they do so.

Can you actually reproduce the problem with the first test form attached above?

Are you using any "extensions"?  If so, please name them.

For each file that you upload that experiences the crash, please answer 
these questions:
What is the size of the file that you upload that experiences the problem?
What is the type of that file?

Comment 16

[Christian Schmidt]

Yes, it is 100% reproducible for me with attachment 171030 [details].

It happens with small files (~10 KB) as well as larger files (~300 KB). Uploading a large files takes about 10 seconds. When I press F5, the crash happens immediately, i.e. before the whole file was uploaded again.

It only seems to happen when the Live HTTP Headers extension is installed.

Here is a fresh TB id: TB11434487H

Comment 17

[Nelson Bolyard (seldom reads bugmail)]

OK, I don't think this crash is the fault of NSS.  
NSS crashes trying to copy application data from memory at an address
given by the caller of NSS, for a length given by the caller of NSS.
If the address is bogus, or the length is absurdly long, a crash will
result.  NSS is no more guilty here than is memcopy.  Both have been 
given bad arguments.  

The fact that the crash only occurs in the presence of a particular 
extension strongly indicates that the actions of that extension led to
the bad address and/or length that is passed to NSS.  

It's unfortunate that the talkback only contains the address of the
function on the top of the stack, and not the rest of the stack.
I think the only way to find the source of the problem will be to build
a complete debug build of the browser and try it with that extension.
But I'm pretty sure the cause is not going to be in NSS.  
Is there a way to give this bug to the owner of that extension?

Comment 18

[Adam Guthrie]

*** Bug 312990 has been marked as a duplicate of this bug. ***

Comment 19

[Nelson Bolyard (seldom reads bugmail)]

This bug is evidently caused by the "Live HTTP Headers extension".
If there is a bug reporting system for that extension, this bug should
be filed there.  
NSS has been passed an invalid pointer, and is the victim here, not the
culprit.  NSS is no more the cause than say, memcopy.  The cause is the 
code that produces the invalid pointer.

Comment 20

[timeless]

nelson: so erm, afaik livehttpheaders is js. in general it should be virtually impossible for js to pass an invalid pointer to nss or anything else (in fact, anytime it can is generally a security vulnerability).

reporter: are you willing to use a developer's personal debug build? if so we can provide one where symbols are available and you can use windbg which should enable us to at least get a useful stack trace.

Comment 21

[Christian Schmidt]

> reporter: are you willing to use a developer's personal debug build?
Sure, no problem. I build on WinXP using MinGW, if that can be of any help. I don't have any experience with debugging tools, though.

Comment 22

[Nelson Bolyard (seldom reads bugmail)]

Timeless has suggested that the afflicted extension is pure javascript, 
making use of only JavaScript callable interfaces provided by the FF
product itself.  If that is true, then I would have to agree that the 
fault lies in the implementation of one (or more) JavaScript-callable
interfaces that ultimately call NSS.  I do not know what interface(s)
may be at fault, but I think there is a high probability that they are
part of PSM.  So, I am reopening this bug, and will reassign it to PSM
and PSM's owner.

Comment 23

[Nelson Bolyard (seldom reads bugmail)]

Kai, This is the bug we discussed yesterday, a crash in NSS that occurs 
when the page from a form post is reloaded and the Live HTTP Headers 
extension is installed.  libSSL receives a bad write data pointer and/or
length, and crashes when trying to copy the write data.  

In NSS 3.11, this code has been changed to try to reduce the amount of 
data copying, so with NSS 3.11, this crash may appear to be in an 
encryption function which is attempting to encrypt the data directly 
from the caller's buffer.

MinGW may also be a factor.  If you have experience with MinGW tools, 
perhaps you can explain to Christian how to get a stack trace when it crashes.

Comment 24

[Brad Bowman]

> MinGW may also be a factor

This also occurs on Linux.  See duplicate Bug #312990

Comment 25

[Brad Bowman]

Attachment: Debug output and backtrace during crash

Firefox 1.5 on Ubuntu Linux 2.6.10-5-686

Comment 26

[Nelson Bolyard (seldom reads bugmail)]

Brad, Thanks for those stack traces.  I don't know what tool produced the 
first stack trace, but it is the stack for the thread of interest.  
The second stack trace (from gdb's bt command) seems to be the stack of 
another thread.  Perhaps you can switch threads in gdb and find a stack
whose backtrace (bt) matches the stack shown as the first one?

From that first stack, We now know that PR_Write was called with a NULL 
buffer pointer.  Here are some of the missing function names in the first 
stack trace.

abort+0x000000E9 [/lib/tls/i686/cmov/libc.so.6 +0x0002A2C9]

UNKNOWN [./dist/bin/libnspr4.so +0x0000EE61]  is PR_Assert()
http://lxr.mozilla.org/mozilla/source/nsprpub/pr/src/io/prlog.c#525

UNKNOWN [./dist/bin/libssl3.so +0x00021EB2]   is ssl_SecureSend()
http://lxr.mozilla.org/mozilla/source/security/nss/lib/ssl/sslsecur.c#1058

UNKNOWN [./dist/bin/libssl3.so +0x00021F63]   is ssl_SecureWrite()
http://lxr.mozilla.org/mozilla/source/security/nss/lib/ssl/sslsecur.c#1125

UNKNOWN [./dist/bin/libssl3.so +0x00027A43]   is ssl_Write()
http://lxr.mozilla.org/mozilla/source/security/nss/lib/ssl/sslsock.c#1386

UNKNOWN [/home/bsb/mozilla/fb-obj-debug/dist/bin/components/libpipnss.so +0x000287EE]                                  is nsSSLIOLayerWrite() in PSM
http://lxr.mozilla.org/mozilla/source/security/manager/ssl/src/nsNSSIOLayer.cpp#1121

PR_Write+0x0000001C [./dist/bin/libnspr4.so +0x0000B3FD] is PR_Write http://lxr.mozilla.org/mozilla/source/nsprpub/pr/src/io/priometh.c#144

But the caller of PR_Write, who passed in a NULL ptr, is in the unknown
code below.  :-/

UNKNOWN [/home/bsb/mozilla/fb-obj-debug/dist/bin/components/libnecko.so +0x0005570F]                                             ?????
UNKNOWN [/home/bsb/mozilla/fb-obj-debug/dist/bin/components/libnecko.so +0x000CBE05]
UNKNOWN [/home/bsb/mozilla/fb-obj-debug/dist/bin/components/libnecko.so +0x000D9190]
UNKNOWN [./dist/bin/libxpcom_core.so +0x00076F62]

Comment 27

[Brad Bowman]

Attachment: Attempt #2 at a useful gdb backtrace

gdb backtrace hopefully in the right thread.
(If not I'll need additional gdb coaching)

Comment 28

[Kai Engert (:KaiE:)]

Comment on attachment 204906 [details]
Attempt #2 at a useful gdb backtrace

Darin, this stack trace shows that some networking code calls SSL I/O functions with a null buffer.

Comment 29

[Darin Fisher]

Comment on attachment 204906 [details]
Attempt #2 at a useful gdb backtrace

Looks like a problem in nsBufferedInputStream::ReadSegments perhaps.  It is probably passing a null mBuffer.  Not sure how that could happen :(

Comment 30

[Kai Engert (:KaiE:)]

i just retried using a seamonkey linux build from latest 1.8 branch, having latest livehttpheaders 0.12 installed to the profile dir.

I went to the test site, uploaded a 70k text file, confirmed to resubmit when asked, and did not see a crash.

christian, do you still crash?

hmm, but let me try windows

Comment 31

[Kai Engert (:KaiE:)]

I also tried on Windows, using firefox 2.0 alpha + from a couple of days ago. livehttpheaders 0.12 refused to install, so I downloaded the .xpi, unzipped, edited install.rdf, changed version 1.5+ to 2.0+, updated the .xpi zip archive and installed locally, this worked.

I went to the test page and I can not reproduce the crash.

closing as worksfor, in the hope this bug has meanwhile been fixed by some other code changes.

please reopen if you can still reproduce, thanks.

Comment 32

[Kai Engert (:KaiE:)]

timeless suggested this might have been fixed in the context of bug 336501

Comment 33

[Nelson Bolyard (seldom reads bugmail)]

I propose that we resolve this bug as a duplicate of bug 336501.  objections?

Comment 34

[Kai Engert (:KaiE:)]

(In reply to comment #33)
> I propose that we resolve this bug as a duplicate of bug 336501.  objections?
> 

ok


*** This bug has been marked as a duplicate of 336501 ***