Post Memory Corruption Memory Analysis

Jonathan Brossard - [email protected]

Security Research Engineer & CEO, Toucan System, France

Blackhat Briefings Conference, Las Vegas, 2011

"Normality is the route to nowhere." Ridderstrale and Nordstorm

Abstract. In this article, we introduce a new exploitation methodology of invalid memory reads and writes, based on dataflow analysis after a memory corruption bug has occurred inside a running process.

We will expose a methodology which shall help writing a reliable exploit out of a PoC triggering an in- valid memory write, in presence of modern security defense mechanism such as compiler enhancements (such as SSP...), lib protections (eg: safe heap unlinking), linking and dynamic linking enhancements (full read only GOT and relocations) or kernel anti exploitation features (ASLR, NX...).

In particular, we will demonstrate how to : nd all the function pointers inside a running process, how to determine which ones would have been dereferenced after the Segmentation fault if the process had kept executing, which ones are truncatable (in particular with 0x00000000). In ase all of the above fail, we will demonstrate how to test for overwrites in specific locations in order to indirectly trigger a second vulnerability allowing greater control and eventually full control ow hijacking. All of the above without needing the source code of the application debugged.

In the case of invalid memory reads, we will show how to indirectly influence the control flow of execution by reading arbitrary values, how to trace all the unaligned memory access and how to test if an invalid read an be turned into an invalid write or at least used to infer the mapping of the binary.

We will also introduce a new debugging technique which allows for very exaustive dynamic testing of all of the above by forcing the debugged process to fork(). All those steps are realized automatically and provide a rating of the best read/write location based on probabilities of mapping addresses (in the hope to defeat ASLR).

These techniques were implemented in the form of a proof of concept tool running under GNU/Linux and Intel architectures : pmcma1.

Keywords: Exploit automation, post memory corruption analysis, debugging, memory protections, in- valid memory writes.

1The official website of the tool is http://www.pmcma.org

1Introdu tion

Determining exploitability is hard, and writing exploits is hard. In fa t, due to theoreti al limitations (id est: "Halting Problem"), those two problems are the two sides of the same oin. Proving unex- ploitability is infeasible in the general ase, and pra ti ally for the vast majority of omputer programs a tually used nowadays.

In this paper, we will examine exploitability in a systemati way, fo using on what happens in memory after a bug is triggered, rather than tra ing or ba ktra king what has happened before. To the best of the author's knowledge, this is a new approa h.

