373934 - js.c snarf() inconsistant allocation use

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[lsg-mtso]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.2) Gecko/20070225 BonEcho/2.0.0.2
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.2) Gecko/20070225 BonEcho/2.0.0.2

No limit is placed on the file size of the file size read. len could become 0xffffffff, which will cause a 0 allocation, followed by large fread into the 0 allocated buffer.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.



Check the return from ftell is not -1 or would cause an overflow after the arbitrary adjustment in js_malloc().

Comment 1

[Daniel Veditz [:dveditz]]

Seems unlikely an attacker could usefully get a user to download a 4Gb file, but I suppose it could compress to nearly nothing.

Comment 2

[Brian Crowder]

This is a shell-only bug, right?  Doesn't affect the browser.

Comment 3

[Daniel Veditz [:dveditz]]

So it is, thanks.

Comment 4

[Brendan Eich [:brendan]]

Not s-s, #ifdef NARCISSUS shell only, doesn't affect even /usr/bin/js in any *BSD variant that shipped a shell.

/be

Comment 5

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: So, this fixes it?

I didn't bother adding another error message.

Comment 6

[Blake Kaplan (:mrbkap) (inactive)]

Fixed on trunk.

Comment 7

[Brian Crowder]

This is a good patch, but I don't think it fixes the actual bug which is the overflow in the JS_malloc() below.

Comment 8

[Blake Kaplan (:mrbkap) (inactive)]

Brian and I talked about this on IRC. Because JS_malloc takes a size_t, and len is an off_t (which is a signed type of the same size), the only number that could overflow is 0xffffffff, which is -1 as an off_t, so this patch does cover all cases.