Entendiendo una vulnerabilidad

Question

Entendiendo una vulnerabilidad

#1 de Polynomial (10 votos)

6

Tengo algunos problemas para entender este informe.

Por lo que he leído, parece que al eliminar ciertos nodos dom se produce un bloqueo de pestañas en Chrome.

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

¿Qué significa saltar a nulo? He intentado buscar información sobre él, pero no lo tengo muy claro.

Cualquier ayuda es muy apreciada.

chrome

pregunta Ayrx 29.05.2012 - 09:00

fuente

1 respuesta

Lea otras preguntas en las etiquetas chrome

Drupal disputado CVE Cinco años Tempestad - ¿Falta de seguridad de código abierto? ¿Cuánto cuenta la iteración de PBKDF2 desconocido para mejorar la seguridad?

score 10 · Accepted Answer

Hay dos vulnerabilidades, cada una de las cuales desencadena un salto a la dirección cero:

El primero, dentro de 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

Aquí está el volcado de ensamblaje en el eip que falla:

   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>

La instrucción call llama a la dirección en eax + 0xb0 , lo que implica que 0x02e294f8 es cero (ya que eax es 0x02e29448 ).

Aquí está el segundo, dentro de 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

Y el desmontaje en eip de nuevo:

   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

Esta vez, es eax + 0x24 , y eax es 0x02e29d38 , lo que nos da 0x02e29d5c . Esto implica que la memoria en 0x02e29d5c también es cero.

La distancia desde 0x02e294f8 a 0x02e29d38 (solo menos de 2KB) implica que hay dos asignaciones separadas a las que se accede aquí, por lo que definitivamente son ambos errores diferentes.

El patch diff para la corrección indica que se trata de un problema de uso después de que los objetos estaban siendo " fusionado "al mismo tiempo que se borra. Esto puede ser vulnerable a una condición de carrera, donde la memoria se desasigna, luego se vuelve a asignar en otro lugar de manera probabilística, luego se produce un error por este error, pero no puedo decirlo sin realmente profundizar en él.

Puede probar la explotabilidad haciendo muchas asignaciones de memoria en un bucle dentro de su JavaScript (la manipulación de cadenas es una buena) y luego causa la falla durante el bucle. Si se sobrescribe la memoria, el uso después de liberarse podría intentar saltar a algunos de los valores de su cadena.