Our goal is to help exploit (semi)automation by building exploitation models based on onstraints gath- ered from the environment (in parti ular, the presen e of se urity ountermeasures su h as ALSR[1℄ or non-exe utable memory[2℄ thanks to kernel[3℄ or hardware[4℄ enhan ements, as well as ompiler enhan ements su h as Data Hardening[5℄, FORTIFY SOURCE[6℄ et ), and to allow for the pra ti al testing of those models in order to (in)validate them.

We will primarily fo us on invalid memory write bugs be ause of the spe ial role they play in modern exploitation. Invalid memory dereferen es in read mode used for the purposes of information leakage or indire t memory exploitation will also be dis ussed in this arti le.

The main ontributions of this arti le are:

-A methodology to dis over all the potential fun tion pointers inside the address spa e of a pro ess at any given point in time.

-A methodology to dis over all the fun tion pointers a tually dereferen ed by a pro ess from a given point in time, given a xed set of input data.

-A methodology to nd all the fun tion pointers exploitable by trun ation in ase of an arbitrary write subje t to onditions (su h as not ontrolling the value being dereferen ed).

-A methodology to nd all the unaligned memory reads from a given point in time during the exe ution of a pro ess.

-A new debugging te hnique whi h allows the validation of all of the above, as well as the testing of arbitrary data modi ations inside the address spa e of a pro ess in order to a hieve ontrol ow hija king from an arbitrary memory write.

All those te hniques have been implemented in the form of a proof of on ept tool for the GNU/Linux x86 Intel ar hite tures. They ould, without any loss of generality, be extended to any operating system or ar hite ture with the ex eption of the last debugging te hnique, whi h requires the presen e of the fork() system all and is therefore limited to *NIX operating systems2.

This parti ular debugging te hnique doesn't require the debugged pro ess to be restarted using ex- e ve(), and therefore preserves most of the mapping of the appli ation (whi h may be hard to re- reate be ause of the large entropy used in randomizing a pro ess' address spa e under modern OSes). This te hnique is also believed to be the most ee tive to a hieve this result (by onstru tion) both in terms of speed and resour es.

Finally, sin e overwriting fun tion pointers doesn't allow dire t shell ode exe ution anymore be ause of

W ˆX mappings, we introdu e a new exploitation te hnique whi h works even under the most se urity enhan ed kernels su h as grse urity. We all it "sta k desyn hronization". It allows frame faking inside the sta k itself by having a ontrolled fun tion pointer return to a arefully hosen fun tion prologue instead of returning to a shell ode dire tly.

It is worth noting that we do not seek full exploit generation in this whitepaper, the output of our tool

2A tually, Se urity Resear her Mark Dowd made us aware that it may be possible to simulate a fork() under Windows too... Implementation details would be non trivial though, sin e the pro ess reation me hanism is entirely dierent.

3

being a roadmap to exploitation rather than exe utable (or sour e) ode. This roadmap needs to be implemented using both ontrol ow and data ow analysis of the pro ess prior to the bug, whi h is fortunately what virtually any existing debugging tool is apable of a omplishing.

2Related work

Be ause of the theori al limitations invoked previously, earlier resear h on automati exploitation tend to fo us on numeri al rather than analyti al solutions. It is indeed less intelle tually satisfying (it an- not be proved that a solution will a tually be found in general), but interresting results have been a hieved nonetheless.

More pre isely, they all share a ommon underlying methodology : starting from a given program input leading to a deterministi memory orruption, they express the onstraints on the input data in order to have it keep following the very same path (otherwise we're ba k to the Halting Problem and in pra ti e to path exploration explosion), then turn ea h instru tion into a set of onstraints, express the desired result (id est: register set when re eiving a Segmentation fault) in terms of the same onstraints. Then they solve the equation numeri ally. Both taint analysis at assembly level (whether an intermediary language is used[7℄ or not[8℄) and SAT Solvers[9℄[10℄ used on onstraints expressed from C sour e seem to give satisfying results in pra ti e, eventually modifying the input data to lead to the expe ted set of registers when triggering the bug, thereby leading to exe ution of arbitrary ode.

Unfortunately, in pra ti e the exploits reated using the aforementioned te hniques often do not work under realisti modern operating systems, in parti ular be ause the " omplete exploits" generated au- tomati ally omit to take into a ount the additional omplexity brought by se urity prote tions su h as non-exe utable memory pages or Address Spa e Layer Randomization (ASLR).

If those te hniques seem to give interesting results on simple vulnerabilities su h as sta k overows under basi onditions (no sta k anaries, no address spa e layer randomization and all se tions being exe utable), they annot ope with more omplex vulnerabilities su h as heap overows (overwriting heap meta-data typi ally require having multiple memory lo ations set to appropriate values in order to pass the various lib he ks before a hieving a proper arbitrary write in memory) nor do they work with modern Operating Systems, whi h have enhan ed kernels and ompiler tool hains to prevent triv- ial exploitation.

In reality, dealing with those se urity prote tions is in itself what most se urity resear hers and ha kers alike a tually spend their time on when writing exploits. It requires their exploitation methodologies to be environment-aware, those prote tions being implemented at dierent levels, ranging from ompiler tool hains enhan ements[6℄ to kernel modi ations[11℄.

In the rest of this arti le, we will fo us on what happens inside a pro ess after it triggered a Seg- mentation Fault , assuming that the ontrol ow and data ow analysis of input data leading to this Segmentation Fault, whi h are still the mandatory steps to determine exploitability, an be performed using ommonly available tools (gdb, valgrind, dmallo , ele tri fen e,...).

4

3mk_fork() : writing "weird debuggers" for "weird programs"

3.1Motivation

An arbitrary anything/anywhere write allows an atta ker to overwrite arbitrary data in se tions mapped with writable permissions. In order to a hieve ontrol ow modi ation to exe ute arbitrary ode, the most straight forward te hnique is to overwrite a fun tion pointer that will later be dereferen ed during the normal ow of exe ution.

Depending on the target binary, a few su h pointers may be known without further reverse engineering. In fa t, appli ations linked against the GNU lib library ontain de fa to su h a pointer : the fun tion pointer asso iated with the .dtors se tion. This pointer has long been used[12℄ to exe ute arbitrary ode instead of the legitimate glib destru tors in ase of arbitrary write vulnerabilities, parti ularly when exploiting missing format string vulnerabilities lo ally.

This parti ular te hnique, while popular in the early 2000's, has several limitations. First of all, it assumes the appli ation will exit leanly by alling exit(). If the atta ker is unable to pursue normal exe ution mu h longer after triggering the vulnerability (fairly ommon in ase of heap overows, where heap metadata is irre overably orrupted and will sooner or later for e the appli ation to quit by alling abort() instead of exit(), hen e not alling the normal destru tors), the aforementioned fun tion pointer will not even be dereferen ed.

Se ondly, a hieving arbitrary remote exe ution when the appli ation is exiting may be a bit late. If the atta ker was to atta k a remote servi e whi h typi ally only alls exit() when the server shuts down (whi h may literally take years), this atta k ve tor may not be interesting at all. A arefully oded setuid appli ation may also hose to drop privileges before exiting, hen e wasting the atta k ve tor for a lo al atta ker.

Thirdly, guessing the lo ation of the .dtors se tion, while easy if the binary wasn't ompiled as a PIE is not immediately given in the opposite ase, be ause the data se tion of the binary is then randomized. Finally, the appli ation may not be linked with glib at all (use of ulib for instan e), in whi h ase, this fun tion pointer is simply not available. In any ase, it is possible to modify the linking pro ess through a s ript[?℄ to make the .dtors se tion non writable, whi h mitigates this atta k ve tor ompletely. This is a eptable for the vast majority of appli ations sin e the use of ustom destru tors is in fa t not widespread.

The se ond popular te hnique is to overwrite a pointer in the Global Oset Table (GOT). When alling pro edures whose ode is stored in separate obje ts su h as shared libraries, the lazy dynami linking rst transfers ontrol to the Pro ess Linkage Table (PLT), whi h is a trampoline to the GOT. Over- writing the GOT entry to say, printf() would allow an atta ker to modify the ow of exe ution to an arbitrary lo ation when printf() would later be alled anywhere within the appli ation. This te hnique is also attra tive sin e binaries not ompiled as Position Independent Exe utables (PIE) have their GOT stored at a x lo ation.

Unfortunately for the atta ker, re ent[5℄ modi ations to the linker and dynami linker allow3 for the relo ations to be performed entirely during the loading pro ess. Sin e the GOT is then fully resolved, it an be set read only by a simple all to mprote t(). The net result is that an atta ker annot write to the GOT at all anymore, hen e mitigating this atta k ve tor entirely. This early binding omes at a performan e ost (lazy binding no longer applies, and even referen es that would not have been used during a spe i run of the appli ation are resolved anyways), and is therefore not applied sys- temati ally to all binaries under all Linux distributions. That being said, it is absolutely possible to

3When ompiling appli ations using g , and zith the following ags: "-Wl -z relro -z now". Using only "-Wl -z relro " allows for internal reorganization of the se tions of the binary, putting the GOT before writable se tions su h as

.data and .bss. This prevents GOT overwriting in ase of user ontrolled buer overows in those writable se tions. Adding the "-z now" option also for es relo ations to be performed at load time, and enfor e a all to mprote t() to render the GOT unwritable.

5

reate a tool hain that would enfor e those linking options to all the binaries in the system, ee tively killing this atta k ve tor entirely. The Gentoo Hardened distribution is su h an instan e of a distri- bution that privileged se urity over performan e by enfor ing this new feature by default on all binaries.

An other pointer prior resear hers used in the past is the array of pointers alled by at_exit(). While it has been shown[13℄ that overwriting a double word in this glib global data ould grant arbitrary ode exe ution, appli ations a tually using at_exit() tend to be fairly rare. The virtue of this example is generalize the overwrite of fun tion pointers not only in the mapping of the appli ation itself, but also in the writable mappings of the libraries it is linked to. In a way, the present paper an be seen as an extreme generalization of this te hnique.

If deferen ing a fun tion pointer is indeed a good idea, publi ly available debuggers do a poor job at listing them. This is understandable sin e what happens inside an appli ation after a Segmentation Fault is of little interest to normal software developers, whose fo us is to x bugs, not to write exploits. We will therefore without further due introdu e a te hnique to automati ally dete t all the fun tion pointers possibly dereferen ed by an appli ation (in luding its libraries) after a given memory orrup- tion bug has o urred.

3.2Methodology

Our methodology is based on the use of ptra e() to debug a pro ess. We start by either atta hing to a running pro ess thanks to its pid, or reate a new pro ess from the ommand line of pm ma.

We then wait for the pro ess to rash, emitting a Segmentation Fault aught by ptra e(). This indeed assumes that the user of the pm ma is able to reate an input to reate an invalid memory a ess inside the pro ess.

On any given pro ess, the amount of mapped memory is limited by ar hite ture onstraints. In order to verify if overwriting4 a given double word in memory will in fa t modify the ow of exe ution, we start by listing all the memory lo ations that are writable (we annot modify non writable lo ations anyway). This preliminary phase is performed on a memory snapshot, but performing it after a Segmentation Fault allows us to have a binary whi h looks (in memory) exa tly like the pro ess we'd like to exploit from a mapping point of view.

We then for e the debugged appli ation to fork(). This reates a new pro ess whi h only diers from the original debugged pro ess by its pro ess id. In parti ular, all the writable memory lo ations in luding the heap, or even global data from all the mapped libraries remain exa tly the same.

We then overwrite a given writable lo ation with a dummy value orresponding to a lo ation non- exe utable in userland inside the newly reated pro ess (therefore leaving the original pro ess inta t, for later use). 0xf1f2f3f4 is a good su h value5. We then lear the signals re eived by the newly spawned pro ess and follow its exe ution as if a Segmentation Fault didn't just happen.

In ase exe ution is transfered to memory lo ation 0xf1f2f3f4 before the appli ation exits, we have found a proper fun tion pointer a tually dereferen ed by the appli ation. This is easily dete table as it will trigger a SIGSEGV signal (the Segmentation Fault being due to an attempt to exe ute ode in a lo ation normally reserved to ring 0).

If su h is not the ase, we repeat the pro ess of for ing the original debugged pro ess to fork() and overwrite an other memory lo ation with the same dummy pointer.

4 simulating the fa t that the previous ins tru tion triggering the Segmentation Fault had led to an arbitrary memory write instead of simply triggering a SEGFAULT...

5 It is both always pointing to kernel land, regardless of the kernel split in use, and easy to identify.

6

By iterating this way over all of the possible writable memory lo ations, we an nd all the fun tion pointers dereferen ed by the appli ation during its normal ow of exe ution.

3.3mk_fork() implementation

Previous works[14℄[15℄ have shown it was possible to use ptra e to inje t an arbitrary library inside the pro ess' address spa e. We don't need that mu h, we'll just inje t a small shell ode for ing the pro ess to all fork, and start ptra ing the hild.

Let's see how this an be a hieved (ignoring error handling here and unne essary omplexity for the sake of larity):

/*

*

*for e a pro ess to fork()

*returns the pid of the offspring

*/

int mk_fork(pid_t pid){

void *target_addr;

stru t user_regs_stru t regz; stru t user_regs_stru t regs; stru t user_regs_stru t regz_new; int status;

siginfo_t si;

stru t w_to_x_ptr *tmp4; int newpid;

int fork_ok=0,offspring_ok=0;

/*

*prepare hild to perform a fork

*/

// save registers

ptra e(PTRACE_GETREGS, pid,NULL, ®z); mem py(®z_new,®z,sizeof(regz));

// ba kup ontent at addr

getdata(pid, (int)target_addr, ba kup_buff, 200);

// repla e with fork_stub shell ode

write_data(pid,(int)target_addr,fork_stub,10);

// exe ute fork_stub

regz_new.eip=(int)target_addr+2; ptra e(PTRACE_SETREGS, pid,NULL, ®z_new);

/*

*Continue ptra ing untill we get both a

*SIGTRAP (parent) or SIGSTOP ( hild)

7

*/

fork_ok=0; offspring_ok=0; while((!fork_ok)&&(!offspring_ok)){

memset(&si, 0, sizeof(siginfo_t));

ptra e(PTRACE_GETREGS, pid,NULL, ®s); ptra e(PTRACE_SETREGS, pid,NULL, ®s);

ptra e(PTRACE_CONT, pid, NULL, NULL); waitpid(-1,&status,P_ALL); // any pid ptra e(PTRACE_GETSIGINFO, pid, NULL, &si);

// parent ?

if(si.si_signo == 5){ fork_ok=1;

}

// offspring ?

if (status >> 16 == PTRACE_EVENT_FORK) { ptra e(PTRACE_GETEVENTMSG, pid, NULL, (void*) &newpid); ptra e(PTRACE_SYSCALL, newpid, NULL, NULL);

}

}

/*

*Clean up the mess

*/

// lear signals

memset(&si, 0, sizeof(siginfo_t)); ptra e(PTRACE_SETSIGINFO, pid, NULL, &si); ptra e(PTRACE_SETSIGINFO, newpid, NULL, &si);

// restore data

write_data(pid,(int)target_addr,ba kup_buff,200); write_data(newpid,(int)target_addr,ba kup_buff,200);

// restore registers

ptra e(PTRACE_SETREGS, pid, NULL, ®z); ptra e(PTRACE_SETREGS, newpid, NULL, ®z);

return newpid;

}

With fork_stub being a small shell ode6 :

;forking shell ode:
00000000	6631C0	xor eax,eax
00000003	B002	mov	al,0x2
00000005	CD80	int	0x80

followed by 4 bytes 0x whi h will trigger a signal 5 (SIGTRAP) when exe uted.

6The shell odes in this paper will be given assuming a 32b intel ar hite ture for illustrative purpose.

8

The operations performed are therefore the following : rst of, the state of the registers of the de- bugged appli ation are saved. Then, 10 bytes from the debugged pro ess are ba ked up, starting from target_addr (whi h is the pla e we will use to write and exe ute our small shell ode. This lo ation needs to be mapped in an exe utable lo ation). Our small shell ode is then inje ted inside the running pro ess. Registers are then modied in the debugged pro ess so that the next instru tion to be exe uted will be our shell ode, and ontrol is passed to this appli ation. Upon orre t exe ution of this shell ode, we will re eive two signals : a SIGTRAP emitted by the debugged pro ess, and a SIGSTOP emitted by its newly reated ospring. We then restore the 10 bytes ba ked up earlier in both pro esses and restore their registers to the their original state.

This way, we obtain an almost perfe t repli a of our original pro ess to experiment with at will.

3.4Limitations

.

The main limitation is that all of the Inter Pro ess Communi ation (IPC) and le I/O an be assumed to be in unpredi table state in the ontext of the ospring. The return of any sys all is in fa t un- predi table. This may ause dieren es in the exe ution of the original pro ess and the ospring. In parti ular, this may ause the ospring to exit earlier than the original pro ess would have be ause of IPC or sys all errors, leading to false negatives in our analysis.

Experimentally, this experimental te hnique works well enough to provide rea hable fun tion pointers alled, even though it still misses many that would exist mu h later in the ow of exe ution.

The system alls ould probably be re orded in the original pro ess and faked in osprings to remove those problems entirely, thanks fo the ptra e() method PTRACE_SYSCALL. And a further ost in performan e. This idea is further des ribed later in this whitepaper under se tion 6.5.

4Here be dragons : zombie reaping

The previously des ribed methodology to reate pro esses is indeed powerful, but reating unexpe ted hildren to a pro ess poses several problems if we intend to debug large appli ations su h as network servi es or web browsers. In this later ase, we will need to analyze megabytes of writable data, hen e reate millions of hildren. In order to s ale under those proportions, dealing with the termination of the reated osprings is mandatory.

4.1Dealing with SIGCHLD

Sin e the original appli ation will be kept sleeping while we will reate thousands if bot millions of hildren to test writes in dierent lo ations, it won't be able to wait() for the return signal (SIGCHLD) emitted by ea h hild pro ess reated when exiting. If we don't solve this situation, all those unre eived signals will prevent the hild pro esses from a tually terminating, leaving them in a zombie state.

First of, this is a waste of memory and pu y les be ause the zombies still have an entry in say, task_stru t in kernel land. Those pro esses will also uselessly keep a pro ess id, whi h is a limited resour e on a omputer. On e all the available pro ess ids will be attributed to hildren pro esses even- tually ending in zombie states, we will not be able to reate new ones at all.

The rst strategy to avoid zombies is to expli itly have the original pro ess ask not to be sent SIGCHLD signals when its osprings exit. This is fortunately possible under GNU/Linux by using siga tion() to ignore SIGCHLD signals. The kernel will then not bother sending signals to our dormant pro ess.

9

The C ode to perform this operation is equivalent to:

stru t siga tion sa = {.sa_handler = SIG_IGN}; siga tion(SIGCHLD, &sa, NULL);

This ode needs to be alled only on e by our original pro ess. To perform this operation, we use the same inje tion methodology as with the mk_fork() shell ode. Our position independent shell ode stub to perform this system all is the following:

;Siga tion shell ode: // Zombie reaper

;stru t siga tion sa = {.sa_handler = SIG_IGN};

;siga tion(SIGCHLD, &sa, NULL);

_start:

nop nop nop nop all fake

fake:
pop e x
add e x,0x18			; delta to siga tion stru ture
xor eax,eax
mov al,0x43			; siga tion
mov ebx,0x11			; SIGCHLD
xor edx,edx			; 0x00
int 0x80
db 0x , 0x ,0x ,0x
; stru t siga tion sa = {.sa_handler =					SIG_IGN};
db	01, 00,	00,	00, 00, 00, 00,		00,	00, 00,	00, 00, 00,	00
db	00, 00,	00,	00, 00, 00, 00,		00,	00, 00,	00, 00, 00,	00
db	00, 00,	00,	00, 00, 00, 00,		00,	00, 00,	00, 00, 00,	00
db	00, 00,	00,	00, 00, 00, 00,		00,	00, 00, 00, 00, 00,		00
db	00, 00,	00, 00, 00, 00, 00,			00,	00, 00, 00, 00, 00,		00
db	00, 00,	00, 00, 00, 00, 00,			00,	00, 00, 00, 00, 00,		00
db	00, 00,	00, 00, 00,		00, 00,	00,	00, 00, 00, 00, 00,		00
db	00, 00,	00, 00, 00,		00, 00,	00,	00, 00, 00, 00, 00,		00
db	00, 00,	00, 00, 00,		00, 00,	00,	00, 00, 00, 00, 00,		00
db	00, 00,	00, 00, 00,		00, 00,	00,	00, 00, 00, 00, 00,		00

Using this te hnique, we don't need to are about pending signals anymore. But sin e our weird de- bugger is spawning so many hildren, we need to ensure that those pro esses a tually terminate after a given period of time. And that any pro esses that they'd have spawned themselves without our knowl- edge will also terminate in order to spare omputer resour es.

10

5Exploiting invalid memory writes

In this hapter, we will des ribe how pm ma an be used to help exploit dierent sub lasses of invalid memory writes. We will start with the study of fully ontrolled invalid memory writes, where an atta ker ontrols both the destination where to write to, and the ontent being written fully. We will then envisage other lasses of bugs, where the atta ker has less degrees of liberty : the ase of overows in dierent writable se tions, then the one where the atta ker doesn't ontrol the data being written, and the spe ial sub ase of aligned memory writes.

5.1Finding all the fun tion pointers dereferen ed after an invalid write

Pm ma an be run in two fashions in order to perform an analysis. The rst one is to atta h to a running pro ess by providing its pid at the ommand line. It is parti ularly suited when auditing pro esses like network daemons. The se ond one is by providing pm ma the path of an ELF binary and a ommand line arguments to provide it. In both ases, in its default mode, pm ma will then wait for a segmentation fault to start its analysis.

5.2Overows

Overows an be seen as a sub lass of arbitrary writes where the write operation is performed sequen- tially over a given number of bytes (the size of the overow). As opposed to the previous sub lass of bugs, the atta ker doesn't get to hose where the overwrite is performed. They may though, be able to ontrol the size of the overow and the ontent being overwritten.

Assuming the atta ker has ontrol on both the length of the overow and the data overwritten, limiting the s ope of the previous audit to the one se tion being overwritten will nd all the relevant fun tion pointers potentially overwritten.

More exploitation strategies are mentioned later in this paper in ase su h a pointer ould not be found.

5.3Partial overwrites and pointers trun ations

Another ommon ase happens when an atta ker ontrols fully the lo ation of the write, but has no ontrol over the values being written. The ta ti then used in order to a hieve ontrol ow hija king is to attempt to overwrite a fun tion pointer only partially. This te hnique is referred in the literature as pointer trun ation.

Depending on the (un ontrolled, hopefully repeatable) value of the data being written, an atta ker an attempt to perform either a lower bytes overwrite or a upper bytes overwrite. The goal is that on e modied, the new fun tion pointer still points to a memory se tion mapped as exe utable.

In ase the trun ated fun tion pointer points to the same se tion as the original one (typi ally several bytes before or after), this de fa to implies that the se tion is both writable and exe utable8. Obtaining arbitrary ode exe ution is then a matter of having an appropriate shell ode, possibly pre eded by a nop sled, mapped at the destination address of the modied pointer.

In ase the trun ated pointer points to a dierent se tion, and parti ularly when it is modied to point to a se tion whi h is exe utable but not writable (su h as the .text of a library or of the main binary itself), ontrol will be transfered to a lo ation whi h has very little han es to hold user ontrolled op odes. In other words, the behavior of the binary from this point is totally not predi table. That being said, as a last resort strategy, it may be a good option to an atta ker in the hope of triggering almost immediately an other invalid memory a ess (whi h is very likely), and that this se ond indire t

8Su h mappings still do exist on a tual distributions, but the more hardened ones, having a better kernel in terms of se urity, an prevent su h mappings entirely.

12

vulnerability will give him more ontrol over the data being possibly written (this is not granted and is largely unpredi table). For this to happen in a deterministi fashion though, the return address has to remain un hanged between dierent mappings due to ASLR. This is quite possible in theory, for instan e by returning to a x .text lo ation in a non PIE binary.

It is worth noting that being able to write only the value 0x00000000 is a very ommon su h s enario. In parti ular, integer overows o urring in iteration ounters of opy loops typi ally allow an atta ker to write passed the intended limits of a write, possibly to arbitrary lo ations. But the data being written then often omes from se tion paddings be ause a given opy is taking bytes passed the last mapped buer of a se tion to re-write them at another lo ation.

Pm ma allows for automati testing of the above sub- ases, taking into a ount both lower bytes and higher bytes trun ations. After olle ting informations over the mapping of ea h se tion of the binary, in luding its permissions, and listing the existing fun tion pointers, it is able to determine whi h ones are trun able to point to mapped memory, even a ross se tions :

--[ Validating fun tion pointers (relaxed mode):

<*> Dereferen ed fun tion ptr at 0xbfb7ef4 (full ontrol flow hija k) 0xbfb7ef4 --> 0x080e5e58 // repeatability:0/100

<*> Dereferen ed fun tion ptr at 0xbfb80fe (full ontrol flow hija k) 0xbfb80fe --> 0x080e5fa2 // repeatability:0/100

<*> Dereferen ed fun tion ptr at 0xbfb8101 (full ontrol flow hija k) 0xbfb8101 --> 0x0804f94d // repeatability:0/100

...

<*> Dereferen ed fun tion ptr at 0xbfb7ef4 (full ontrol flow hija k) 0xbfb7ef4 --> 0x080e5e58 // repeatability:0/100

<*> Dereferen ed fun tion ptr at 0xbfb80fe (full ontrol flow hija k) 0xbfb80fe --> 0x080e5ea2 // repeatability:0/100

--> total : 186 validated fun tion pointers

(and found 8 additional ontrol flow errors)
--[ Fun tion pointers exploitable by trun ation with 0x41424344:
At 0xb70 e070 : 0xb70 63 2 will be ome 0xb70 4142 (lower	trun ated by 16 bits, dest perms:RW)
At 0xb70e40a4 : 0xb70 a8f2 will be ome 0xb70 4142 (lower	trun ated by 16 bits, dest perms:RW)
At 0xb70e 080 : 0xb70e5e02 will be ome 0xb70e4142 (lower	trun ated by 16 bits, dest perms:RW)
At 0xb731a030 : 0xb7315da2 will be ome 0xb7314142 (lower	trun ated by 16 bits, dest perms:RW)
At 0xb73230a4 : 0xb732003a will be ome 0xb7324142 (lower	trun ated by 16	bits, dest perms:RW)
At 0xb732803 : 0xb7325a36 will be ome 0xb7324142 (lower	trun ated by 16	bits, dest perms:RW)
At 0xb76a80d8 : 0xb7325bf0 will be ome 0xb7324142 (lower	trun ated by 16	bits, dest perms:RW)

In the previous example taken from an analysis on the text editor nedit under Ubuntu 10.10, 186 fun tion pointers a tually dereferen ed were found, after the starting point of the analysis. Assuming that the value being written is not ontrolled and is (0x41424344)9, 7 of them an be trun ated to point to valid memory. In this run, the destination permission was always reported as "RW", that is both

9This value is ongurable from the ommand line, and pm ma an also use the value a tually being written during the invalid memory a ess leading to the rst segmentation fault - this is the default.

13

Readable and Writable. In ase the urrent kernel allowed exe ution of se tions mapped as writable but not expli itly agged as writable (id est: the kernel doesn't support the NX feature and doesn't emulate for this appli ation), having a shell ode stored at either 0xb70e4142 or 0xb7324142 will result in arbitrary ode exe ution.

For the seek of ompleteness, here is an other example, performed this time with a trun ation by

0x00000000 on 4b aligned addresses, on /bin/sudo:

--[ Fun tion pointers possibly exploitable by 4 byte aligned trun ation with 0x00000000:

At 0x08067135 : 0x4008039e will	be ome 0x40000000 (lower trun ated by	24	bits, dest perms:RX)
At 0x08067b29 : 0x40080637 will	be ome 0x40000000 (lower trun ated by	24	bits, dest perms:RX)
At 0x08067b69 : 0x40080639 will	be ome 0x40000000 (lower trun ated by	24	bits, dest perms:RX)
At 0x08067d89 : 0x4007a933 will	be ome 0x40000000 (lower trun ated by	24	bits, dest perms:RX)
At 0x08a8a03d : 0x4007a7a2 will	be ome 0x40000000 (lower trun ated by	24	bits, dest perms:RX)
At 0x08a8a059 : 0x4007a7a5 will	be ome 0x40000000 (lower trun ated by	24	bits, dest perms:RX)
At 0x08a8a241 : 0x4007a7a0 will	be ome 0x40000000 (lower trun ated by	24	bits, dest perms:RX)
At 0x08a8a581 : 0x4007a7a0 will	be ome 0x40000000 (lower trun ated by	24	bits, dest perms:RX)
At 0x08a8b351 : 0x4000013e will	be ome 0x40000000 (lower trun ated by	24	bits, dest perms:RX)
At 0x08a8b90a : 0x40004042 will	be ome 0x40000000 (lower trun ated by	16	bits, dest perms:RX)
At 0x08a8 361 : 0x4007a7 3 will	be ome 0x40000000 (lower trun ated by	24	bits, dest perms:RX)
At 0x08a8 761 : 0x4007a7 7 will	be ome 0x40000000 (lower trun ated by	24	bits, dest perms:RX)
At 0x08a8 861 : 0x4007a7 8 will	be ome 0x40000000 (lower trun ated by	24	bits, dest perms:RX)
At 0x08a8 aa1 : 0x4007a7bd will	be ome 0x40000000 (lower trun ated by	24	bits, dest perms:RX)
At 0x08a8d00a : 0x400007a8 will	be ome 0x40000000 (lower trun ated by	16	bits, dest perms:RX)
At 0x08a8d1b9 : 0x4007a7d1 will	be ome 0x40000000 (lower trun ated by	24	bits, dest perms:RX)
At 0x08a8d245 : 0x4000006f will	be ome 0x40000000 (lower trun ated by	24	bits, dest perms:RX)
At 0x08a8d2a2 : 0x400a0001 will	be ome 0x400a0000 (lower trun ated by	16	bits, dest perms:RX)
At 0x08a8d2 5 : 0x4007a7d2 will	be ome 0x40000000 (lower trun ated by	24	bits, dest perms:RX)
At 0x08a8d2 d : 0x404e1 d5 will	be ome 0x40000000 (lower trun ated by	24	bits, dest perms:RX)
At 0x08a944e1 : 0x4007a952 will	be ome 0x40000000 (lower trun ated by	24	bits, dest perms:RX)
At 0x08a949e5 : 0x40403fbf will	be ome 0x40000000 (lower trun ated by	24	bits, dest perms:RX)
At 0x08a94b03 : 0x40449040 will	be ome 0x40449000 (lower trun ated by	8 bits, dest perms:RX)
At 0x08a94e02 : 0x4000404a will	be ome 0x40000000 (lower trun ated by	16	bits, dest perms:RX)
At 0x08a95067 : 0x40415 40 will	be ome 0x40415 00 (lower trun ated by	8 bits, dest perms:RX)
At 0x08a95077 : 0x40415040 will	be ome 0x40415000 (lower trun ated by	8 bits, dest perms:RX)
At 0x08a95087 : 0x40414640 will	be ome 0x40414600 (lower trun ated by	8 bits, dest perms:RX)
...

We an verify that this time, trun ations of dierent sizes are possible, and that the destination address would be readable and exe utable. It orresponds to the .text of shared libraries, and returning there, while almost10 guaranteed to lead to exe ution of exe utable ode. But the result of returning savagely to an unexpe ted lo ation is entirely non predi table and needs be tested, for instan e using an other iteration of pm ma.

10It is in fa t possible in theory to return to the middle of an op ode, hen e orresponding to an invalid instru tion

14

5.4Dis overing unaligned memory reads

Last but not least, an extreme sub- ase of overwrites o urs when an atta ker has not only no or little ontrol over the data being written, but has additional onstraints over where the write lo ation is being performed. The author found himself in su h a situation where only the value 0x00000000 ould be written, and only on 4 byte aligned lo ations. This atypi al ase was due to a opy loop where the destination was user ontrolled be ause of an integer overow, but where the destination would always be a multiple of 4 (many su h memory initialization or opy loops pro ess 4byte aligned memory zones, be ause ompilers try to keep the data aligned in order to maximize pu e ien y, and be ause the size of an atomi opy is also a multiple of 4).

Most fun tion pointers inside an appli ation are aligned on 4 byte boundaries. In this ase, inuen ing the ow of exe ution by trun ating a fun tion pointer like previously is not possible, due to the ad- ditional onstraints on the destination. In ase we found an unaligned fun tion pointer, this ould be pra ti al. Therefore, whenever an unaligned fun tion pointer is found, pm ma ags it as remarkable (but this is honestly quite rare on Intel ar hite tures).

In ase no su h unaligned fun tion pointers ould be found, those highly hallenging memory orruption bugs would probably be regarded as never exploitable by most exploit writters. In fa t, we believe they may still be used to inuen e the ontrol ow of exe ution, but indire tly.

Sin e an atta ker an under those onditions only alter data 4b aligned to be 0x00000000, whi h has little han es of being interesting, the idea is to manage to overwrite partially a given double word in memory that will later be read using an unaligned read by the pu. Su h unaligned reads are fairly rare, but an be listed using a unique te hnique we developped for pm ma.

The following ode performs those operations:

int monitor_unaligned(int pid){ stru t user_regs_stru t regz;

keepexe :

// Set align flag

ptra e(PTRACE_GETREGS, pid,NULL, ®z); regz.eflags |=0x40000; ptra e(PTRACE_SETREGS, pid,NULL, ®z);

while(1){ siginfo_t si;

memset(&si, 0, sizeof(siginfo_t));

// ontinue tra ing

ptra e(PTRACE_CONT, pid, NULL, NULL); wait(NULL);

// display re eived signals

ptra e(PTRACE_GETSIGINFO, pid, NULL, &si); last_signal=si.si_signo;

siginfo_t si;

memset(&si, 0, sizeof(siginfo_t));

// void error

memset(&si, 0, sizeof(siginfo_t)); ptra e(PTRACE_SETSIGINFO, pid, NULL, &si);

15

//disassemble at urrent eip har raw[40℄; memset(raw,0x00,40);

getdata(pid, regz.eip, raw, 40);

har line[400℄;

x86_insn_t insn;/* instru tion */

memset(line,0x00,400);

x86_disasm((unsigned har*)raw, 40, 40, 0x00, &insn ); x86_format_insn(&insn, line, sizeof line,intel_syntax);

if(strlen(line)>1){

printf("%08X: %s\n",(unsigned int)regz.eip,line);

}

//display registers display_regs(line,regz);

//set eip to next instru tion ptra e(PTRACE_GETREGS, pid,NULL, ®z); regz.eip+=insn.size; ptra e(PTRACE_SETREGS, pid,NULL, ®z);

//void error

memset(&si, 0, sizeof(siginfo_t)); ptra e(PTRACE_SETSIGINFO, pid, NULL, &si);

goto keepexe ;

}

return 0;

}

The idea is to set the unaligned ag in the EFLAGS register so that any subsequent unaligned memory a ess triggers a signal 7 (Bus Error), as per the intel manuals[17℄. By then disassembing the latest instru tion exe uted, parsing it to retrieve the registers used and performing a all to ptra e() using the PTRACE_GETREGS request, pm ma is able to retrieve the address of all unaligned reads and writes.

The following example shows how determining all the unaligned memory read and write a ess ould be performed against the OpenSSH daemon running on a Fedora 15 omputer.

[rootfedora-box pm ma℄# netstat -atnp|grep ssh
t p	0	0	0.0.0.0:22	0.0.0.0:*	LISTEN	7619/sshd
t p	0	0	:::22	:::*	LISTEN	7619/sshd

[rootfedora-box pm ma℄#

16

In a se ond terminal, the auditor initiates a ssh onne tion :

[endrazinefedora-box ~℄$ ssh lo alhost

On the rst terminal are then listed all the unaligned memory a esses, along with the relevant infor- mation regarding the instru tion exe uted and the value of registers during ea h a ess:

signo: 7 errno:	0 ode: 1
00BD9FDF: mov	[edx-0x4℄, e x
e x= 00000000
edx= 214e57b6
signo: 7 errno:	0 ode: 1
00BDA336: mov	e x, [eax+0x6℄
eax= bfb3 b08
e x= 0000000a
signo: 7 errno:	0 ode: 1
00BDA339: mov	[edx+0x6℄, e x
e x= ae03591
edx= 214e20
signo: 7 errno:	0 ode: 1
00BDA33C: mov	e x, [eax+0x2℄
eax= bfb3 b08
e x= ae03591
signo: 7 errno:	0 ode: 1
00BDA33F: mov	[edx+0x2℄, e x
e x= 60000000
edx= 214e20
signo: 7 errno:	0 ode: 1
00BDA336: mov	e x, [eax+0x6℄
eax= 002beb49
e x= 0000000a
signo: 7 errno:	0 ode: 1
00BDA33C: mov	e x, [eax+0x2℄
eax= 002beb49
e x= b09f2035
signo: 7 errno:	0 ode: 1
00BDA342: movzx e x, [eax℄
eax= 002beb49
e x= 4a33dae7
signo: 7 errno:	0 ode: 1
00BD5A55: mov	[edx-0x3℄, ax
edx= 214e20e4
signo: 7 errno:	0 ode: 1
00BDA339: mov	[edx+0x6℄, e x
e x= 00 34ff4
edx= 214e20 8
signo: 7 errno:	0 ode: 1
00BDA33F: mov	[edx+0x2℄, e x
e x= 00002d58
edx= 214e20 8
signo: 7 errno:	0 ode: 1
00BDA336: mov	e x, [eax+0x6℄
eax= 002beb53

17

e x= 0000000a

signo: 7 errno: 0 ode: 1

00BDA33C: mov e x, [eax+0x2℄ eax= 002beb53

e x= 382b 34a

signo: 7 errno: 0 ode: 1

00BDA342: movzx e x, [eax℄ eax= 002beb53

e x= 5b802b3e

signo: 7 errno: 0 ode: 1

00BD5A52: mov [edx-0x7℄, eax eax= 00000000

edx= 214e20e4

signo: 7 errno: 0 ode: 1

00BD5A55: mov [edx-0x3℄, ax edx= 214e20e4

signo: 7 errno: 0 ode: 1

00BD5A52: mov [edx-0x7℄, eax eax= 00000000

edx= 214e20e4

signo: 7 errno: 0 ode: 1

00BD5A55: mov [edx-0x3℄, ax edx= 214e20e4

Even if su h unaligned memory a esses are rare, writing 0x00000000 to partially modify a 32 bits value that will then be read using an unaligned read an trigger se ondary bugs inside the appli ations, possibly giving more ontrol over the registers used in this se ond operation to an atta ker.

6ASLR and its limits

ASLR is a pretty ee tive way to prevent exploitation, based on statisti s. If an atta ker an make only a single try, for instan e when exploiting a lient side vulnerability, and if ASLR is fully enfor ed, then it may a t as a very ee tive mitigation. The publi ly available debugging tools usually la k se tion based ASLR testing,and when they have this feature, su h as paxtest, they la k the apability to test the ASLR of a given binary in its entirety. In this hapter, we indent to outline a few limits of ASLR as well as des ribe how ASLR testing has been implemented in pm ma.

6.1Ee tive testing of ASLR

As the astute reader may have noti ed from previous examples, when reporting a nding, pm ma systemati ally appends a metri of repeatability, su h as:

<*> Dereferen ed fun tion ptr at 0xbfb7ef4 (full ontrol flow hija k) 0xbfb7ef4 --> 0x080e5e58 // repeatability:0/100

...

<*> Dereferen ed fun tion ptr at 0xb76f 4b (full ontrol flow hija k) 0xb76f 4b --> 0xb76 3e20 // repeatability:0/100

This metri a tually ree ts the probability of a given mapping to reo ur at the very same lo ation.

In order to ompute those probabilities, pm ma starts by relaun hing the target binary a great number of times (100 by default). For ea h exe ution, it re ords the base address of the mapping of ea h se tion. The metri displayed along with ndings is then the highest probability to nd a given se tion at a parti ular address:

18

--[ Performing ASLR tests:

[se tion:001℄ /bin/su

most probable address:0x08048000, proba=100/100

[se tion:002℄ /bin/su

most probable address:0x0804f000, proba=100/100

[se tion:003℄ /bin/su

most probable address:0x08050000, proba=100/100 [se tion:004℄

most probable address:0x08051000, proba=100/100

[se tion:005℄ [heap℄

most probable address:0x0805e000, proba<001/100

[se tion:006℄ /lib/ld-2.12.1.so

most probable address:0xb7583000, proba<002/100

[se tion:007℄ /lib/ld-2.12.1.so

most probable address:0xb7584000, proba<002/100

[se tion:008℄ /lib/ld-2.12.1.so

most probable address:0xb758d000, proba<002/100

[se tion:009℄ [vdso℄

most probable address:0xb758e000, proba<002/100 [se tion:010℄

most probable address:0xb758f000, proba<002/100

[se tion:011℄ /usr/lib/lo ale/lo ale-ar hive most probable address:0xb75b6000, proba<002/100

[se tion:012℄ /lib/libnss_ ompat-2.12.1.so most probable address:0xb75b8000, proba<002/100

[se tion:013℄ /lib/libnss_ ompat-2.12.1.so most probable address:0xb75b9000, proba<002/100

[se tion:014℄ /lib/libnss_ ompat-2.12.1.so most probable address:0xb75ba000, proba<002/100

[se tion:015℄ /lib/libnsl-2.12.1.so

most probable address:0xb7711000, proba<002/100

[se tion:016℄ /lib/libnsl-2.12.1.so

most probable address:0xb7713000, proba<002/100

[se tion:017℄ /lib/libnsl-2.12.1.so

most probable address:0xb7714000, proba<002/100 [se tion:018℄

most probable address:0xb7718000, proba<002/100

[se tion:019℄ /lib/se urity/pam_rootok.so most probable address:0xb771a000, proba<002/100

[se tion:020℄ /lib/se urity/pam_rootok.so most probable address:0xb771b000, proba<002/100

[se tion:021℄ /lib/se urity/pam_rootok.so most probable address:0xb771 000, proba<002/100

[se tion:022℄ /lib/libpam.so.0.82.2

most probable address:0xb7727000, proba<002/100

[se tion:023℄ /lib/libpam.so.0.82.2

most probable address:0xb7728000, proba<002/100

[se tion:024℄ /lib/libpam.so.0.82.2

most probable address:0xb774f000, proba<002/100

[se tion:025℄ /lib/libpam_mis .so.0.82.0 most probable address:0xb7751000, proba<002/100

[se tion:026℄ /lib/libpam_mis .so.0.82.0 most probable address:0xb7752000, proba<002/100

[se tion:027℄ /lib/libpam_mis .so.0.82.0 most probable address:0xb776e000, proba<002/100

[se tion:028℄

19

most probable address:0xb776f000, proba<002/100

[se tion:029℄ /lib/lib -2.12.1.so

most probable address:0xbf7e4000, proba<002/100

Computing those probabilities in an ee tive way is in itself quite a hallenge : when should one stop the pro ess and assume it is fully mapped ? The te hnique should also ope with network daemon that bind ports and may pose an additional problem. If we exe ute say OpenSSH and wait for it to be fully loaded, re ord its mapping and shut it down, the port 22 will not be available immediately for rebinding.

To ope with those problems, pm ma attempts to re ord mappings right after the proper loading of the main binary and its asso iated shared libraries. To a hieve this aim, pm ma runs the appli ation while debugging it using the PTRACE_SYSCALL request of ptra e(). This allows pm ma to be made aware of any system all performed by the debugged pro ess. It then maintains a list of system alls used during the loading of an appli ation:

int allowed_sys alls[℄={3,5,6,11,33,45,91,125,192,197,243}; /*Those sys alls are used during exe ve() and loading :

read	3
open	5
lose	6
exe ve	11
a ess	33
brk	45
munmap	91
mprote t	125
mmap2	192
fstat64	197
set_thread_area	243*/

Whenever a system all performed by the debugged pro ess doesn't belong to this white list, pm ma assumes that exe ution has already been transfered to the entry point of the appli ation, and that the loading has therefore entirely been done. It then re ords the base address of ea h se tion of the mapping and kills the debugged pro ess.

The net benet of this te hnique is to allow for a very ee tive re ording of mappings. The only map- pings pm ma would a tually missed are those performed mu h later during exe ution su h as pluggings or shared libraries mapped by the appli ation itself.

Finally, that the same aim an be rea hed in a simpler way by putting a breakpoint on the entry point of the binary .

Thanks to Ivanlef0u for this idea.

20

6.2Non Position Independant Exe utables

As mentioned before in this arti le, binaries not expli itly ompiled as position independent exe utables do not have their se tions randomised (only their share libraries if any, their heap and sta k are).

If Linux distributions biased towards se urity instead of performan e su h as Gentoo Hardened with grse urity kernels enfor e PIE ompilation on every single binary of the system, this is hardly the ase for the vast majority of the Linux distributions.

Mainstream distributions su h as Fedora or Ubuntu only impose PIE ompilation on a arefully hosen set of binaries. Typi ally only network deamons.

It means that even setuid binaries su h as /bin/su or network lients su h as web browsers are not ompiled as position independent exe utables, and have therefore some se tions not randomized. This may not seem too bad at rst sight, but it really means that when looking for a x pivoting address inside the appli ation, an atta ker is guaranteed to nd some. This may be used not only to write 100% reliable ret2plt bootstrap shell ode in ase of sta k overows, but also sometimes return to the .text of the binary as explained earlier in ase of pointer trun ations. We will see that this weakness an also be used to infere the mapping of the whole appli ation when attempting to leak the layout of the binary towards the end of this hapter.

6.3Prelinking

Prelinking is a time saving feature, employed notably by default on Fedora. It allows for faster loading of appli ations by pre omputing the lo ation of the shared libraries inside a pro ess, and hard oding those lo ations on disk.

The Fedora prelinking is renewed every two weeks thanks to a ron job. It means that during 14 days, the mapping of the shared libraries of a given pro ess are entirely deterministi . Under pm ma, this means that the probability asso iated with the mappings of a given se tion fo a shared library will be of 100%.

Fedora's do umentation expli itly mentioned this behavior[18℄ and on ludes that the risk is a eptable sin e the mapping of shared library is hosen randomly every two weeks. In parti ular it will dier from ma hine to ma hine. We will see later in this hapter the limits of those assumptions : if an atta ker ould somehow retrieve the mapping of a given pro ess at a given point in time, he would then know the mapping of subsequent exe utions of this same binary for some time.

6.4Biased ASLR

Finally, it is worth mentioning that some distributions have very biased ASLR, due to improper kernels. This allows for probabilisti exploitation of binaries.

Here is an example of an analysis performed by pm ma on Ubuntu 10.10 with a kernel 2.6.32-26-generi :

--[ Performing ASLR tests:

[se tion:001℄ /bin/ping

most probable address:0x08048000, proba=100/100

[se tion:002℄ /bin/ping

most probable address:0x08050000, proba=100/100

[se tion:003℄ /bin/ping

most probable address:0x08051000, proba=100/100 [se tion:004℄

most probable address:0x08052000, proba=100/100

[se tion:005℄ [heap℄

most probable address:0xb76a7000, proba<003/100

21

[se tion:006℄ /lib/tls/i686/ mov/libnss_files-2.10.1.so most probable address:0xb76a9000, proba<003/100

[se tion:007℄ /lib/tls/i686/ mov/libnss_files-2.10.1.so most probable address:0xb77e7000, proba<003/100

[se tion:008℄ /lib/tls/i686/ mov/libnss_files-2.10.1.so most probable address:0xb77e8000, proba<003/100

[se tion:009℄

most probable address:0xb77ea000, proba<003/100

[se tion:010℄ /lib/tls/i686/ mov/lib -2.10.1.so most probable address:0xb77eb000, proba<013/100

[se tion:011℄ /lib/tls/i686/ mov/lib -2.10.1.so most probable address:0xb77ee000, proba<014/100

[se tion:012℄ /lib/tls/i686/ mov/lib -2.10.1.so most probable address:0xb77fe000, proba<013/100

[se tion:013℄ /lib/tls/i686/ mov/lib -2.10.1.so most probable address:0xb77ff000, proba<013/100

[se tion:014℄

most probable address:0xb7800000, proba<003/100

[se tion:015℄ /lib/tls/i686/ mov/libresolv-2.10.1.so most probable address:0xb7810000, proba<003/100

[se tion:016℄ /lib/tls/i686/ mov/libresolv-2.10.1.so most probable address:0xb7812000, proba<003/100

[se tion:017℄ /lib/tls/i686/ mov/libresolv-2.10.1.so most probable address:0xb7813000, proba<003/100

[se tion:018℄

most probable address:0xb782e000, proba<003/100 [se tion:019℄

most probable address:0xb782f000, proba<003/100

[se tion:020℄ [vdso℄

most probable address:0xbfa7d000, proba<002/100

In this analysis, pm ma was able to report that some shared libraries su h as the lib a tually have a

given base address for their mapping mu h more probable (up to 13% of the time) than expe ted.12. If upgrading to a more re ent kernel shipped by Ubuntu xes this parti ular problem, it fundamentally

means that ustom kernels ompiled by system administrators not su iently knowledgeable about se urity an lead to weak ASLR.

6.5Memory mapping leakage

Previous resear hes[19℄[20℄, and in parti ular the 2010 WTFuzz exploit against IE8 under Windows 7[21℄ whi h won the pwn2own ontest have shown that using JavaS ript and a heap overow to over- write the NULL terminator of a Javas ript string, it was possible for an atta ker to be given more information than he should have a essed (when reading from the string in question). If the leaked bytes (whi h may be in random quantity, up to the next NULL byte) ontained a pointer to data in other se tions, then the atta ker ould infer the lo ation of a mapping of a given se tion inside the running pro ess (from JavaS ript itself) and trigger a very pre ise se ond write to obtain arbitrary ode exe ution.

To further generalise this te hnique, let's take a step ba k and look at the problem from a kernel's stand point. Essentially, all the information sent to an atta ker use only a few system alls. Namely sys_write() and sys_so ketsys all(). The later oers a few dierent requests and now handles what used to be all the other so ket related system alls, su h as sys_ onne t(), or sys_send(). Let's have a look at the ode of this system all in kernel 2.6.39 sour e ode13:

12The analysis also shows that the ode, data and read only data segments of ping are not randomized at all, but this was a tually expe ted given that this binary isn't ompiled as PIE.

13Sample ode taken from net/so ket.

22

2234	SYSCALL_DEFINE2(so ket all, int, all, unsigned long __user *, args)
2235	{
2236	unsigned long a[6℄;
2237	unsigned long a0, a1;
2238	int err;
2239	unsigned int len;
2240
...
2247
2248	/* opy_from_user should be SMP safe. */
2249	if ( opy_from_user(a, args, len))
2250	return -EFAULT;
2251
2252	audit_so ket all(nargs[ all℄ / sizeof(unsigned long), a);
2253
2254	a0 = a[0℄;
2255	a1 = a[1℄;
2256
2257	swit h ( all) {
2258	ase SYS_SOCKET:
2259	err = sys_so ket(a0, a1, a[2℄);
2260	break;
2261	ase SYS_BIND:
2262	err = sys_bind(a0, (stru t so kaddr __user *)a1, a[2℄);
2263	break;
2264	ase SYS_CONNECT:
2265	err = sys_ onne t(a0, (stru t so kaddr __user *)a1, a[2℄);
2266	break;
2267	ase SYS_LISTEN:
2268	err = sys_listen(a0, a1);
2269	break;
2270	ase SYS_ACCEPT:
2271	err = sys_a ept4(a0, (stru t so kaddr __user *)a1,
2272	(int __user *)a[2℄, 0);
...
2287	ase SYS_SEND:
2288	err = sys_send(a0, (void __user *)a1, a[2℄, a[3℄);
2289	break;
2290	ase SYS_SENDTO:
2291	err = sys_sendto(a0, (void __user *)a1, a[2℄, a[3℄,
2292	(stru t so kaddr __user *)a[4℄, a[5℄);
...
2327	default:
2328	err = -EINVAL;
2329	break;
2330	}
2331	return err;
2332	}

23

In a nutshell, to all sys_so ket all, eax has to worth 102, then ebx spe ies whi h parti ular all is to be performed, a ording to the following requests, dened in in lude/linux/net.h:

26	#define SYS_SOCKET	1	/* sys_so ket(2)	*/
27	#define SYS_BIND	2	/* sys_bind(2)	*/
28	#define SYS_CONNECT	3	/* sys_ onne t(2)	*/
29	#define SYS_LISTEN	4	/* sys_listen(2)	*/
30	#define SYS_ACCEPT	5	/* sys_a ept(2)	*/
31	#define SYS_GETSOCKNAME	6	/* sys_getso kname(2)	*/
32	#define SYS_GETPEERNAME	7	/* sys_getpeername(2)	*/
33	#define SYS_SOCKETPAIR	8	/* sys_so ketpair(2)	*/
34	#define SYS_SEND	9	/* sys_send(2)	*/
35	#define SYS_RECV	10	/* sys_re v(2)	*/
36	#define SYS_SENDTO	11	/* sys_sendto(2)	*/
37	#define SYS_RECVFROM	12	/* sys_re vfrom(2)	*/
38	#define SYS_SHUTDOWN	13	/* sys_shutdown(2)	*/
39	#define SYS_SETSOCKOPT	14	/* sys_setso kopt(2)	*/
40	#define SYS_GETSOCKOPT	15	/* sys_getso kopt(2)	*/
41	#define SYS_SENDMSG	16	/* sys_sendmsg(2)	*/
42	#define SYS_RECVMSG	17	/* sys_re vmsg(2)	*/
43	#define SYS_ACCEPT4	18	/* sys_a ept4(2)	*/
44	#define SYS_RECVMMSG	19	/* sys_re vmmsg(2)	*/

So, to monitor all the data leaving the pro ess and possibly rea hing an atta ker, being it over so kets, les, ttys or any other mean, all we need to pay attention to is sys_write() (sys all 4 under Intel x86 ar hite tures), and sys_so ket all() (sys all 102 under Intel x86 ar hite tures) for a few arefully hosen sub- alls: sys_send(), sys_sendto(), sys_sendmsg().

The main idea is to pro eed as following: rst of, make the original pro ess fork() on e. Unlike with previous te hniques, we then let the original pro ess run, and monitor it using the ptra e() PTRACE_SYSCALL request, whi h allows us to break every time the pro ess will perform a sys- tem all. We re ord all the system alls exe uted, as well as their return data and values. We now have a referen e run to ompare subsequent experiments with.

Then, we make the saved ospring and make it fork(). We overwrite the rst writable lo ation in mem- ory with dummy data. We then tra e its exe ution thanks to the same ptra e() PTRACE_SYSCALL request. Everytime this pro essattempts to exe ute a system all, we ompare it's input registers with the one of the original pro ess. If the sys all to be exe uted is either sys_write(), or sys_so ket all() with a relevant sub- all, we verify if the data to be pro essed diers from the one of the original pro ess.

Three ases may arise : the amount of data sent may dier. If it is now larger, we have found a lo ation in memory, whi h, when overwritten, for es the appli ation to send more data than expe ted ba k to the atta ker. This would be the ase when overwritting for instan e a variable stored in a read/write se tion, and used as the length argument in the following statement:

write(3,&buff,length);

The se ond ase happens when the data is entirely dierent, be ause for instan e we would have overwritten a pointer to the bu variable in the previous ase.

The third ase is when both the data and the length dier entirely, for instan e when overwritting a pointer to bu and then alling the pointer to data and then alling the following system all via sys_so ket all():

sendto(so kfd,&buff,sizeof(buff),0);

24

In all of those ases, we an a tually with a pretty high a ura y verify if an interresting memory leak o ured, whi h will allow an atta ker to dedu e the mappings of the binary. For this ondition to o ur, the leaked data (either new trailing bytes, or entirely dierent data sent ba k to the atta ker) needs to ontain a pointer to any se tion in the binary. Be ause of the way ASLR is performed under Linux (all the se tions but heap and sta k being translated by a onstant oset), knowing a single pointer to the main binary or to a shared library will result in knowledge of the almost whole mapping. To dis over the lo ation of the heap or sta k, we would need in addition to nd a pointer to the heap (possible) and the sta k (less realisti ) in the data sent to the atta ker. This is really only a matter of parsing the new data sent by the pro ess, and mat h potential pointers against the memory addresses of ea h se tion in its address spa e.

We mentioned earlier that one of the biggest limitation of pm ma is the fa t that system alls performed by osprings ould provide a dierent result than in the original pro ess provided the same inputs (be ause so kets will now be losed, le des riptors in undened states...). Sin e we have now des ribed a method to re ord the system alls performed by the original pro ess, it is possible to fake them in the osprings (by using the ptra e() PTRACE_SYSCALL until a system all is to be alled, and modify the ouput registers and optionally their asso iated data before adjusting eip : we don't even need to a tually perform a real system all). The main in onvenient of this te hnique is the fa t that some system alls pass data in non standard ways (eg: sys_so ket all()). We ould extend pm ma to know how ea h sys all expe ts and modies data, but there are about 300 of them in a modern Linux kernel, and they are ar hite ture spe i . Also, using PTRACE_SYSCALL has a non negligeable overhead in terms of performan e.

25

7Extending the apabilities of pm ma

We have so far fo used on exploitation of invalid memory writes through the use of fun tion pointer. Pm ma is apable of mu h more, and the apabilities oered in terms of exploitation modeling by the mk_fork() te hnique haven't been fully explored yet. In this hapter, we will des ribe a few distin tive features of pm ma.

7.1Call tables and returns to registers+osets

Pure fun tion pointers are not the only way to dire tly modify the ow of exe ution of an appli ation given an arbitary write bug. For exemple, redire tion of the ontrol ow via all tables and dire t modi ations of the ontrol ow based on the value of a register, su h as jmp [eax+0xdeadbeef℄ or all [ebx+0x 0f33babe℄ ould be inuen ed in ase an atta ker ould perform a ontrolled write when exploiting an invalid write vulnerability.

Pm ma is also able to dete t the o urren e of su h s enarios when attempting to write to dierent lo ations in the writable se tions of an appli ation. When reporting ontrol ow modi ations, it will dierentiate the ase where the value it has written to memory is the exa t address later being dereferen ed (labeled as "dire t ontrol ow hija k"). and the ase where the it diers ("indire t ontrol ow bug"):

...

<*> Dereferen ed fun tion ptr at 0xb73 e08 (full ontrol flow hija k) 0xb73 e08 --> 0xb734e54e // repeatability:2/100

<*> Dereferen ed fun tion ptr at 0xb73de0a4 (full ontrol flow hija k) 0xb73de0a4 --> 0xb73d19aa // repeatability:2/100

<-> Triggered an indire t ontrol flow bug when writing at 0xb73df000 (ret value=0xf1f3 38 is unmapped)

0xb73df000 --> 0xb73bf000 // repeatability:2/100

<-> Triggered an indire t ontrol flow bug when writing at 0xb73df2b0 (ret value=0xf1f8ef7 is unmapped)

0xb73df2b0 --> 0xb7348000 // repeatability:2/100

...

--> total : 186 validated fun tion pointers

(and found 8 additional ontrol flow errors)

In the previous example, the addresses where exe ution was attempted by the appli ation (0xf1f3 38 and 0xf1f8ef7 ) be ause of an indire t ontrol ow bug are very lose to the remarkable test value used (0xf1f2f3f4), whi h is a string indi ator that the appli ation in fa t added an oset to this base value inside a register before attempting to jump (or all) the orresponding address.

7.2Sear hing for pointers to stru tures ( ontaining fun tion pointers)

Sin e all se tions do not always share the same amount of entropy, in parti ular when biased ASLR has been dete ted, it is tempting to atta k the worst prote ted se tions rst. In ase fun tion pointers were found only in the best randomized se tions, pm ma is able to perform yet an other analysis in order to maximize the ee tiveness of exploitation.

Instead of atta king fun tion pointers dire tly, it may be worth sear hing for pointers to data stru tures in other se tions (the more heavily randomized ones) ontaining fun tion pointers.

26

The atta k s enario would then be the following : instead of overwriting a fun tion pointer dire tly, overwrite the pointer (whose address is less randomized) to the stru ture to point to a user ontroled, writable lo ation. Then fake the stru ture in this lo ation, and eventually dereferen e the fun tion pointer.

The onditions for this atta k to work are quite realisti in many ases. For instan e, data stru tures ontaining fun tion pointers reated by the appli ation itself are typi ally stored on the heap, whi h is always heavily randomized, and not a good target for a blind overwrite in terms of probability. But if those fun tion pointers are in fa t stored in a linked list, that the rst pointer of the liked list is stored on the proper data se tion of the appli ation, and that the lo ation of this rst pointer an be guessed (for example be ause the binary isn't PIE), then overwriting the rst pointer to point into a user ontrolled buer in the data se tion itself would do the tri k.

In order to dete t pointers to stru tures ontaining fun tion pointers, pm ma rst parses the writable se tions of the binary and sear h for possible pointers to other writable se tions. Those will be the andidate pointers.

Then, it reates a new mapping inside osprings reated by mk_fork(). Those mapping should never be read or written to under normal onditions sin e they have been arti ially reated. Then pm ma modies one pointer andidate per ospring to point to the beginning of the new mapping.

In ase this modi ation triggers an invalid memory a ess in exe ution, pm ma dedu es it has in fa t overwriten a pointer to a stru ture ontaining a pointer a tually dereferen ed.

The reated mappings also ontain a parti ular pattern of bytes, whi h helps in identifying at whi h oset inside the mapping a fun tion pointer is being dereferen ed.

The algorithm to reate a new mapping inside an ospring relies on the inje tion of a small stub shell ode to allo ate memory via mmap(). The main idea of inje ting a shell ode in a debugged pro ess should be pretty familiar to the reader by now. The reation of the mapping then only requires to read the return address of mmap(), whi h is indeed stored into eax.

The shell ode used to a hieve a proper memory allo ation is given below:

;

;old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS, 0, 0) shell ode:

_start:

nop nop nop nop

xor eax, eax xor ebx, ebx xor e x, e x xor edx, edx xor esi, esi xor edi, edi

mov bx,	0x1000	; 1 page
mov l,	0x3	;	PROT_READ|PROT_WRITE
mov dl,	0x21	;	MAP_SHARED|MAP_ANON

push eax push eax

27

push edx push e x push ebx push eax

mov ebx, esp
mov	al, 0x5a	; sys_mmap
int	0x80

;eax ontains address of new mapping db 0x , 0x , 0x , 0x

A typi al analysis by pm ma would then look like:

--[ Sear hing pointers to datastru tures with fun tion pointers

** Pointers to +W se tions: 15928

<*> Dereferen ed a fun tion pointer inside a stru ture when writing at 0x094568e4 (ret value=0xffffffff) // repeatability:1/100

<*> Dereferen ed a fun tion pointer inside a stru ture when writing at 0x094616f (ret value=0xffffffff) // repeatability:1/100

<*> Dereferen ed a fun tion pointer inside a stru ture when writing at 0x094a 960 (ret value=0xffffffff) // repeatability:1/100

<*> Dereferen ed a fun tion pointer inside a stru ture when writing at 0x094a a10 (ret value=0xffffffff) // repeatability:1/100

<*> Dereferen ed a fun tion pointer inside a stru ture when writing at 0x094a ab8 (ret value=0xffffffff) // repeatability:1/100

<*> Dereferen ed a fun tion pointer inside a stru ture when writing at 0xbfb81098 (ret value=0xffffffff) // repeatability:0/100

--> total : 6 fun tion pointers identified inside stru tures

In this example, the return value is 0x, whi h orresponds to the padding of our newly reated mapping. It is therefore not possible to immediately dedu e from the mapping pattern at whi h oset inside this new mapping, the fun tion pointer was lo ated.

7.3Testing exhaustively arbitrary writes

Sin e pm ma has the apabilities to make the debugged pro ess fork() at will, it an exhaustively attempt to overwrite all the writable addresses mapped inside a given pro ess, in the hope to trigger invalid memory a ess in exe ution mode. This pro ess is not only slow and resour e onsuming, but pm ma annot attempt to overwrite all those lo ations with all of the more than 4 billion possible values a 32b register allows. In onsequen e, this option is kept as a last resort in ase all of the other strategies failed. It is nonetheless pra ti al to overwrite all the possible lo ations inside a given pro ess with a predened remarkable value.

28

This feature may seem ane dotal at rst sight. But it is urrently the only way for pm ma to nd the pointers asso iated with unresolved pro edure relo ations. The alternative would be to run all audits with an LD_BINDNOW environment variable set in order to for e resolution by the dynami linker at load time. Unfortunately, this isn't pra ti al for analysis of network daemon, at least not without restarting them. In addition, the use of LD_BINDNOW would indu e modi ations inside the writable mappings of the binary and would no longer ree t its a tual state in real exploitation onditions.

7.4Testing invalid reads

Invalid reads by themselves do not allow dire t modi ation of the ontrol ow. They an nonetheless be interesting, depending on how this parti ular memory read is handled inside the appli ation. If the value read by the faulting instru tion is user ontrolled (meaning : the appli ation an be for ed to read from a given address in memory whi h is user ontrolled), it may trigger indire t invalid memory a esses either in exe ution or write modes. A trivial example would be an appli ation using the value just read as a ounter in e x to perform a memory opy. By setting this register to a very large value, an atta ker would indire tly ause an invalid memory a ess in this loop.

Testing for su h indire t problems aused by an invalid read is fairly straight forward : by setting the register in whi h the value is read to multiple values in dierent osprings of the debugged pro ess, it is possible to dete t if they would eventually result in an invalid memory a ess more interesting (either in write or exe ution mode) later one, simply by ptra ing the ospring and disassembling the faulting address in ase a Segmentation Fault was dete ted.

There again, testing the 2￿ˆ32 possible values oered by modest 32b pro essors is most probably a bit overkill. Testing on a thousand of evenly spa ed values a ross the sear h spa e is mu h more time saving and would spot most indire t vulnerabilities anyways.

8Sta k desyn hronization

For the most part, we have fo used so far on where to write in memory in order to a hieve a modi a- tion of the ontrol ow. It is about time we also onsider the question of what to write. In other word, to onsider what an hija ked fun tion pointer should be modied to point to.

In ase writable se tions are found to be exe utable, and at least one is both reasonably ontrolled and not too randomized, the answer is quite simple : opying a nop sled and shell ode in at this position would grant an atta ker arbitrary ode exe ution. This is how exploitation has been a hieve for about 15 years.

But this s enario is be oming less and less likely, in parti ular be ause writable se tions are not exe- utable anymore thanks either to PaX or pu NX-like bits. In parti ular, the heap, whi h is the only se tion that an be made almost arbitrary big (whi h would help in making the exploit probabilisti ally better thanks to a lassi heap spray) is not ommonly exe utable anymore under GNU/Linux.

In order to over ome those problems, we suggest to return, not to a writable se tion, but to a arefully hosen fun tion prologue. This indeed requires that su h a prologue is either available in a non ran- domized se tion (.text of the binary if ompiled without PIE14), or at an address we an predi t (for instan e thanks to a memory leak indu ed by a previous memory write, like explained earlier in this paper).

By returning to a hosen fun tion prologue, an atta ker will get to hose by how mu h he will modied the sta k pointer. If they ontrol a large buer in the sta k and an reate fake sta k frames in it, then he an default ba k to more standard sta k-smashing-like exploitation (ret2lib , ret2plt or ROP depending on randomization and ompilation options).

To the best of our knowledge, this methodology has never been publi ly dis ussed.

14We saw earlier PIE doesn't apply to non network daemons on most distributions yet, for performan e reasons

29

9Performan e onsiderations

Pm ma starts its analysis by dumping to disk all the mapped se tion of the analysed binary for easier study. This preliminary phase is parti ularly ostly.

The other phase whi h is really ostly in terms of performan e is parsing all se tions mapped as writable, list their potential pointers to other se tions, and verify if they point to valid assembly instru tions by disassembling the destination bytes. The ost of this phase is O(n), where n is the size of writable memory inside the pro ess.

Finally, for ea h potential fun tion pointer dis overed, pm ma will reate a new pro ess, overwrite the test pointer with a known value and run the pro ess. This phase is in O(p), where p is the number of potential fun tion pointers dis overed.

Experimentally when looking for fun tion pointers, an analysis performed by pm ma ranges from a few se onds when analysing /bin/ping to about one hour when analysing the Opera web browser when rashing after performing a ertain amount of heap sparying (resulting in a total of 1.3Gb or memory mapped, among whi h more than 1.2Gb is writable memory). The average analysis is of several minutes for most network daemons.

It is worth noting that urrently, the tests on osprings are run sequentially one after the other. But in fa t, this is not ne essary, wether sys all faking is in use or not. In the near future, we hope to modify pm ma to run those tests in parallel instead of running them sequentially.

10 Con lusion

We have briey presented in this arti le new exploitation te hniques, or sometimes extension of existing ones, and detailed how they ould be tested automati ally against a target binary vulnerable to invalid memory a esses.

We have exposed how to reate exploitation models thanks to a new debugging te hnique post memory orruption, in order to automati ally study the exploity of sub lasses of the invalid memory write bug lass.

Our proof of on ept tool, pm ma, doesn't write exploits itself. Instead, its goal is to analyze all the en- vironment onstraints of a given system and provide its user with the best possible atta k methodology for a given vulnerability, generalizing many atta k ve tors and taking into a ount all the small details (kernel behavior, ompiler versions and ags, stati and dynami liking options, set of shared libraries used...) that need be taken into a ount to write an ee tive exploit for a given target nowadays. Given the number of ta ti s available in the literature that work only on very spe i o asions (su h as spe i distributions), the exploitation strategies oered by this tool shall prove valuable to atta kers (exploit writers) and software developers or system administrators alike ("is this vulnerability ae ting my system or software exploitable by the state of the art of exploitation theory on my parti ular setup ?").

11 a knowledgements

The author would like to thank in no parti ular order #busti ati, #so ial, #grse urity, #rux on, #bla kse , THC/TESO, pipa s, spender, twiz, bliss, silvio, andrewg, mer y, gamma, bsdeamon, addis, izik, xort, redsand, sbz, deadbyte, the grugq, phil, emmanuel, msui he, the Ha kito Ergo Sum (HES) team, the HES Programming omitee, the HES speakers and friends, the /tmp/lab ha kerspa e, Mark Dowd, Meder Kydyraliev, the CBACert for their te hni al ontributions, ideas and peer reviews. The Tou an System team, his family and his girlfriend, for their en ouragements, and their patien e.

30

Referen es

1.PaXTeam: (http://pax.grse urity.net/do s/aslr.txt)

2.PaXTeam: (http://pax.grse urity.net/do s/noexe .txt)

3.PaXTeam: (http://pax.grse urity.net/)

4.AMD: (http://support.amd. om/us/pro essor_te hdo s/24593.pdf)

5.Drepper, U.: (Se urity enhan ements in red hat enterprise linux)

6.Jelinek, J.: (http://g .gnu.org/ml/g -pat hes/2004-09/msg02055.html)

7.BBSDaemon: Dynami program analysis and software exploitation, from the rash to the exploit ode. (Phra k magazine)

8.Bania, P.: Spiderpig. Te hni al report (2008)

9.Cristian Cadar, Daniel Dunbar, D.E.: Klee: Unassisted and automati generation of high- overage tests for omplex systems programs. Te hni al report (2008)

10.Thanassis Avgerinos, Sang Kil Cha, B.L.T.H., Brumley, D.: (Aeg: Automati exploit generation)

11.Henderson, R.: (http://g .gnu.org/ml/g -pat hes/2005-05/msg01193.html)

12.lo al ore, D..: (/bin/su exploit : http://www.exploit-db. om/exploits/209/)

13.Hertz: (at_exit() lo al exploit)

14.Anonymous: Runtime pro ess infe tion. (Phra k magazine)

15.Stealth: (http://stealth.openwall.net/lo al/inje tso-0.52.tgz)

16.Brossard, J.: Opera : Sele t size arbitrary null write, tssa-2011-02, ve-2011-1824 (2011)

17.Intel: Intel 64 and ia-32 ar hite tures software developer's manual. In: Volume 3A: System Pro- gramming Guide. (2008)

18.van de Ven, A.: (Limiting buer overows with exe shield)

19.Mark Daniel, Jake Honoro, C.M.: (Engineering heap overow exploits with javas ript)

20.Chen, Y.: (Using information leakage to avoid aslr+dep)

21.Vreugdenhil, P.: (Internet explorer 8 on windows 7 exploit form the pown2own ontest 2010)

31