linux - what is The poisoned NUL byte, in 1998 and 2014 editions? -

i have make 10 minutes presentation "poisoned null-byte (glibc)". searched lot found nothing, need please because operating system linux , memory , process management isn't thing.

here original article, , here old article same problem version.

what want short , simple explanation old , new versions of problem or/and sufficient references can better read security threat.

to begin understand how attack works, need @ least basic understanding of how cpu works, how memory works, "heap" , "stack" of process are, pointers are, libc is, linked lists are, how function calls implemented @ machine level (including calls function pointers), malloc , free functions c library do, , on. @ least have basic knowledge of c programming? (if not, not able complete assignment in time.)

if have couple "gaps" in knowledge of basic topics mentioned above, hit books , fill them in can. talk others if need to, make sure understand them. read following carefully. not explain in article linked to, give start. ok, ready? let's start...

c strings "null-terminated". means end of string marked 0 byte. example, string "abc" represented in memory (hex): 0x61 0x62 0x63 0x00. notice, 3-character string takes 4 bytes, due terminating null.

now if this:

char *buffer = malloc(3); // not checking error, example strcpy(buffer, "abc"); 

...then terminating null (zero byte) go past end of buffer , overwrite something. allocated 3-byte buffer, copied 4 bytes it. whatever stored in byte right after end of buffer replaced 0 byte.

that happened in __gconv_translit_find. had buffer, had been allocated enough space append ".so", including terminating null byte, onto end of string. copied ".so" in starting wrong position. started copy operation 1 byte far "right", terminating null byte went past end of buffer , overwrote something.

now, when call malloc dynamically allocated buffer, implementations of malloc store housekeeping data right before buffer. example, might store size of buffer. later, when pass buffer free release memory, can reused else, find "hidden" data right before beginning of buffer, , know how many bytes of memory freeing. malloc may "hide" other housekeeping data in same location. (in 2014 article referred to, implementation of malloc used stored "flag" bits there.)

the attack described in article passed crafted arguments command-line program, designed trigger buffer overflow error in __gconv_translit_find, in such way terminating null byte wipe out "flag" bits stored malloc -- not flag bits the buffer overflowed, another buffer allocated right after 1 overflowed. (since malloc stores housekeeping data before beginning of allocated buffer, , overrunning previous buffer. follow?)

the article shows diagram, 0x00000201 stored right after buffer overflows. overflowing null byte wipes out bottom 1 , changes 0x00000200. might not make sense @ first, until remember x86 cpus little-endian -- if don't understand "little-endian" , "big-endian" cpus are, up.

later, buffer flag bit wiped out passed free. turns out, wiping out 1 flag bit "confuses" free , makes it, in turn, overwrite other memory. (you have understand implementation of malloc , free used gnu libc, in order understand why so.)

by choosing input arguments original program, can set things memory overwritten "confused" free used called tls_dtor_list. linked list maintained gnu libc, holds pointers functions must call when main program exiting.

so tls_dtor_list overwritten. attacker has set things right, function pointers in overwritten tls_dtor_list point code want run. when main program exiting, code in libc iterates on list , calls each of function pointers. result: attacker's code executed!

now, in case, attacker has access target system. if can run code privilege level of own account, doesn't them anywhere. want run code root (administrator) privileges. how possible? possible because buggy program setuid program, owned root. if don't know "setuid" programs in unix are, , make sure understand it, because key whole exploit.

this 2014 article -- didn't @ 1 1998. luck!