1. © 2003 School of Computing, University of Leeds SY32 Secure Computing, Lecture 13 Implementation Flaws Part 1: Buffer Overruns

2. 2 SY32 Secure Computing, Lecture 13 Outline Background Background Three generations of flaws Three generations of flaws Classic stack smashing Classic stack smashing Off-by-one errors Off-by-one errors Format string bugs and heap overruns Format string bugs and heap overruns Mitigation Mitigation Coding practices Coding practices Memory protection Memory protection

3. 3 SY32 Secure Computing, Lecture 13 Background What are buffer overruns? What are buffer overruns? Program allocates a contiguous chunk of memory of fixed size to store data (a buffer) Program allocates a contiguous chunk of memory of fixed size to store data (a buffer) Amount of data copied to buffer exceeds its capacity and overwrites other memory Amount of data copied to buffer exceeds its capacity and overwrites other memory Why are they a problem? Why are they a problem? Many critical programs are written in C/C++… Many critical programs are written in C/C++… …but C/C++ have no run-time bounds checking …but C/C++ have no run-time bounds checking

4. 4 SY32 Secure Computing, Lecture 13 Background Problem known about since 1960s Problem known about since 1960s First seen widely in 1988 (Morris worm) First seen widely in 1988 (Morris worm) Infamous overruns: Infamous overruns: wu-ftpd wu-ftpd Several overruns discovered in 1999 & 2000 Several overruns discovered in 1999 & 2000 Some flaws up to 10 years old! Some flaws up to 10 years old! Code Red worm Code Red worm Exploited buffer overrun in IIS Exploited buffer overrun in IIS 359,000 machines infected within 14 hours 359,000 machines infected within 14 hours Estimated worldwide cost of $2 billion Estimated worldwide cost of $2 billion

5. 5 SY32 Secure Computing, Lecture 13 Public Enemy #1!

6. 6 SY32 Secure Computing, Lecture 13 Public Enemy #1!

7. 7 SY32 Secure Computing, Lecture 13 Possible Outcomes No effect on program No effect on program Unpredictable behaviour (D) Unpredictable behaviour (D) Program crashes (D) Program crashes (D) Attack affects flow of execution (T,I,D) Attack affects flow of execution (T,I,D) Attacker executes arbitrary code (T,I,D,E) Attacker executes arbitrary code (T,I,D,E)

8. 8 SY32 Secure Computing, Lecture 13 Memory Layout: A Reminder Text segment holds program instructions (read-only) Text segment holds program instructions (read-only) Data and BSS segments provide storage for static/global data Data and BSS segments provide storage for static/global data Stack and heap change size as program executes Stack and heap change size as program executes Stack holds information about context of function calls in a stack frame Stack holds information about context of function calls in a stack frame Function parameters Function parameters Local variables Local variables Saved register information Saved register information Return address for call Return address for call Stack Env. variables Text Data BSS Heap High memory Low memory

9. 9 SY32 Secure Computing, Lecture 13 Stack Smashing Buffer Other local variables Saved frame pointer Return address Parameters Caller’s stack frame Stack pointer Frame pointer …and overwrites return address, gaining control of execution! High memory Low memory Attacker overruns buffer…

10. 10 SY32 Secure Computing, Lecture 13 Demo

11. 11 SY32 Secure Computing, Lecture 13 jmp 0x1f popl %esi movl %esi,0x8(%esi) xorl %eax,%eax movb %eax,0x7(%esi) movl %eax,0xc(%esi) movb $0xb,%al movl %esi,%ebx leal 0x8(%esi),%ecx leal 0xc(%esi),%edx int $0x80 xorl %ebx,%ebx movl %ebx,%eax inc %eax int $0x80 call -0x24.string \"/bin/sh\" Crafting an Exploit void exploit() { char* s = "/bin/sh"; execl(s, s, 0x0); } int main() { exploit(); } Must rewrite to remove nulls, or strcpy won’t work! Shellcode

