183986 - Width wraps to negative value using CSS

Status: RESOLVED DUPLICATE of bug 265084

(Core :: CSS Parsing and Computation, defect)

Description

[Mitchell Stoltz (not reading bugmail)]

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

[Mitchell Stoltz (not reading bugmail)]

Attachment: Example - css2.html

Comment 2

[Hixie (not reading bugmail)]

cc'ing layout people for threat prognosis.

seems just like an innocent bug to me though.

Comment 3

[Hixie (not reading bugmail)]

cc'ing some mozilla regulars who watch the people i cc'ed last time

Comment 4

[georgi - hopefully not receiving bugspam]

Another strange behavior is the following:
----------
<style type="text/css">
        img { position: relative; border: thick solid; color: red; width:
65535px; height: 65535px; }
</style>
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

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 6

[georgi - hopefully not receiving bugspam]

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

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

[Mitchell Stoltz (not reading bugmail)]

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

[Mitchell Stoltz (not reading bugmail)]

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

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

[Mitchell Stoltz (not reading bugmail)]

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

Comment 12

[chris hofmann]

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

[chris hofmann]

sounds like sg:low or no security problem here.  updating whiteboard

Comment 14

[Jesse Ruderman]

Will be fixed by bug 575011 or bug 265084, or by using more the "saturating arithmetic" functions such as NSCoordSaturatingAdd in more places.