0

I'm trying to bypass ASLR with NOP sled. Here's the assembly for vuln(), sorry I don't have the source code:

0804878a <vuln>:
 804878a:   55                      push   %ebp
 804878b:   89 e5                   mov    %esp,%ebp
 804878d:   53                      push   %ebx
 804878e:   81 ec a4 00 00 00       sub    $0xa4,%esp
 8048794:   e8 77 fe ff ff          call   8048610 <__x86.get_pc_thunk.bx>
 8048799:   81 c3 67 18 00 00       add    $0x1867,%ebx
 804879f:   83 ec 0c                sub    $0xc,%esp
 80487a2:   8d 85 64 ff ff ff       lea    -0x9c(%ebp),%eax
 80487a8:   50                      push   %eax
 80487a9:   e8 52 fd ff ff          call   8048500 <gets@plt>
 80487ae:   83 c4 10                add    $0x10,%esp
 80487b1:   83 ec 0c                sub    $0xc,%esp
 80487b4:   8d 85 64 ff ff ff       lea    -0x9c(%ebp),%eax
 80487ba:   50                      push   %eax
 80487bb:   e8 80 fd ff ff          call   8048540 <puts@plt>
 80487c0:   83 c4 10                add    $0x10,%esp
 80487c3:   8b 83 fc ff ff ff       mov    -0x4(%ebx),%eax
 80487c9:   8b 00                   mov    (%eax),%eax
 80487cb:   83 ec 0c                sub    $0xc,%esp
 80487ce:   50                      push   %eax
 80487cf:   e8 1c fd ff ff          call   80484f0 <fflush@plt>
 80487d4:   83 c4 10                add    $0x10,%esp
 80487d7:   90                      nop
 80487d8:   8b 5d fc                mov    -0x4(%ebp),%ebx
 80487db:   c9                      leave  
 80487dc:   c3                      ret   

The binary is 32-bit, and the stack is executable, so I decide to use NOP sled. My payload is as follows:

'A'*160 + return address + '\x90'*1024 + shellcode

If my understanding is right, if I run the exploit many times there is chance that the return address may point to somewhere in the NOP sled, which will cause the processor to execute my shellcode.

However, I don't know how to approximate the return address. I try gdb the binary, it tells me the original return address is 0xfc3fc758 so I just use that value. When I feed the payload to the binary, it just exit with SIGSEGV.

[*] Process './vuln5' stopped with exit code -11 (SIGSEGV) (pid 9240)

After some debugging I found that the segfault is thrown when vuln() returns, so I try feeding junk bytes only to see what happens. It turns out that any padding longer than 152 bytes will cause the segfault, but I don't know why. I think 160 bytes must be correct since the assembly tells that the buffer begins at ebp-0x9c.

So am I using the NOP sled correctly? And how can I approximate the return address?

null
  • 57
  • 1
  • 7
  • If ASLR is enabled the preferred method is to either find gadgets to perform ROP or find a way to leak the stack pointer. Bruteforcing addresses isn't a viable solution. It might work if you're lucky enough though. – ShellCode Mar 29 '21 at 10:15

1 Answers1

0

Using GDB, you can check what address the program tries to return to. This will let you know if you are overwriting the stored return address with the desired value.

As for defeating ASLR, while there is a possibility that your stack is placed somewhere that allows your exploit to succeed, this highly unlikely. Also, because pages are aligned to 0x1000, your NOP sled likely wont increase the odds of you landing in your shellcode.

The NOP sled is typically used when the location of the stack isn't randomized, but you do not necessarily know the offset to your shellcode. This often happens due to different environment variable sizes between your local machine and the remote server.

In this case, with ASLR on, you'll need to leak a stack address to determine where to jump if you want your shellcode to work. Alternatively, there are other methods that will allow you to exploit this program. Seeing the call to <puts@plt>, ret2libc comes to mind.

Green-Avocado
  • 901
  • 5
  • 20