Exploit Stack Based desbordamiento de búfer (x64) mientras se controla el registro rbx

1

Puedo controlar estos registros:

(gdb) i r
rax            0x1  1
rbx            0x4141414141414141   4702111234474983745
rcx            0x7ffff760cf90   140737343704976
rdx            0x49526df7d355ee04   5283406224028986884
rsi            0x1  1
rdi            0x7fffffffce00   140737488342528
rbp            0x49526df7d355ee04   0x49526df7d355ee04
rsp            0x49526df7d355ee04   0x49526df7d355ee04
r8             0x49526df7d355ee04   5283406224028986884
r9             0x49526df7d355ee04   5283406224028986884
r10            0x8  8
r11            0x246    582
r12            0x4141414141414141   4702111234474983745
r13            0x4141414141414141   4702111234474983745
r14            0x4141414141414141   4702111234474983745
r15            0x4141414141414141   4702111234474983745
rip            0x7ffff760cbbe   0x7ffff760cbbe <__longjmp+78>
eflags         0x10202  [ IF RF ]
cs             0x33 51
ss             0x2b 43
ds             0x0  0
es             0x0  0
fs             0x0  0

¿Puedo controlar de alguna manera estos pensamientos? Particularmente cuando controlo rbx?

Todos los ejemplos que encontré fueron donde se controló el rbp y cómo hacerlo está claro para mí. Descrito por ejemplo, aquí

Actualización 1:

Tal vez eso ayude, desmonté la función a la que se llama después de modificar los registros:

(gdb) disass png_error
Dump of assembler code for function png_error:
=> 0x00007ffff7bcf280 <+0>: push   %r12
   0x00007ffff7bcf282 <+2>: push   %rbp
   0x00007ffff7bcf283 <+3>: mov    %rsi,%rbp
   0x00007ffff7bcf286 <+6>: push   %rbx
   0x00007ffff7bcf287 <+7>: mov    %rdi,%rbx
   0x00007ffff7bcf28a <+10>:    sub    $0x30,%rsp
   0x00007ffff7bcf28e <+14>:    mov    %fs:0x28,%rax
   0x00007ffff7bcf297 <+23>:    mov    %rax,0x28(%rsp)
   0x00007ffff7bcf29c <+28>:    xor    %eax,%eax
   0x00007ffff7bcf29e <+30>:    test   %rdi,%rdi
   0x00007ffff7bcf2a1 <+33>:    je     0x7ffff7bcf2c6 <png_error+70>
   0x00007ffff7bcf2a3 <+35>:    mov    0x120(%rdi),%rcx
   0x00007ffff7bcf2aa <+42>:    test   $0xc0000,%ecx
   0x00007ffff7bcf2b0 <+48>:    jne    0x7ffff7bcf318 <png_error+152>
   0x00007ffff7bcf2b2 <+50>:    mov    0xc8(%rbx),%rax
   0x00007ffff7bcf2b9 <+57>:    test   %rax,%rax
   0x00007ffff7bcf2bc <+60>:    je     0x7ffff7bcf2c6 <png_error+70>
   0x00007ffff7bcf2be <+62>:    mov    %rbp,%rsi
   0x00007ffff7bcf2c1 <+65>:    mov    %rbx,%rdi
   0x00007ffff7bcf2c4 <+68>:    callq  *%rax

¿Alguna idea de cómo controlar rip?

    
pregunta android_dev 01.03.2016 - 19:56
fuente

1 respuesta

2

Lo que puede hacer cuando controla un registro depende de lo que haga el código atacado con ese registro. Por lo tanto, es difícil hacer una respuesta genérica.

En el x86-64 ABI , el registro %rbx es uno de los registros que el destinatario debe conservar, por lo que si una función utiliza %rbx , primero debe guardarla y restaurarla al salir. Una consecuencia es que la mayoría de las funciones no usarán %rbx si pueden evitarlo. En el ABI de 32 bits, el registro %ebx se usa normalmente para guardar la dirección de la GOT (la tabla base que se utiliza para hacer el enlace dinámico), por lo que la modificación de %ebx posiblemente permitiría jugar con las siguientes llamadas de función; pero en el ABI de 64 bits, el código PIC generalmente utiliza Direccionamiento relativo a RIP , que no usa %rbx .

Para ver qué puede hacer con %rbx en una situación específica, realmente tiene que desensamblar el código atacado y ver cómo usa ese registro (o no) en las instrucciones después de su modificación.

    
respondido por el Tom Leek 01.03.2016 - 20:25
fuente

Lea otras preguntas en las etiquetas