Closed Bug 78876 Opened 23 years ago Closed 23 years ago

null bytes badly interpreted in base64-encoded data: URI scheme

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.1

People

(Reporter: david+bugs, Assigned: neeti)

References

(
URL
)

Details

(Keywords: testcase, Whiteboard: want for mozilla 0.9.1)

Attachments

(1 file)

patch which fixes base64 length computation
704 bytes, patch
Details | Diff | Splinter Review 
nsDataChannel::ParseData() uses PL_strlen() to compute the length of
base64-encoded data, which means that whenever the data contain a null byte,
they will be truncated.

Test case: the following URI (same as URL field above in bug report)

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAIAAAACUFjqAAAABGdBTUEAALGPC/xhBQAAAAlwSFlzAAALEgAACxIB0t1+/AAAAAd0SU1FB9EFBAoYMhVvMQIAAAAtSURBVHicY/z//z8DHoBH+v///yy4FDEyMjIwMDDhM3lgpaEuh7gTEzDiDxYA9HEPDF90e5YAAAAASUVORK5CYII=

should point to a 10*10 PNG image representing a small square.  Instead, it does
some quite weird things (my build says Image 13660284x1075756316 pixels and
prints the URI itself in the body, but I expect this to be architecture dependent).

This was introduced by an incorrect resolution of bug 53792.  See also final
comments on bug 47288.  A patch which fixes this is forthcoming.
good catch. 

let me review your fix now.
Status: UNCONFIRMED → NEW
Ever confirmed: true
David: I applied the patch and see the image of the small square being 
displayed. However, when I reload, I see the following assertions before it 
loads the page again. 
Seth : could you review this?
###!!! ASSERTION: nsDataChannel::Cancel: 'Not Reached', file L:\build\mozilla\ne
twerk\protocol\data\src\nsDataChannel.cpp, line 255
###!!! ASSERTION: nsDataChannel::Cancel: 'Not Reached', file L:\build\mozilla\ne
twerk\protocol\data\src\nsDataChannel.cpp, line 255
###!!! ASSERTION: Cancel failed: 'NS_SUCCEEDED(cancelRv)', file l:\build\mozilla
\netwerk\base\src\nsAsyncStreamListener.cpp, line 109
###!!! ASSERTION: nsDataChannel::Cancel: 'Not Reached', file L:\build\mozilla\ne
twerk\protocol\data\src\nsDataChannel.cpp, line 255
###!!! ASSERTION: Cancel failed: 'NS_SUCCEEDED(cancelRv)', file l:\build\mozilla
\netwerk\base\src\nsAsyncStreamListener.cpp, line 109
What is going on with this bug?  Seth, did you have the chance to review?
Whiteboard: want for mozilla 0.9.1
I haven't reviewed / tested yet.  on my short list of things to do today.
testing this fix now...
I tested the patch.  it's good.

the assertions are not related to this bug.  probably a bug with data urls and
the mem cache, if you made me guess without looking.

r=sspitzer
new bug logged on the assertions.  #79896

this is ready for sr and checkin.

it's necko, so you might want valeski or gagan for the sr.
Target Milestone: --- → mozilla0.9.1
Judson: Could you sr= this bug.

Thanks,
Neeti
Blocks: 77850
cc'ing valeski for sr=?
No longer blocks: 77850
Blocks: 77850
please test the following bugs, we've changed the way we compute the length
several times now:

http://bugzilla.mozilla.org/show_bug.cgi?id=53792
http://bugzilla.mozilla.org/show_bug.cgi?id=35439

I believe your patch will re-introduce
http://bugzilla.mozilla.org/show_bug.cgi?id=21314

I think we're chasing our tails w/ broken usages of data: urls unfortunately :-/.
I tested the above three bugs with and without the above patch.

1. For bug http://bugzilla.mozilla.org/show_bug.cgi?id=53792, we display the 
 same data with and without the patch.

2. For bug http://bugzilla.mozilla.org/show_bug.cgi?id=35439, for the testcase

http://bugzilla.mozilla.org/showattachment.cgi?attach_id=7466

We do not show #2 in the build without the patch, but in a build with the patch 
we show #2.

For the test link http://pmt.sourceforge.net/gamma_test/ we broken with and 
without the patch.

3. For bug http://bugzilla.mozilla.org/show_bug.cgi?id=21314

I do not see random characters appearing at the bottom of messages in a build 
with the patch.