12. 12 SY32 Secure Computing, Lecture 13 Crafting an Exploit "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07 \x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d \x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80 \xe8\xdc\xff\xff\xff/bin/sh" "\x90\x90..." No-opsShellcodeAddresses "\x58\x6f\xff\xbf..." (0xbffff658) Address chosen to ensure jump into no-ops at start of shellcode

13. 13 SY32 Secure Computing, Lecture 13 Demo

14. 14 SY32 Secure Computing, Lecture 13 Questions Are very small buffers susceptible to attack? Are very small buffers susceptible to attack? By how much must we overrun a buffer to execute shellcode? By how much must we overrun a buffer to execute shellcode?

15. 15 SY32 Secure Computing, Lecture 13 Off-By-One Errors void doSomething(const char* input) { char buffer[256]; strncpy(buffer, input, sizeof(buffer)); buffer[sizeof(buffer)] = '\0';... } Sensible choice of strncpy in place of strcpy Sensible choice of strncpy in place of strcpy …but attempt to null-terminate the copied string results in a one-byte overrun …but attempt to null-terminate the copied string results in a one-byte overrun

16. 16 SY32 Secure Computing, Lecture 13 Exploiting Off-by-One Errors Buffer Saved EBP Saved EIP Parameters Caller’s stack frame ESP EBP Preconditions Preconditions Buffer next to saved EBP Buffer next to saved EBP 32-bit alignment 32-bit alignment Little-endian architecture Little-endian architecture Event Event Attempt to null-terminate buffer contents, resulting in one-byte overrun Attempt to null-terminate buffer contents, resulting in one-byte overrun Consequences Consequences LSB of saved EBP now zero LSB of saved EBP now zero Saved EBP now points lower in memory—possibly into buffer itself Saved EBP now points lower in memory—possibly into buffer itself 0

17. 17 SY32 Secure Computing, Lecture 13 Exploiting Off-by-One Errors Just before function exit, saved EBP is popped off stack into EBP register Just before function exit, saved EBP is popped off stack into EBP register On function exit, saved EIP is restored to EIP register and control returns to caller On function exit, saved EIP is restored to EIP register and control returns to caller Just before caller exits, stack pointer is moved to address in EBP register, with aim of restoring the saved EIP… Just before caller exits, stack pointer is moved to address in EBP register, with aim of restoring the saved EIP… …instead, attacker-supplied address is loaded into EIP register, and we have control! …instead, attacker-supplied address is loaded into EIP register, and we have control!

18. 18 SY32 Secure Computing, Lecture 13 Third-Generation Flaws Format string vulnerabilities Format string vulnerabilities First appeared in Summer 2000 First appeared in Summer 2000 Affect the *printf family of functions Affect the *printf family of functions Allow reading from & writing to arbitrary addresses Allow reading from & writing to arbitrary addresses Easy to exploit, but also easy to find and fix Easy to exploit, but also easy to find and fix Heap overruns Heap overruns Less standardized than format string bugs Less standardized than format string bugs Allow writing of arbitrary data to arbitrary addresses Allow writing of arbitrary data to arbitrary addresses Hard to exploit, but also hard to detect Hard to exploit, but also hard to detect

19. 19 SY32 Secure Computing, Lecture 13 Format String Bugs Two ways of printing a string in C: Two ways of printing a string in C: printf("%s", input) printf("%s", input) printf(input) printf(input) Lazy programmers may do the latter, but what if input contains format specifiers? Lazy programmers may do the latter, but what if input contains format specifiers? %n specifier will write data onto the stack %n specifier will write data onto the stack Value could be address of some shellcode… Value could be address of some shellcode… …which could overwrite saved EIP in stack frame …which could overwrite saved EIP in stack frame

20. 20 SY32 Secure Computing, Lecture 13 Mitigation Coding practices Coding practices Choice of language Choice of language Use of library functions Use of library functions Memory protection Memory protection Recompilation of applications required Recompilation of applications required No recompilation required No recompilation required

