CSCI6268L32 - Foundations of Network and Computer Security...

Info iconThis preview shows pages 1–10. Sign up to view the full content.

View Full Document Right Arrow Icon
Foundations of Network and Foundations of Network and Computer Security Computer Security J J ohn Black Lecture #32 Nov 18 th 2009 CSCI 6268/TLEN 5550, Fall 2009
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
StackGuard Idea (1996): Change the compiler to insert a “canary” on to the stack just after the return address The canary is a random value assigned by the compiler that the attacker cannot predict If the canary is clobbered, we assume the return address was altered and we terminate the program Built in to Windows 2003 Server and provided by Visual C++ .NET Use the /GS flag; on by default (slight performance hit)
Background image of page 2
Sample Stack with Canary c b a ret buffer 3 2 1 4 bytes 4 bytes 4 bytes Return address sfp canary
Background image of page 3

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Canaries can be Defeated A nice idea, but depending on the code near a buffer overflow, they can be defeated Example: if a pointer (int *a) is a local and we copy another local (int *b) to it somewhere in the function, we can still over-write the return address Not too far fetched since we commonly copy ptrs around
Background image of page 4
Avoiding Canaries ret buffer Return address sfp canary int *a int *b int i Address of ret Address of i SSSSSSSSSSSSSS SSSSSSSSSSSSSS SSSSSSSSSSSSSS SSSSSS First, overflow the buffer as shown above. Then when executing *a = *b we will copy code start addr into ret Address of buffer Address of buffer
Background image of page 5

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Moral: If Overruns Exist, High Probability of an Exploit There have been plenty of documented buffer overruns which were deemed unexploitable But plenty of them are exploitable, even when using canaries Canaries are a hack, and of limited use
Background image of page 6
Non-Executing Stacks and Return to LibC Suppose the stack is marked as non-executable Some hardware can enforce bounded regions for executable code This is not the case on generic Linux, however, since all our example programs for stack overruns work just fine, but there is a Linux version which supports this Has to do all kinds of special stuff to accommodate programs which need an executable stack Linux uses executable stacks for signal handling Some functional languages use an executable stack for dynamic code generation The special version of Linux has to detect this and allow executable stacks for these processes
Background image of page 7

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Return to LibC: Getting around the Non-Executing Stack Problem Assume we can still over-write the stack 1) Set return address to system() in LibC Use address of dynamically-linked entry point 2) Write any sfp 3) Write address of exit() as new ret addr 4) Write pointer to “/bin/sh” 5) Write string “/bin/sh”
Background image of page 8
buffer sfp ret --Anything-- Address of system() Garbage -- Unimportant First, overflow the buffer as shown above. When function returns, we go to system(“/bin/sh”) which spawns a shell
Background image of page 9

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full Document Right Arrow Icon
Image of page 10
This is the end of the preview. Sign up to access the rest of the document.

{[ snackBarMessage ]}

Page1 / 64

CSCI6268L32 - Foundations of Network and Computer Security...

This preview shows document pages 1 - 10. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online