1. Buffer Overflow Group 7Group 8 Nathaniel CrowellDerek Edwards Punna ChalasaniAxel Abellard Steven Studniarz

2. Basic Concepts Buffer Region of memory used to hold temporary input and output data Memory Organization

3. Stack Helps implementation of High- level languages Used to dynamically allocate memory Frame Pointer (FP): points to fixed location within frame Stack Pointer (SP): points to the top of the stack

4. Buffer Overflow A process attempts to store more data in a buffer than there is memory allocated for it Triggered by specific inputs which may be designed to execute arbitrary code. Up to 50 percent of today's widely exploited vulnerabilities are buffer overflows Source: 2005 Network and Distributed Systems Security conference

5. Shell Code Designing Shell Code Utilizing debugger Disassembling system commands Generating machine code Problems with null termination How to avoid? When it matters?

6. Disassembled System Commands

7. Eliminating null

8. What’s the “????” ? Remove bad intermediate values Better choice of registers Use similar instructions with different op codes

9. Smashing the stack Executing arbitrary code Typically for remote access Access level (and raising it) Improvements Generating exploitive input ($EGG) NOP sled

10. imapd: A Real World Example University of Washington's IMAP Server (UW-IMAP) Insufficient bounds checking on user-supplied values for specifying mailbox name Parsing error allowed a string that started with a “ character to continuously read input until another “ is encountered More info at: http://www.idefense.com/intelligence/vulnerabilities/display.php?type=vulnerabilities&id=313

11. imapd: The Code In Question long mail_valid_net_parse_work (char *name,NETMBX *mb,char *service) { int i,j; #define MAILTMPLEN 1024 /* size of a temporary buffer */ char c,*s,*t,*v,tmp[MAILTMPLEN],arg[MAILTMPLEN];...snip... if (t - v) { /* any switches or port specification? */ 1] strncpy (t = tmp,v,j); /* copy it */ tmp[j] = ''; /* tie it off */... if (*t == '"') { /* quoted string? */ 2] for (v = arg,i = 0,++t; (c = *t++) != '"';) { /* Vulnerability */ /* quote next character */ if (c == '\') c = *t++; arg[i++] = c; }

12. imapd: The Code In Question long mail_valid_net_parse_work (char *name,NETMBX *mb,char *service) { int i,j; #define MAILTMPLEN 1024 /* size of a temporary buffer */ char c,*s,*t,*v,tmp[MAILTMPLEN],arg[MAILTMPLEN];...snip... if (t - v) { /* any switches or port specification? */ 1] strncpy (t = tmp,v,j); /* copy it */ tmp[j] = ''; /* tie it off */... if (*t == '"') { /* quoted string? */ 2] for (v = arg,i = 0,++t; (c = *t++) != '"';) { /* Vulnerability */ if (!c) return NIL; /* unterminated string */ /* quote next character */ if (c == '\') c = *t++; if (!c) return NIL; /* can't quote NUL either */ arg[i++] = c; }

13. The Moral of the Story… Careful programming is the first line of defense against buffer overflows Parsing such as that done in imapd must be very carefully checked (unit testing, perhaps) to ensure such vulnerabilities do not exist Many overflows come from simply using unsafe library functions…

14. Unsafe Library Functions and Their Safe(r) Counterparts strcpy() → strncpy() strcat() → strncat() strcmp() → strncmp() sprintf() → snprintf() From manpage for gets(): Never use gets(). Because it is impossible to tell without knowing the data in advance how many characters gets() will read, and because gets() will continue to store characters past the end of the buffer, it is extremely dangerous to use. It has been used to break computer security. Use fgets() instead.

15. Simple Prevention Techniques

16. Buffer Overflow Prevention with Libsafe Intercepts calls to vulnerable functions No need to recompile kernel No need to access source code Protects against currently unknown vulnerabilities

17. Partial List of Vulnerable C Functions Source: http://www.research.avayalabs.com/project/libsafe/

18. Source: http://www.research.avayalabs.com/project/libsafe

21. Countering buffer overflows There are many defensive measures available. The most popular measures can be grouped into these categories: Canary-based defenses Non-executing stack defenses Other defense approaches & tools

22. Canary-based defenses There are four types of canaries that have been used to date: Random Canary Random XOR Canary Null Canary Terminator Canary

23. Non-executing stack defenses Other approaches start by making it impossible to execute code on the stack. “non-exec stack patch” Move all executable code to an area of memory called the "ASCII armor" region

24. Other Approaches & Tools Libsafe Split control and data stack Randomizing the locations of executables Crispen's "PointGuard" extends the canary idea to the heap Flawfinder and Viega's RATS

25. A New Preventative Technology: XD/NX Intel → XD (Execute Disable) AMD → NX (No Execute) (Marketing mumbo-jumbo) Last bit in paging table entry (bit 63) If bit is set to 0, code can be executed from the page (and if it’s 1…) Has been included in Sparc, Alpha, PowerPC, and IA-64 Emulation available in software for Linux (PaX, Exec Shield) and OpenBSD (W^X)

26. Questions?