This repository presents a newer version of the RIPE benchmark.
RIPE was originally developed by John Wilander and Nick Nikiforakis and the paper was presented at The 27th Annual Computer Security Applications Conference (ACSAC) in Orlando, Florida, December 5-9, 2011.
Originally, in 2011, the RIPE benchmark was developed for x86
architecture.
In 2018, Draper Labs realized a port for risc-V
architecture, called hope-RIPE
The RIPE port to RISC-V was developed by John Merrill. RIPE for RISC-V is designed for use with the Spike simulator.
Hubert Rosier realized a port for x86-64
, called RIPE64.
This port was developed by Hubert ROSIER for an academic project in the National University of Singapore. The project was supervised by Professor Roland YAP and co-supervisor senior research fellow Gregory James DUCK of the School of Computing of the National University of Singapore.
Gabriele Serra realized improved the benchmark implementing a hardware abstraction layer and re-implementing attacks for ARM 64 architecture.
The HAL and the
aarch64
port was developer by Gabriele Serra a PhD student at Scuola Superiore Sant'Anna, Pisa.
This repository aims at merge the best of all ports and let developers use a common repo for all architectures.
To build and run RIPE benchmark you need (at least) the following binaries/environments:
- python3 (for the frontend benchmark tool)
- gcc
- clang
To build the benchmark just run the make
command.
It will create the build
folder and two executable file in it.
Indeed executable files are compiled both using clang and gcc
By default, both binaries are compiled without stack protector (-fno-stack-protector
) and with executable stack (-z execstack
).
The RIPE testbed is based upon five attack parameters which combine to yield approximately 900 buffer overflow attacks.
To run a specific attack, you need to specify all the dimensions like this:
./build/[gcc|clang]_attack_gen -l location -c code_ptr -i inject_param -t [direct|indirect] -f func_abused [-d t]
where:
- location can be
stack
,heap
,bss
ordata
- code_ptr can be
ret
,baseptr
,funcptrstackvar
,funcptrstackparam
,funcptrheap
,funcptrbss
,funcptrdata
,structfuncptrstack
,structfuncptrheap
,structfuncptrbss
,structfuncptrdata
,longjmpstackvar
,longjmpstackparam
,longjmpheap
,longjmpbss
orlongjmpdata
- inject_params can be
nonop
,simplenop
,simplenopequival
,r2libc
orrop
- func_abused can be
memcpy
,strcpy
,strncpy
,sprintf
,snprintf
,strcat
,strncat
,sscanf
,fscanf
orhomebrew
The attacks is successful if a shell has been spawned.
The attack location describes the memory section in which the target buffer is located. RIPE supports attacks on the stack
, heap
, data
, and bss
sections.
// TODO
// TODO
Buffer overflows can be performed with or without indirection.
- The
direct
technique simply overwrites a target pointer in the same memory location as the overflow buffer. Direct, data-only attacks overwrite a target pointer with an integer value. - The
indirect
technique initially targets a generic pointer that is adjacent to the buffer. A dereference redirects this pointer to the attack code. Indirect overflows work between memory regions (i.e. from a stack buffer to a heap pointer).
There are nine vulnerable functions available as attack vectors:
str(n)cpy
,str(n)cat
,s(n)printf
, C library string functionsmemcpy
homebrew
, a loop-based, memcpy() equivalentsscanf
via a format string vulnerability
You can run all the possible attack forms by running the script ripe_tester.py
:
./ripe_tester.py [direct|indirect|both] n (gcc|clang|both) (VERBOSE_OPTIONS)
It accepts at least 2 pararameters, the first one to launch direct attacks, indirect or both; the second is the number of times each attack should be launched. The other parameters are optional, the third parameter specifies to use the gcc or clang executables or both.
The last one controls the output format:
--only-ok
: only prints the functional attacks--only-some
: only prints the partly functional attacks--only-fail
: only prints the non-functional attacks--no-ok
: don't print the functional attacks--no-fail
: don't print the non-functional attacks--only-summary
: only prints the summary--format-bash
(default): prints the summary in plain text--format-latex
: prints the summary as a latex table--format-bash-latex
: prints the summary in plain text and as a latex table
RIPE produces and performs a series of exploits based on its five attack parameters:
- technique
- attack code
- target code pointer
- memory location
- vulnerable function.
The result log generated by the frontend labels each test as one of the following:
OK
: the attack executes successfullyFAILED
: the attack encounters an error before running to completionSOME
: attacks that didn't succeed each roundNOT POSSIBLE
: the attack is not practically possible (eg. a direct attack on a stack buffer targeting a global pointer)
Address Space Layout Randomization is a computer security technique that randomly arranges the address space positions of key data areas of a process, including the base of the executable and the positions of the stack, heap and libraries. ASLR makes a number of attacks unfeasible.
ASLR can be disabled temporary with:
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
Ropper can find gadgets to build rop chains for different architectures. It was used before the wanted gadgets were hardcoded in functions.
The one byte NOP equivalent sled has been generated using the metasploit framework with the command:
generate 40 -s rsp -t c
the -s rsp
tells that we don't want to change the RSP register (I got errors without).
Shellcodes can be find anywhere on the internet. However, a good place to start finding shellcodes is ShellStorm. Shellcodes are grouped by architecture.
RIPE was originally released under the MIT licence. Subsequent modification and porting to other architectures were still released under the MIT license.
If you use, extend or build upon RIPE we kindly ask you to cite the original ACSAC paper in which RIPE is presented. Here's the BibTeX:
@inproceedings{ wilander.ripe,
author = {John Wilander and Nick Nikiforakis and Yves Younan and Mariam Kamkar and Wouter Joosen},
title = {{RIPE}: Runtime Intrusion Prevention Evaluator},
booktitle = {In Proceedings of the 27th Annual Computer Security Applications Conference, {ACSAC}},
year = {2011},
publisher = {ACM}
}
May your buffer overflow protection prove ripe!