Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am having a little bit of trouble understanding this report.

From what i have read, it appears as though removing certain dom nodes triggers a tab crash within chrome.

When removing certain nodes, a jump to null is triggered in each of the two cases. 

What does jump to null mean? I have tried searching up on information on it, but it isn't really clear to me.

Any assistance is very much appreciated.

share|improve this question
my guess is jmp 0x00000000 – Dog eat cat world May 29 '12 at 9:32
Not far from it, and it earned the reporter $2000. Nice. – Polynomial May 29 '12 at 13:22
up vote 10 down vote accepted

There are two vulnerabilities, each triggering a jump to address zero:

The first, inside markContainingBlocksForLayout:

  Program received signal SIGSEGV, Segmentation fault.
  [Switching to Thread 0xb09fdb70 (LWP 2039)]
> 0x00000000 in ?? ()
  (gdb) bt
> #0  0x00000000 in ?? ()
  #1  0x0194b82b in markContainingBlocksForLayout (this=0x2e29944, owner=
      0x2e298e4, oldChild=0x0, fullRemove=true)
      at third_party/WebKit/WebCore/rendering/RenderObject.h:946

Here's the assembly dump at the faulting eip:

   0x0194b81b <removeChildNode(...)+1083>:  decl   -0x74ffd98c(%ebp)
   0x0194b821 <removeChildNode(...)+1089>:  push   %es
   0x0194b822 <removeChildNode(...)+1090>:  mov    %esi,(%esp)
   0x0194b825 <removeChildNode(...)+1093>:  call   *0xb0(%eax)
=> 0x0194b82b <removeChildNode(...)+1099>:  test   %al,%al
   0x0194b82d <removeChildNode(...)+1101>:  jne    0x194b67d <removeChildNode(...)+669>
   0x0194b833 <removeChildNode(...)+1107>:  mov    -0x24(%ebp),%edi
   0x0194b836 <removeChildNode(...)+1110>:  mov    -0x28(%ebp),%esi
   0x0194b839 <removeChildNode(...)+1113>:  jmp    0x194b728 <removeChildNode(...)+840>

The call instruction calls to the address at eax + 0xb0, which implies that 0x02e294f8 is zero (since eax is 0x02e29448).

Here's the second one, inside RenderObject::destroy:

  Program received signal SIGSEGV, Segmentation fault.
  [Switching to Thread 0xb1646b70 (LWP 2100)]
> 0x00000000 in ?? ()
  (gdb) bt
> #0  0x00000000 in ?? ()
  #1  0x0194387f in WebCore::RenderObject::destroy (this=0x2e29cc4)
      at third_party/WebKit/WebCore/rendering/RenderObject.cpp:2152

And the disassembly at eip again:

   0x0194386f <WebCore::RenderObject::destroy()+15>:    xchg   %eax,%ebx
   0x01943870 <WebCore::RenderObject::destroy()+16>:    incb   0x3dd4a3c3(%ecx)
   0x01943876 <WebCore::RenderObject::destroy()+22>:    add    %ecx,0x24348906(%ebx)
   0x0194387c <WebCore::RenderObject::destroy()+28>:    call   *0x24(%eax)
=> 0x0194387f <WebCore::RenderObject::destroy()+31>:    test   %eax,%eax
   0x01943881 <WebCore::RenderObject::destroy()+33>:    je     0x194388b <WebCore::RenderObject::destroy()+43>
   0x01943883 <WebCore::RenderObject::destroy()+35>:    mov    %eax,(%esp)
   0x01943886 <WebCore::RenderObject::destroy()+38>:    call   0x194a680 <WebCore::RenderObjectChildList::destroyLeftoverChildren()>
   0x0194388b <WebCore::RenderObject::destroy()+43>:    mov    0x8(%esi),%eax
   0x0194388e <WebCore::RenderObject::destroy()+46>:    mov    0x14(%eax),%eax

This time, it's eax + 0x24, and eax is 0x02e29d38, giving us 0x02e29d5c. This implies that the memory at 0x02e29d5c is also zero.

The distance from 0x02e294f8 to 0x02e29d38 (just less than 2KB) implies that there are two separate allocations being accessed here, so they're almost definitely both different bugs.

The patch diff for the fix indicates that this is a use-after-free issue, where objects were being "merged" at the same time as being deleted. This may be vulnerable to a race condition, where the memory is deallocated, then re-allocated elsewhere in a probabilistic fashion, then jumped to by this bug, but I can't tell without really digging into it.

You could test the exploitability by doing a lot of memory allocations in a loop within your JavaScript (string manipulation is a good one) and then causing the fault during the loop. If the memory is overwritten, the use-after-free might attempt a jump to some of your string's value.

share|improve this answer
Very clear explanation of the vulnerability! Thanks! – Terry Chia May 29 '12 at 13:23
Glad it helped. I might have a real play with it tonight to see what I can come up with as far as a PoC exploit goes. – Polynomial May 29 '12 at 13:27

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.