53792 - nsDataChannel::ParseData() calculates the wrong length on the base64 decoded data

Status: VERIFIED FIXED

(Core :: Networking, defect, P3)

Description

[(not reading, please use [e-mail] instead)]

I'm working on something that uses data: urls

basically, I build up a data url with a spec like this:

"data:text/html;base64,<foo>"

where <foo> is base 64 encoded html follows, encoded with PL_Base64Encode().

I've noticed that when I run the data url and <foo> comes back decoded, extra
junk is at the end.

I've traced it down, and the problem is in nsDataChannel::ParseData()

see line 187 on nsDataChannel.cpp:

	dataToWrite->dataLen = resultLen;

If you look at how resultLen is calculated, it is way too big.  (it's about the
size of the *encoded* data.  it should be the size of the decoded data.)

This fix is working for me:
	
		dataToWrite->dataLen = PL_strlen(decodedData);

PL_Base64Decode() will null terminate the buffer since we pass null for the 3rd
parameter.

Do you think this could be causing any other bugs?

my code that uses this isn't checked in yet, but I'd need to fix this before I
do check in.

Comment 1

[(not reading, please use [e-mail] instead)]

Attachment: here's the patch

Comment 2

[(not reading, please use [e-mail] instead)]

valeski, mscott, can you review the patch?

for an explanation see my original comments in the bug report.

Comment 3

[Scott MacGregor]

sr=mscott

Comment 4

[(not reading, please use [e-mail] instead)]

taking from valeski.

Comment 5

[(not reading, please use [e-mail] instead)]

fixed.  I'll come up with at data url that tever can use to verify.

Comment 6

[(not reading, please use [e-mail] instead)]

to reproduce, click here:

data:text/html;base64,VGhpcyBpcyBhIHRlc3QK

before the fix, you'd see:

"This is a test ýýýý"

after, you should see

"This is a test"

Comment 7

[Tom Everingham]

Seth, is this platform specific?  This seems to work on my rtm builds on Linux 
and NT.  I do see some trailing garbage characters on the mac though.

Comment 8

[Tom Everingham]

oh wait, sorry I just had to hit reload and it was their.  Will check your patch 
on tomorrows build .

Comment 9

[(not reading, please use [e-mail] instead)]

the bug is XP.  the trailing garbage is not guaranteed, but common.

we can try other data urls to convince you.

try

data:text/html;base64,YSBzbGlnaHRseSBsb25nZXIgdGVzdCBmb3IgdGV2ZXIK

fyi, heres how I generate the base64 data:

$ echo "a slightly longer test for tever" > foo
$ uuencode -m foo test

begin-base64 664 test
YSBzbGlnaHRseSBsb25nZXIgdGVzdCBmb3IgdGV2ZXIK
====

Comment 10

[Tom Everingham]

ok thanks, both of those examples work on my three test platforms

Verified
WinNT4 2000113004-Mtrunk
Linux rh6 2000113006-Mtrunk
Mac os9 2000113008-Mtrunk

Comment 11

[David A. Madore]

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

Comment 12

[David A. Madore]

This bug's resolution introduced a new one.  Please refer to bug 78876