Discussion Post

Discuss ROP and code injection.

Late yet again, probably later than I needed to be, but like Dr. Ford said this week at the beginning of the lecture, this was the week I was waiting for, and I had to get a little dirty and break some stuff.

Code injection typically refers to getting something (data) that is not machine code to run as code. Code injection tries to take control of a machine by gaining privilege, the privilege that code injection works to obtain is the ability to run binary code.

To understand code injection and buffer overflows understanding the stack is essential. Return-Oriented Programming (ROP) focuses on overwriting a buffer on the stack, which overwrites the return address and allowing the attacker to jump back onto the stack and execute an instruction, to prevent this, a few defense mechanisms have been developed. (Ford, 2018)

  • The no-execute flag marks something in makes memory non-executable. Data Execution Prevention (DEP) works by using the no-execute flag to prevent attackers from executing data as if it were code. Attackers are unable to execute code from the stack.
  • Address Space Layout Randomization (ASLR) works by randomly moving segments of a program around memory; this prevents the attacker from predicting gadget addresses.
  • Stack cookies (canaries) is a random value written to the stack immediately preceding the return address. Before the return address is executed the system checks to see if the canary has been overwritten, it the canary has been overwritten the system will trap execution.

ROP is based on the Return-to-Libc exploit technique but uses gadgets from different areas of memory to create an executable program.

ROP gadgets may look like:
0x1000b516 : pop eax ; pop ebp ; ret
0x10015875 : pop eax ; pop ebp ; ret 0x1c
0x1000ffe3 : pop eax ; pop ecx ; xchg dword ptr [esp], eax ; jmp eax
(apriorit, 2017)

While the widespread adoption of DEP which ensures that all writable pages in memory are non-executable has made classic code injection attacks difficult, ROP has become the approach for all modern attacks. Rather than injecting malicious code the attacker chains together existing code which already exists in the stack, these code snippets which are taken from the stack and are called gadgets. (TehAurum, 2015)

I was really interested in getting some hands-on experience here to see how this worked in the real world. A bit of googling and I happened across this website: https://samsclass.info/127/proj/lbuf1.htm – I fired up a Linux machine with Vagrant on my desktop and started playing.