Was there a specfic test case email message which showed the bug? 

Seth: Could you try testing bug 
http://bugzilla.mozilla.org/show_bug.cgi?id=21314 with the above patch. It would 
help if you could also verify we are causing any regressions.

Thanks,
Neeti
I'm overloaded right now.  neeti, can you drive this?
Judson: I have tested bug http://bugzilla.mozilla.org/show_bug.cgi?id=21314 with  
the patch applied on linux and windows, and I do not see any random characters 
appearing at the bottom of messages. 
as I pointed out earlier. I suspect we're just bouncing a bug back and forth.
your code looks fine to me, r=valeski, but we just need to be ready for another
bug to bounce back up, and determine which we want to supress.
I agree.
checked in fix
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
I can now see base64 encoded images using the data: protocol (cool!), but now I 
crash on base64 encoded text/html.

For instance, the following crashes mozilla, but shows up just fine in Netscape 
4.77...


data:text/html;base64,PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMD
AgVHJhbnNpdGlvbmFs 
Ly9FTiIKImh0dHA6Ly93d3cudzMub3JnL1RSL2h0bWw0L2xvb3NlLmR0ZCI+CjxodG1sPjxoZWFk 
Pjx0aXRsZT5DcmVhemlvbmUgVXRlbnRpPC90aXRsZT48L2hlYWQ+Cjxib2R5IGJnY29sb3I9Indo 
aXRlIj48Zm9udCBmYWNlPSJzYW5zLXNlcmlmIiBzaXplPTM+CgombmJzcDsgCgo8aDE+UHJvdmEg 
ZGkgaWZyYW1lPC9oMT4KVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJv 
dmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkg 
cHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8g 
ZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVz 
dG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEg 
VGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJv 
dmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkg 
cHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8g 
ZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVz 
dG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEg 
VGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJv 
dmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkg 
cHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8g 
ZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVz 
dG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEK 
VGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJv 
dmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkg 
cHJvdmEKCjwvZm9udD48L2JvZHk+PC9odG1sPgoK


also, base64 encoded mp3's play immediately with the system default mp3 player 
in Netscape 4.77, but pop up a download dialog in Mozilla...seems to confuse 
Mozilla.  I'll post the base64 mp3 if anyone wants to test that out.

jake
data:text/html;base64,PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDAgVHJhbnNpdGlvbmFsLy9FTiIKImh0dHA6Ly93d3cudzMub3JnL1RSL2h0bWw0L2xvb3NlLmR0ZCI+CjxodG1sPjxoZWFkPjx0aXRsZT5DcmVhemlvbmUgVXRlbnRpPC90aXRsZT48L2hlYWQ+Cjxib2R5IGJnY29sb3I9IndoaXRlIj48Zm9udCBmYWNlPSJzYW5zLXNlcmlmIiBzaXplPTM+CgombmJzcDsgCgo8aDE+UHJvdmEgZGkgaWZyYW1lPC9oMT4KVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEgVGVzdG8gZGkgcHJvdmEKCjwvZm9udD48L2JvZHk+PC9odG1sPgoK

works for me on today's build.  doesn't crash on linux.

about the mp3 problem, I think that's by design.  but log a bug on it if you
think otherwise.  (cc mscott on it.)
Seth, you are partially right about the text/html.  I took out any line breaks 
and/or spaces and it rendered fine without crashing.

however, Netscape 4.77 deals with the line breaks/spaces transparently.  For 
instance, if I copy your example into the Address box and view it, it makes no 
difference whether there are spaces or not for Netscape 4.77 and it most 
certainly does not crash.  

To test this, try puting even one single space into into the base64 text that 
you provided, have Mozilla load that, and watch it crash immediately.

That seems just a bit sensitive to me.  I could be evil and put base64 data 
with line breaks/spaces in a web page to crash peoples browsers intentionally.  
hehehehehehehe.  

It isn't overly functional if it is that sensitive.

I dont' think this bug is fixed until it is robust enough not to crash on 
something that simple.

jake
jake, log a new bug on this problem.
reported bug 81185 per Seth's comment

jake
reported bug 81190 about strange behavior in handling base64 encoded mp3's

Jake
*** Bug 76312 has been marked as a duplicate of this bug. ***
+verifyme, so it gets attention from me later...
Keywords: verifyme
Verified Duplicate
Status: RESOLVED → VERIFIED
Keywords: verifyme → testcase
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: