/
Compile time vs Run time Compile time vs Run time

Compile time vs Run time - PowerPoint Presentation

natalia-silvester
natalia-silvester . @natalia-silvester
Follow
342 views
Uploaded On 2019-12-13

Compile time vs Run time - PPT Presentation

Compile time vs Run time main argc argv envp int argc char argv char envp int i char name buf 32 name getname printf your name is sn name ID: 770201

heap code overflow stack code heap stack overflow return char executable buffer attacks run defending int injection datadep time

Share:

Link:

Embed:

Download Presentation from below link

Download Presentation The PPT/PDF document "Compile time vs Run time" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.


Presentation Transcript

Compile time vs Run time

main( argc, argv, envp)int argc;char **argv;char **envp;{ int i; char *name, buf[32]; name = getname(); printf("your name is %s\n", name); gets(buf); otherFunc(); printf("your name is %s\n", name);} char*getname() { char *ret, nm[32]; printf("enter your name: "); gets(nm); ret = &(nm[0]); return(ret);}voidotherFunc(){ int i; char b[128]; for (i=0; i<128; i++) b[i] = 'a';} Explain

Heap overflows (& other issues) what is the heap about again? what is the target we wish to overwrite?

Java: MyThing thing1 = new MyThing(id);C:struct idata { int id; char *name; char dept[32]; float gpa;}struct idata mything;mything = (struct data *) malloc(sizeof(mything));Heap – space dynamically allocated at run time

The algorithms to allocate, track, free, coalesce blocks of memory on the heapvary by platform/releaseTherefor heap overflow exploits are narrowlydependent on the platform where they are runThe heap is often a noisy, busy place, and reverseengineering to the point of absolute certaintyIs usually quite difficult

Heap spraying – payload delivery (not execution) Get the heap into a known state so that the position of your object is (more) predictablevs detailed reverse engineeringTo be certain of heap state before you start your exploit

Basically, copy your nop sled and shell code a zillion times over the heapThis is not a vulnerability in itself, butit reduces the apparent randomness ofthe heap from the viewpoint of the attackerWe still need to be able to manipulate a function pointer could be on the stack, though sometimes on the heap as well (because: “narrowly dependent on the platform where they are run”)

Buffer overflow defense techniques Use the OS to make buffers non-executable (DEP)Enable compiler bounds checkingchecks pointers before dereferencing themGet the code right

Buffer overflow defense arms race ASLRDEP, Code injection need executable stack/heapArc injection return to libc, need to know where the functions areReturn oriented programming (ROP) use a series of gadgets to run arbitrary code

Memory protection mechanisms in Windows Bypassing Browser Memory Protections Setting back browser security by 10 years Alexander Sotirov, Mark Dowd Stack cookies compiler flag: -GSEnable run-time detection of stack overflow

stores a random value (stack cookie) on the stack between the local variables and return address of a function Epilog code is added to check to see if it is stillThe same before branching to the return address

(prolog/epilog code also deal with the stack frame for call/return)printf()

~42% hit on runtime performance(OO programming especially problematic)Series of modifications to try to lessen this: only used for string variablesOnly if longer than 2 bytesBe strictDon’t be strict….The balance-point issue remains

Detects only when a function returnsYou might be able to take over via usage within the functionYou might be able to leave it undisturbed, or read it first, then overflow it back in big hit on runtime performance

2. Variable reordering Reorder the layout on the stack so that strings come lastWrite this: f(arg) { char s[1024]; int i;

f( arg) { char s[1024]; int i;arg arg return address return addressreturn value space  return value spaces ii s

But that is weak… why?

-SEH safe exception handler make sure exception handlersand liked lists thereofare real

Heap protection Consider the heap, and what goes on during allocate and free:char *s;s = malloc(128);…..free(s);

Starting in Windows XP SP2 the heap allocator implements safe unlinking when removing chunks from the free list. Before using the flink and blink pointers, it verifies that both flink->blink and blink->flink point to the current heap block. This prevents the attacker from pointing flink or blink to arbitrary memory locations and using the unlink operation to do an arbitrary 4-byte write.Heap protection

Cookie is stored in each header block on the heap It is checked when you try to freeOther header info is xor’ed with a random32 bit value, and are decrypted before use(but they have to store it somewhere)Heap protection

Data Execution Prevention (DEP) is a protection mechanism that prevents the execution of code in memory pages marked non-executable. Code vs dataDEP

Up until 2004, x86 architecture had only a single bit per pageRead-only, or notEverything was executableCode vs dataDEP

Now there is a second bit for executable/not executable Code vs dataDEP

Lots of problems thoughThere exists software for the ms platform whichrelies on executing code contained on the heapCode vs dataDEP

Microsoft decided to provide a "cheat" to enable the exisitng code to functionWhen a program attempts to execute code on a non-executable page, the kernel calls KiEmulateAtlThunk() to check if this is a result of a well known instruction sequence.Code vs dataDEP

Entire Java heap is marked executableGenerating code on the fly is what Java is all about…and it’s a popular design pattern these daysHeap spraying here effectivelyoverrides Code vs dataDEP

Defending against Buffer Overflow attacks Code injection need executable stack/heapArc injection return to libc, need to know where the functions areReturn oriented programming (ROP) use a series of gadgets to run arbitrary code

Defending against Buffer Overflow attacks Arc injectionAlmost everything has libclibc has fork(), exec(), system(), not to mention text like “/bin/sh” available

Defending against Buffer Overflow attacks If I can’t make it execute code where I write it (w^X)I’ll just make it execute code which is already thereThis can defeat DEP

Address Space Layout Randomization (ASLR )(hide libc and other stuff)ASLRVista and Windows Server 2008 are the first operating systems in the Windows family to provide ASLR natively.

registry key (image location) HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\ MoveImages0 never randomize-1 randomize allelse randomize only images that have relocation information and are explicitly marked as compatible with ASLR by setting the IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE (0x40) flag in DllCharacteristics field the PE header

RDTSC Intel time stamp counter (since Pentium) Number of major machine cycles since last resetTake (8 bits from RDTSC) * 65536To get start address within 16meg8bits can’t be zero

Similar for DLL’s Random location and order of loading (sometimes)int main() { HINSTANCE hGetProcIDDLL = LoadLibrary("C:\\....\\test.dll"); if (!hGetProcIDDLL) { std::cout << "could not load the dynamic library" << std::endl; return EXIT_FAILURE; }

Similar for the heap (5 bits) order is random alsobut clock is not as “random” as it feels

A the base of the stack is chosen randomly B) offset into the initial page where the stack starts getting is randomSimilar for the run time stack

4. Insert statically located objects Microsoft is diligent about using these protections, butNot so for many 3rd part vendors (often due to market pressure)

ASLR can break a lot of code which, often for efficiency reasons, requires packed data in a known locationMost popular browser plug-ins include libraries whichare not compatible with ASLRFlash, javaSome diligent plant-and-search can often find stuff anyway

ASLR Brute force searches to find where things are is often not too hardCertain markers in code can reveal locations

Entire Java heap is marked executable, Heap spraying here effectivelyoverrides

Stack canaries Data Execution PreventionAddress Space Layout RandomizationCode signing/TocTouSafe Exception Handlers

Defending against Buffer Overflow attacks Program crash (segv)Code injection need executable stack/heapArc injection return to libc, need to know where the functions areReturn oriented programming (ROP) use a series of gadgets to run arbitrary code

Defending against Buffer Overflow attacks Return Oriented Programming find ‘enough’ gadgetsConsider what assembly is/doesIt all kind of looks the same, no?

Defending against Buffer Overflow attacks ROP uses code which is already there,Catenating it together to achieve arbitrarycode execution

Defending against Buffer Overflow attacks ROP can give you Turing-complete capabilityThe game continues