21. 21 SY32 Secure Computing, Lecture 13 Coding Practices If possible, use languages with intrinsic run-time bounds checking instead of C or C++ If possible, use languages with intrinsic run-time bounds checking instead of C or C++ Java, C#, Python, Perl, etc Java, C#, Python, Perl, etc When writing C++, use its features rather than those of C standard library When writing C++, use its features rather than those of C standard library std::string class, not char* and strcpy, etc std::string class, not char* and strcpy, etc Use C library functions very carefully Use C library functions very carefully Never, ever, use gets ! Never, ever, use gets ! Prefer ‘safe’ versions of other functions Prefer ‘safe’ versions of other functions

22. 22 SY32 Secure Computing, Lecture 13 C Library Risks High-risk functions include High-risk functions include strcat, strcpy strcat, strcpy Use strncat, strncpy – carefully! Use strncat, strncpy – carefully! printf, sprintf, vsprintf printf, sprintf, vsprintf Always use a format string; use snprintf, not sprintf Always use a format string; use snprintf, not sprintf scanf, sscanf, vscanf, vsscanf scanf, sscanf, vscanf, vsscanf getopt, getpass, realpath, syslog getopt, getpass, realpath, syslog Truncate string arguments before passing them in Truncate string arguments before passing them in Some risk with other functions Some risk with other functions See WSC2 or BSS for more information See WSC2 or BSS for more information Always check destination buffer is as big as you are claiming, and watch out for off-by-one errors! Always check destination buffer is as big as you are claiming, and watch out for off-by-one errors!

23. 23 SY32 Secure Computing, Lecture 13 Safety Through Recompilation Compile against safer version of C library Compile against safer version of C library Use compiler support for array bounds checking Use compiler support for array bounds checking Patches for GCC: Patches for GCC: http://web.inter.nl.net/hcc/Haj.Ten.Brugge/ http://web.inter.nl.net/hcc/Haj.Ten.Brugge/ http://web.inter.nl.net/hcc/Haj.Ten.Brugge/ /RTCs compiler option in Visual C++.NET /RTCs compiler option in Visual C++.NET Protect return address on stack with a canary Protect return address on stack with a canary StackGuard, http://www.immunix.org/stackguard.html StackGuard, http://www.immunix.org/stackguard.html http://www.immunix.org/stackguard.html /GS compiler option in Visual C++.NET /GS compiler option in Visual C++.NET

24. 24 SY32 Secure Computing, Lecture 13 Transparent Protection Non-executable stack Non-executable stack Example: http://www.openwall.com/linux/ Example: http://www.openwall.com/linux/ http://www.openwall.com/linux/ Requires kernel patch Requires kernel patch Won’t trap overruns in heap, data or BSS segments Won’t trap overruns in heap, data or BSS segments libverify libverify Binary rewriting of process memory to force stack verification prior to use Binary rewriting of process memory to force stack verification prior to use libsafe, http://www.research.avayalabs.com/project/libsafe/ libsafe, http://www.research.avayalabs.com/project/libsafe/ http://www.research.avayalabs.com/project/libsafe/ Estimates safe upper limit on buffer size at run time Estimates safe upper limit on buffer size at run time Intercepts dangerous library calls, substituting versions that respect buffer size limit Intercepts dangerous library calls, substituting versions that respect buffer size limit

25. 25 SY32 Secure Computing, Lecture 13 Summary Buffer overruns and related flaws are the major cause of security problems in software Buffer overruns and related flaws are the major cause of security problems in software Attacks are varied, but typically involve transfer of control to shellcode supplied by attacker Attacks are varied, but typically involve transfer of control to shellcode supplied by attacker Partial solutions exist Partial solutions exist Compilation of run-time checks into code Compilation of run-time checks into code Transparent memory protection Transparent memory protection Best solution is to avoid C/C++ if possible, or avoid dangerous C library function calls Best solution is to avoid C/C++ if possible, or avoid dangerous C library function calls