Here is my ASLR example
Note:  I ran in debug mode to show all the commands.  Lines prefixed by the + symbol are input commands and lines with no prefix are output.
vagrant@vagrant-ubuntu-trusty-64:~$ sh -x aslr.sh
+ echo Let’s make sure ASLR is enabled
Let’s make sure ASLR is enabled
+ sudo tee /proc/sys/kernel/randomize_va_space
+ sudo echo 1
+ echo Let’s look at the C code that will print the esp (pointer) memory address
Let’s look at the C code that will print the esp (pointer) memory address
+ cat esp.c
#include <stdio.h>
void main() {
register int i asm(“esp”);
printf(“$esp = %#010x\n”, i);
+ echo Let’s compile the source code into an executable program
Let’s compile the source code into an executable program
+ gcc -o esp esp.c
+ echo Let’s execute the the binary executable esp three times
Let’s execute the the binary executable esp three times
+ ./esp
$esp = 0xd47931b0
+ ./esp
$esp = 0x5526d700
+ ./esp
$esp = 0xf7542b00
+ echo You can see that the memory address changes each time (ASLR at work here)
You can see that the memory address changes each time (ASLR at work here)
+ echo Let’s disable ASLR
Let’s disable ASLR
+ sudo tee /proc/sys/kernel/randomize_va_space
+ sudo echo 0
+ echo Lets’ execute the binary executable esp three more times
Lets’ execute the binary executable esp three more times
+ ./esp
$esp = 0xffffe620
+ ./esp
$esp = 0xffffe620
+ ./esp
$esp = 0xffffe620
+ echo You can see that now the memory ddress remaind the same each tiem (ASLR disabled)
You can see that now the memory ddress remaind the same each tiem (ASLR disabled)

I pushed on to more more complex exercises; these are both excellent ones:

A couple of pointers to get started:

  1. Get Virtualbox to build your sandbox. (https://www.virtualbox.org/wiki/Downloads)
  2. Download a Windows 7 Vbox image (https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/) to run the vulnserver executable you will get above on (note: get vulnserver.zip from the alternate link)
  3. Download Kali Linux for Vbox image (https://www.offensive-security.com/kali-linux-vm-vmware-virtualbox-hyperv-image-download/)

I left a bunch of stuff out like how to configure networking, getting going with Immunity Debugger, etc… but it’s about the journey, not the destination. Right?


Carlini, N., & Wagner, D. (2014, August). ROP is Still Dangerous: Breaking Modern Defenses. In USENIX Security Symposium (pp. 385-399).

Ford, R. (2018, May 23). Vulnerabilities: How Things Go Wrong, Part 2. Retrieved May 23, 2018, from http://learningmodules.bisk.com/play.aspx?xml=L0Zsb3JpZGFUZWNoTUJBL01HVDUxNTYvQ1lCNTI4ME04VjEvRGF0YS9tb2R1bGUueG1s

Shacham, H. (2007, October). The geometry of innocent flesh on the bone: Return-into-libc without function calls (on the x86). In Proceedings of the 14th ACM conference on Computer and communications security (pp. 552-561). ACM.

TehAurum. (2015, December 30). Exploit Development: Stack Buffer Overflow – Bypass NX/DEP. Retrieved May 25, 2018, from https://tehaurum.wordpress.com/2015/06/24/exploit-development-stack-buffer-overflow-bypass-nxdep/

apriorit. (2017, June 02). ROP Chain. How to Defend from ROP Attacks (Basic Example). Retrieved May 25, 2018, from https://www.apriorit.com/dev-blog/434-rop-exploit-protection


Discussion Response 1

Good post, given that you were interested in tips I thought I would respond with a toolkit for playing with buffer overflows and code injection.
The toolkit (assuming you are a Windows user):

  • Code:Blocks:  http://www.codeblocks.org/downloads/binaries
    • This is a good free C IDE and Compiler
    • Note:  Grab either codeblocks-17.12mingw-setup.exe or codeblocks-17.12mingw-nosetup.zip
    • Note:  To use the debugger you will need to set it up Setting -> Debugger -> Default, and enter path to gdb32 (on my system this is  path_to\codeblocks-17.12mingw-nosetup\MinGW\gdb32\bin\gdb32.exe but it will vary, just find gdb32.exe and enter full path here).  You will also need to make sure you create a project and add .c files to the project otherwise you won’t be able to debug.
  • OllyDbg:  http://www.ollydbg.de/ or IDA https://www.hex-rays.com/products/ida/support/download.shtml
    • Both good debuggers and disassemblers that will let you view the stack.

Some code to get started with:
/* vuln.c */
#include <stdlib.h>
#include <stdio.h>
#include <string.h>

int func (char *str)
char buffer[5];
strcpy(buffer, str);
return 1;
int main(int argc, char **argv)
char str[517];
FILE *inputfile;
inputfile = fopen(“inputfile.txt”, “r”);
fread(str, sizeof(char), 517, inputfile);
func (str);
printf(“Returned Properly\n”);
return 1;

– Create a text file called inputifile.txt and place at least 517 characters in it.
– Compile and execute vuln.c
– Set a breakpoint at main() and debug to see what happens.

Play around with the size of the read or write buffer:
By Changing the value of 5 in “char buffer[5]” in func() to 517
By changing the value of 517 “char str[5]” and “fread(str, sizeof(char), 5, inputfile)” in main() to 5

If you debug while you play you will start to see things happen.

Happy hacking!


Discussion Response 2

I’ve started doing some additional research and sandboxing because I am wondering about Return Oriented Programming (ROP) as a method to circumvent Address Space Layout Randomization (ASLR).  Need some hands-on time to really understand how gadgets can be chained given that the address space is randomized.

Doing some additional reading and experimenting to better understand the topic:

Anyway, I feel like I have a good handle on buffer overflows and ROP when ALSR is disabled.  I have played with this on Linux by disabling ASLR on Linux (sudo echo 1 | sudo tee /proc/sys/kernel/randomize_va_space) and when debugging I can see that instructions always reside in the same stack address.  OK, back to the sandbox.


Discussion Response 3

Sharing this link
All here is a good free sample from a Coursera and the University of Maryland that reviews much of what we spoke about this week. I found it helpful to reinforce the concepts so I am sharing with you.



Essay Assignment

Describe in detail code injection attacks and the countermeasures that exist to stop them. What future solutions are there?


Midterm Exam


Grade: 98%