Width wraps to negative value using CSS




CSS Parsing and Computation
16 years ago
7 years ago


(Reporter: Mitchell Stoltz (not reading bugmail), 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.

Comment 1

16 years ago
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.

Comment 5

16 years ago
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.

Comment 7

16 years ago
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?

Comment 8

16 years ago
How hard would this be to fix? If it's straghtforward, it's probably better to
fix it first, analyze the risk later.

Comment 9

15 years ago
Let's try to get this fixed by 1.4 final, just to be safe.

Comment 10

15 years ago
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.

Comment 11

15 years ago
dbaron, you know better than I do. If you think there's no security problem
here, please uncheck the Security-Sensitive flag.

Comment 12

15 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.


11 years ago
QA Contact: ian → style-system

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

7 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: 7 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.