Width wraps to negative value using CSS




16 years ago
8 years ago


(Reporter: security-bugs, Assigned: dbaron)


Windows 2000

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [sg:want])


(1 attachment)

From Georgi, potential security problem:

Attached file css2.html uses width: 1073741952px; which wraps to negative
value and the console gives the following - 
###!!! ASSERTION: Negative Width Input - very bad: 'mComputedWidth>=0', file
nsHTMLReflowState.cpp, line 2729
Break: at file nsHTMLReflowState.cpp, line 2729
Probably this is not exploitable, but negative values can lead to problems.
Probably large values with CSS may lead to problems in the future.
Created attachment 108537 [details]
Example - css2.html
cc'ing layout people for threat prognosis.

seems just like an innocent bug to me though.
cc'ing some mozilla regulars who watch the people i cc'ed last time
Another strange behavior is the following:
<style type="text/css">
        img { position: relative; border: thick solid; color: red; width:
65535px; height: 65535px; }
Large css values. Check the console.

<img src="poweredby.png">

mozilla displays large scrollbars, the image is not shown, the console gave
strange things. Some times after several reloads, the content area displays garbage.

I may be wrong, but an image with size 65535x65535 cannot be handled correctly
on 32 bit x86.

The same test on konqueror shows very small image with borders but no scrollbars.

Also mozilla does not seem to consume so much memory in this case which kind of
surprise me.
What's the security risk of bugs like this?  Incorrect handling of memory
allocation failures?  If so, then security problems are extremely unlikely in
core layout, but possible in image handling.
Not only memory alocation. Another problem may be passing negative values to
memcpy() and such. 
The apache chunked bug turned exploitable on at least windoze and *bsd.
But all the problems relate to using the numbers that wrap as sizes of things in
memory (whether allocations, parameters to memcpy, etc.)?  So if we never use
widths as sizes we're OK?
How hard would this be to fix? If it's straghtforward, it's probably better to
fix it first, analyze the risk later.
Let's try to get this fixed by 1.4 final, just to be safe.
Not unless somebody can give me a definition of fixed such that there is reason
to believe that there may be a security problem that is more likely to be fixed
with the assertion gone than with the assertion present.
dbaron, you know better than I do. If you think there's no security problem
here, please uncheck the Security-Sensitive flag.

Comment 12

16 years ago
dbaron, can you take one last look at this and if you don't see the security
problem then let's take the security closed status off.

Comment 13

11 years ago
sounds like sg:low or no security problem here.  updating whiteboard
Whiteboard: sg:low
Whiteboard: sg:low → [sg:low]

Comment 14

8 years ago
Will be fixed by bug 575011 or bug 265084, or by using more the "saturating arithmetic" functions such as NSCoordSaturatingAdd in more places.
Group: core-security
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Whiteboard: [sg:low] → [sg:want]
Duplicate of bug: 265084
You need to log in before you can comment on or make changes to this bug.