User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:126.96.36.199) Gecko/20070225 BonEcho/188.8.131.52 Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:184.108.40.206) Gecko/20070225 BonEcho/220.127.116.11 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().
Assignee: nobody → general
Product: Firefox → Core
QA Contact: general → general
Seems unlikely an attacker could usefully get a user to download a 4Gb file, but I suppose it could compress to nearly nothing.
Assignee: general → crowder
Status: UNCONFIRMED → NEW
Ever confirmed: true
This is a shell-only bug, right? Doesn't affect the browser.
So it is, thanks.
Whiteboard: [sg:moderate] → [sg:nse] local exploit for js shell
Not s-s, #ifdef NARCISSUS shell only, doesn't affect even /usr/bin/js in any *BSD variant that shipped a shell. /be
Created attachment 267191 [details] [diff] [review] So, this fixes it? I didn't bother adding another error message.
Assignee: crowder → mrbkap
Status: NEW → ASSIGNED
Attachment #267191 - Flags: review?(brendan)
Attachment #267191 - Flags: review?(brendan) → review+
Fixed on trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
This is a good patch, but I don't think it fixes the actual bug which is the overflow in the JS_malloc() below.
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.
You need to log in before you can comment on or make changes to this bug.