DOCSLIB.ORG

Control Hijacking Attacks

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Control Hijacking Attacks Note: project 1 is out Section this Friday 3:15pm (Gates B01) Control hijacking attacks ! Attacker’s goal: n" Take over target machine (e.g. web server) w"Execute arbitrary code on target by hijacking application control flow ! This lecture: three examples. n" Buffer overflow attacks n" Integer overflow attacks n" Format string vulnerabilities ! Project 1: Build exploits 1. Buffer overflows ! Extremely common bug. n" First major exploit: 1988 Internet Worm. fingerd. 600 ≈"20% of all vuln. 500 400 2005-2007: ≈ 10% 300 200 100 0 Source: NVD/CVE 1995 1997 1999 2001 2003 2005 ! Developing buffer overflow attacks: n" Locate buffer overflow within an application. n" Design an exploit. What is needed ! Understanding C functions and the stack ! Some familiarity with machine code ! Know how systems calls are made ! The exec() system call ! Attacker needs to know which CPU and OS are running on the target machine: n" Our examples are for x86 running Linux n" Details vary slightly between CPUs and OSs: w"Little endian vs. big endian (x86 vs. Motorola) w"Stack Frame structure (Unix vs. Windows) w"Stack growth direction Linux process memory layout 0xC0000000 user stack %esp shared libraries 0x40000000 brk run time heap Loaded from exec 0x08048000 unused 0 Stack Frame Parameters Return address Stack Frame Pointer Local variables Stack Growth SP What are buffer overflows? ! Suppose a web server contains a function: void func(char *str) { char buf[128]; strcpy(buf, str); do-something(buf); } ! When the function is invoked the stack looks like: top buf sfp ret-addr str of stack ! What if *str is 136 bytes long? After strcpy: top *str ret str of stack Basic stack exploit ! Problem: no range checking in strcpy(). ! Suppose *str is such that after strcpy stack looks like: top *str ret NOP slide code for P of stack Program P: exec( “/bin/sh” ) (exact shell code by Aleph One) ! When func() exits, the user will be given a shell ! ! Note: attack code runs in stack. ! To determine ret guess position of stack when func() is called Many unsafe C lib functions strcpy (char *dest, const char *src) strcat (char *dest, const char *src) gets (char *s) scanf ( const char *format, … ) ! “Safe” versions strncpy(), strncat() are misleading n" strncpy() may leave buffer unterminated. n" strncpy(), strncat() encourage off by 1 bugs. Exploiting buffer overflows ! Suppose web server calls func() with given URL. n" Attacker sends a 200 byte URL. Gets shell on web server ! Some complications: n" Program P should not contain the ‘\0’ character. n" Overflow should not crash program before func() exists. ! Sample remote buffer overflows of this type: n" (2005) Overflow in MIME type field in MS Outlook. n" (2005) Overflow in Symantec Virus Detection Set test = CreateObject("Symantec.SymVAFileQuery.1") test.GetPrivateProfileString "file", [long string] Control hijacking opportunities ! Stack smashing attack: n" Override return address in stack activation record by overflowing a local buffer variable. ! Function pointers: (e.g. PHP 4.0.2, MS MediaPlayer Bitmaps) Heap buf[128] FuncPtr or stack n" Overflowing buf will override function pointer. ! Longjmp buffers: longjmp(pos) (e.g. Perl 5.003) n" Overflowing buf next to pos overrides value of pos. Heap-based control hijacking ! Compiler generated function pointers (e.g. C++ code) FP1 method #1 ptr FP2 method #2 FP3 method #3 data vtable Object T ! Suppose vtable is on the heap next to a string object: buf[256] vtable ptr data object T Heap-based control hijacking ! Compiler generated function pointers (e.g. C++ code) FP1 method #1 ptr FP2 method #2 FP3 method #3 data vtable Object T NOP shell slide code ! After overflow of buf : buf[256] vtable ptr data object T Other types of overflow attacks ! Integer overflows: (e.g. MS DirectX MIDI Lib) Phrack60 void func(int a, char v) { char buf[128]; init(buf); buf[a] = v; } n" Problem: a can point to `ret-addr’ on stack. ! Double free: double free space on heap. n" Can cause mem mgr to write data to specific location n" Examples: CVS server Integer overflow stats 140 120 100 80 60 40 20 Source: NVD/CVE 0 1996 1998 2000 2002 2004 2006 Finding buffer overflows ! To find overflow: n" Run web server on local machine n" Issue requests with long tags All long tags end with “$$$$$” n" If web server crashes, search core dump for “$$$$$” to find overflow location ! Many automated tools exist (called fuzzers – next lecture) ! Then use disassemblers and debuggers (e.g. IDA-Pro) to construct exploit Defenses Preventing hijacking attacks 1." Fix bugs: n" Audit software w"Automated tools: Coverity, Prefast/Prefix. n" Rewrite software in a type safe languange (Java, ML) w"Difficult for existing (legacy) code … 2." Concede overflow, but prevent code execution 3." Add runtime code to detect overflows exploits n" Halt process when overflow exploit detected n" StackGuard, LibSafe, … Marking memory as non-execute (W^X) ! Prevent overflow code execution by marking stack and heap segments as non-executable n" NX-bit on AMD Athlon 64, XD-bit on Intel P4 Prescott w"NX bit in every Page Table Entry (PTE) n" Deployment: w"Linux (via PaX project); OpenBSD w"Windows since XP SP2 (DEP) n" Boot.ini : /noexecute=OptIn or AlwaysOn n" Visual Studio: /NXCompat[:NO] ! Limitations: n" Some apps need executable heap (e.g. JITs). n" Does not defend against `return-to-libc’ exploit Examples: DEP controls in Windows DEP terminating a program Attack: return to libc ! Control hijacking without executing code stack libc.so args ret-addr exec() sfp printf() local buf “/bin/sh” ! Generalization: can generate arbitrary programs using return oriented programming Response: randomization ! ASLR: (Address Space Layout Randomization) n" Map shared libraries to rand location in process memory ⇒ Attacker cannot jump directly to exec function n" Deployment: (/DynamicBase) w"Windows Vista: 8 bits of randomness for DLLs n" aligned to 64K page in a 16MB region ⇒ 256 choices w"Linux (via PaX): 16 bits of randomness for libraries n" More effective on 64-bit architectures ! Other randomization methods: n" Sys-call randomization: randomize sys-call id’s n" Instruction Set Randomization (ISR) ASLR Example Booting Vista twice loads libraries into different locations: Note: ASLR is only applied to images for which the dynamic-relocation flag is set Attack: JiT spraying Idea: 1. Force Javascript JiT to fill heap with executable shellcode 2. then point SFP anywhere in spray area NOP slide shellcode execute enabled execute enabled heap execute enabled execute enabled vtable Run time checking Run time checking: StackGuard ! Many many run-time checking techniques … n" we only discuss methods relevant to overflow protection ! Solution 1: StackGuard n" Run time tests for stack integrity. n" Embed “canaries” in stack frames and verify their integrity prior to function return. Frame 2 Frame 1 top local canary sfp ret str local canary sfp ret str of stack Canary Types ! Random canary: n" Choose random string at program startup. n" Insert canary string into every stack frame. n" Verify canary before returning from function. n" To corrupt random canary, attacker must learn current random string. ! Terminator canary: Canary = 0, newline, linefeed, EOF n" String functions will not copy beyond terminator. n" Attacker cannot use string functions to corrupt stack. StackGuard (Cont.) ! StackGuard implemented as a GCC patch. n" Program must be recompiled. ! Minimal performance effects: 8% for Apache. ! Note: Canaries don’t offer fullproof protection. n" Some stack smashing attacks leave canaries unchanged ! Heap protection: PointGuard. n" Protects function pointers and setjmp buffers by encrypting them: XOR with random cookie n" Less effective, more noticeable performance effects StackGuard variants - ProPolice ! ProPolice (IBM) - gcc 3.4.1. (-fstack-protector) n" Rearrange stack layout to prevent ptr overflow. String args No arrays or pointers Growth ret addr SFP CANARY Stack arrays Growth local variables Ptrs, but no arrays MS Visual Studio /GS [2003] Compiler /GS option: n Combination of ProPolice and Random canary. n Triggers UnHandledException in case of Canary mismatch to shutdown process. ! Litchfield vulnerability report n" Overflow overwrites exception handler n" Redirects exception to attack code n" /SafeSEH: only call pre-designated exception handler Run time checking: Libsafe ! Solution 2: Libsafe (Avaya Labs) n" Dynamically loaded library (no need to recompile app.) n" Intercepts calls to strcpy (dest, src) w"Validates sufficient space in current stack frame: |frame-pointer – dest| > strlen(src) w"If so, does strcpy, otherwise, terminates application top sfp ret-addr dest src buf sfp ret-addr of stack libsafe main More methods … q" StackShield §" At function prologue, copy return address RET and SFP to “safe” location (beginning of data segment) §" Upon return, check that RET and SFP is equal to copy. §" Implemented as assembler file processor (GCC) q" Control Flow Integrity (CFI) §" A combination of static and dynamic checking §" Statically determine program control flow §" Dynamically enforce control flow integrity Format string bugs Format string problem int func(char *user) { fprintf( stderr, user); } Problem: what if user = “%s%s%s%s%s%s%s” ?? n" Most likely program will crash: DoS. n" If not, program will print memory contents. Privacy? n" Full exploit using user = “%n” Correct form: int func(char *user) { fprintf( stdout, “%s”, user); } History ! First exploit discovered in June 2000. ! Examples: n" wu-ftpd 2.* : remote root n" Linux rpc.statd: remote root n" IRIX telnetd: remote root n" BSD chpass: local root Vulnerable functions Any function using a format string. Printing: printf, fprintf, sprintf, … vprintf, vfprintf, vsprintf, … Logging: syslog, err, warn Exploit ! Dumping arbitrary memory: n" Walk up stack until desired pointer is found. n" printf( “%08x.%08x.%08x.%08x|%s|”) ! Writing to arbitrary memory: n" printf( “hello %n”, &temp) -- writes ‘6’ into temp.
Recommended publications
  • Heap Feng Shui in Javascript

    Heap Feng Shui in Javascript

    Heap Feng Shui in JavaScript Alexander Sotirov <[email protected]> Introduction The exploitation of heap corruption vulnerabilities on the Windows platform has become increasingly more difficult since the introduction of XP SP2. Heap protection features such as safe unlinking and heap cookies have been successful in stopping most generic heap exploitation techniques. Methods for bypassing the heap protection exist, but they require a great degree of control over the allocation patterns of the vulnerable application. This paper introduces a new technique for precise manipulation of the browser heap layout using specific sequences of JavaScript allocations. We present a JavaScript library with functions for setting up the heap in a controlled state before triggering a heap corruption bug. This allows us to exploit very difficult heap corruption vulnerabilities with great reliability and precision. We will focus on Internet Explorer exploitation, but the general techniques presented here are potentially applicable to any other browser or scripting environment. Previous work The most widely used browser heap exploitation technique is the heap spraying method developed by SkyLined for his Internet Explorer IFRAME exploit. This technique uses JavaScript to create multiple strings containing a NOP slide and shellcode. The JavaScript runtime stores the data for each string in a new block on the heap. Heap allocations usually start at the beginning of the address space and go up. After allocating 200MB of memory for the strings, any address between 50MB and 200MB is very likely to point at the NOP slide. Overwriting a return address or a function pointer with an address in this range will lead to a jump to the NOP slide and shellcode execution.
  • Understanding Integer Overflow in C/C++

    Understanding Integer Overflow in C/C++

    Appeared in Proceedings of the 34th International Conference on Software Engineering (ICSE), Zurich, Switzerland, June 2012. Understanding Integer Overflow in C/C++ Will Dietz,∗ Peng Li,y John Regehr,y and Vikram Adve∗ ∗Department of Computer Science University of Illinois at Urbana-Champaign fwdietz2,[email protected] ySchool of Computing University of Utah fpeterlee,[email protected] Abstract—Integer overflow bugs in C and C++ programs Detecting integer overflows is relatively straightforward are difficult to track down and may lead to fatal errors or by using a modified compiler to insert runtime checks. exploitable vulnerabilities. Although a number of tools for However, reliable detection of overflow errors is surprisingly finding these bugs exist, the situation is complicated because not all overflows are bugs. Better tools need to be constructed— difficult because overflow behaviors are not always bugs. but a thorough understanding of the issues behind these errors The low-level nature of C and C++ means that bit- and does not yet exist. We developed IOC, a dynamic checking tool byte-level manipulation of objects is commonplace; the line for integer overflows, and used it to conduct the first detailed between mathematical and bit-level operations can often be empirical study of the prevalence and patterns of occurrence quite blurry. Wraparound behavior using unsigned integers of integer overflows in C and C++ code. Our results show that intentional uses of wraparound behaviors are more common is legal and well-defined, and there are code idioms that than is widely believed; for example, there are over 200 deliberately use it.
  • A Defense Against Heap-Spraying Code Injection Attacks

    A Defense Against Heap-Spraying Code Injection Attacks

    Nozzle: A Defense Against Heap-spraying Code Injection Attacks Paruj Ratanaworabhan Benjamin Livshits and Benjamin Zorn Cornell University Microsoft Research Ithaca, NY Redmond, WA November 19, 2008 Microsoft Research Technical Report MSR-TR-2008-176 nnoozzllee 1 Abstract Heap spraying is a new security attack that significantly increases the exploitability of existing memory corruption errors in type-unsafe applications. With heap spraying, attackers leverage their ability to allocate arbitrary objects in the heap of a type-safe language, such as JavaScript, literally filling the heap with objects that contain danger- ous exploit code. In recent years, spraying has been used in many real security exploits, especially in web browsers. In this paper, we describe Nozzle, a runtime monitoring infrastructure that detects attempts by attackers to spray the heap. Nozzle uses lightweight emulation techniques to detect the presence of objects that contain executable code. To reduce false positives, we developed a notion of global “heap health”. We measure the effectiveness of Nozzle by demonstrating that it successfully detects 12 published and 2,000 synthetically generated heap-spraying exploits. We also show that even with a detection threshold set six times lower than is required to detect published ma- licious attacks, Nozzle reports no false positives when run over 150 popular Internet sites. Using sampling and concurrent scanning to re- duce overhead, we show that the performance overhead of Nozzle is less than 7% on average. While Nozzle currently targets heap-based spraying attacks, its techniques can be applied to a more general class of attacks in which an attacker attempts to fill the address space with dangerous code objects.
  • Collecting Vulnerable Source Code from Open-Source Repositories for Dataset Generation

    Collecting Vulnerable Source Code from Open-Source Repositories for Dataset Generation

    applied sciences Article Collecting Vulnerable Source Code from Open-Source Repositories for Dataset Generation Razvan Raducu * , Gonzalo Esteban , Francisco J. Rodríguez Lera and Camino Fernández Grupo de Robótica, Universidad de León. Avenida Jesuitas, s/n, 24007 León, Spain; [email protected] (G.E.); [email protected] (F.J.R.L.); [email protected] (C.F.) * Correspondence: [email protected] Received:29 December 2019; Accepted: 7 February 2020; Published: 13 February 2020 Abstract: Different Machine Learning techniques to detect software vulnerabilities have emerged in scientific and industrial scenarios. Different actors in these scenarios aim to develop algorithms for predicting security threats without requiring human intervention. However, these algorithms require data-driven engines based on the processing of huge amounts of data, known as datasets. This paper introduces the SonarCloud Vulnerable Code Prospector for C (SVCP4C). This tool aims to collect vulnerable source code from open source repositories linked to SonarCloud, an online tool that performs static analysis and tags the potentially vulnerable code. The tool provides a set of tagged files suitable for extracting features and creating training datasets for Machine Learning algorithms. This study presents a descriptive analysis of these files and overviews current status of C vulnerabilities, specifically buffer overflow, in the reviewed public repositories. Keywords: vulnerability; sonarcloud; bot; source code; repository; buffer overflow 1. Introduction In November 1988 the Internet suffered what is publicly known as “the first successful buffer overflow exploitation”. The exploit took advantage of the absence of buffer range-checking in one of the functions implemented in the fingerd daemon [1,2]. Even though it is considered to be the first exploited buffer overflow, different researchers had been working on buffer overflow for years.
  • Jitdefender: a Defense Against JIT Spraying Attacks

    Jitdefender: a Defense Against JIT Spraying Attacks

    JITDefender: A Defense against JIT Spraying Attacks Ping Chen, Yi Fang, Bing Mao, and Li Xie State Key Laboratory for Novel Software Technology, Nanjing University Department of Computer Science and Technology, Nanjing University, Nanjing 210093 {chenping,fangyi,maobing,xieli}@nju.edu.cn Abstract. JIT spraying is a new code-reuse technique to attack virtual machines based on JIT (Just-in-time) compilation. It has proven to be capable of circum- venting the defenses such as data execution prevention (DEP) and address space layout randomization(ASLR), which are effective for preventing the traditional code injection attacks. In this paper, we describe JITDefender, an enhancement of standard JIT-based VMs, which can prevent the attacker from executing arbi- trary JIT compiled code on the VM. Thereby JITDefender can block JIT spraying attacks. We prove the effectiveness of JITDefender by demonstrating that it can successfully prevent existing JIT spraying exploits. JITDefender reports no false positives when run over benign actionscript/javascript programs. In addition, we show that the performance overhead of JITDefender is low. 1 Introduction In recent years, attackers have resorted to code-reuse techniques instead of injecting their own malicious code. Typical techniques are Return-oriented Programming (ROP) [21], BCR [12] and Inspector [11]. Different code-reuse attacks launch the attack based on different codebases, including the application, shared libraries or even the kernel. However, all the techniques need to find useful instruction sequence in the codebase, and the task is tedious and costly in practice. Recently, a new code-reuse attack named JIT (Just-In-Time) spraying was proposed by Blazakis [10].
  • RICH: Automatically Protecting Against Integer-Based Vulnerabilities

    RICH: Automatically Protecting Against Integer-Based Vulnerabilities

    RICH: Automatically Protecting Against Integer-Based Vulnerabilities David Brumley, Tzi-cker Chiueh, Robert Johnson [email protected], [email protected], [email protected] Huijia Lin, Dawn Song [email protected], [email protected] Abstract against integer-based attacks. Integer bugs appear because programmers do not antici- We present the design and implementation of RICH pate the semantics of C operations. The C99 standard [16] (Run-time Integer CHecking), a tool for efficiently detecting defines about a dozen rules governinghow integer types can integer-based attacks against C programs at run time. C be cast or promoted. The standard allows several common integer bugs, a popular avenue of attack and frequent pro- cases, such as many types of down-casting, to be compiler- gramming error [1–15], occur when a variable value goes implementation specific. In addition, the written rules are out of the range of the machine word used to materialize it, not accompanied by an unambiguous set of formal rules, e.g. when assigning a large 32-bit int to a 16-bit short. making it difficult for a programmer to verify that he un- We show that safe and unsafe integer operations in C can derstands C99 correctly. Integer bugs are not exclusive to be captured by well-known sub-typing theory. The RICH C. Similar languages such as C++, and even type-safe lan- compiler extension compiles C programs to object code that guages such as Java and OCaml, do not raise exceptions on monitors its own execution to detect integer-based attacks.
  • Secure Coding Frameworks for the Development of Safe, Secure and Reliable Code

    Secure Coding Frameworks for the Development of Safe, Secure and Reliable Code

    Building Cybersecurity from the Ground Up Secure Coding Frameworks For the Development of Safe, Secure and Reliable Code Tim Kertis October 2015 The 27 th Annual IEEE Software Technology Conference Copyright © 2015 Raytheon Company. All rights reserved. Customer Success Is Our Mission is a registered trademark of Raytheon Company. Who Am I? Tim Kertis, Software Engineer/Software Architect Chief Software Architect, Raytheon IIS, Indianapolis Master of Science, Computer & Information Science, Purdue Software Architecture Professional through the Software Engineering Institute (SEI), Carnegie-Mellon University (CMU) 30 years of diverse Software Engineering Experience Advocate for Secure Coding Frameworks (SCFs) Author of the JAVA Secure Coding Framework (JSCF) Inventor of Cybersecurity thru Lexical And Symbolic Proxy (CLaSP) technology (patent pending) Secure Coding Frameworks 10/22/2015 2 Top 5 Cybersecurity Concerns … 1 - Application According to the 2015 ISC(2) Vulnerabilities Global Information Security 2 - Malware Workforce Study (Paresh 3 - Configuration Mistakes Rathod) 4 - Mobile Devices 5 - Hackers Secure Coding Frameworks 10/22/2015 3 Worldwide Market Indicators 2014 … Number of Software Total Cost of Cyber Crime: Developers: $500B (McCafee) 18,000,000+ (www.infoq.com) Cost of Cyber Incidents: Number of Java Software Low $1.6M Developers: Average $12.7M 9,000,000+ (www.infoq.com) High $61.0M (Ponemon Institute) Software with Vulnerabilities: 96% (www.cenzic.com) Secure Coding Frameworks 10/22/2015 4 Research
  • Integer Overflow

    Integer Overflow

    Lecture 05 – Integer overflow Stephen Checkoway University of Illinois at Chicago Unsafe functions in libc • strcpy • strcat • gets • scanf family (fscanf, sscanf, etc.) (rare) • printf family (more about these later) • memcpy (need to control two of the three parameters) • memmove (same as memcpy) Replacements • Not actually safe; doesn’t do what you think • strncpy • strncat • Available on Windows in C11 Annex K (the optional part of C11) • strcpy_s • strcat_s • BSD-derived, moderately widely available, including Linux kernel but not glibc • strlcpy • strlcat Buffer overflow vulnerability-finding strategy 1. Look for the use of unsafe functions 2. Trace attacker-controlled input to these functions Real-world examples from my own research • Voting machine: SeQuoia AVC Advantage • About a dozen uses of strcpy, most checked the length first • One did not. It appeared in infreQuently used code • Configuration file with fixed-width fields containing NUL-terminated strings, one of which was strcpy’d to the stack • Remote compromise of cars • Lots of strcpy of attacker-controlled Bluetooth data, first one examined was vulnerable • memcpy of attacker-controlled data from cellular modem Reminder: Think like an attacker • I skimmed some source code for a client/server protocol • The server code was full of trivial buffer overflows resulting from the attacker not following the protocol • I told the developer about the issue, but he wasn’t concerned because the client software he wrote wouldn’t send too much data • Most people don’t think like attackers. Three flavors of integer overflows 1. Truncation: Assigning larger types to smaller types int i = 0x12345678; short s = i; char c = i; Truncation example struct s { int main(int argc, char *argv[]) { unsigned short len; size_t len = strlen(argv[0]); char buf[]; }; struct s *p = malloc(len + 3); p->len = len; void foo(struct s *p) { strcpy(p->buf, argv[0]); char buffer[100]; if (p->len < sizeof buffer) foo(p); strcpy(buffer, p->buf); return 0; // Use buffer } } Three flavors of integer overflows 2.
  • Practical Integer Overflow Prevention

    Practical Integer Overflow Prevention

    Practical Integer Overflow Prevention Paul Muntean, Jens Grossklags, and Claudia Eckert {paul.muntean, jens.grossklags, claudia.eckert}@in.tum.de Technical University of Munich Memory error vulnerabilities categorized 160 Abstract—Integer overflows in commodity software are a main Other Format source for software bugs, which can result in exploitable memory Pointer 140 Integer Heap corruption vulnerabilities and may eventually contribute to pow- Stack erful software based exploits, i.e., code reuse attacks (CRAs). In 120 this paper, we present INTGUARD, a symbolic execution based tool that can repair integer overflows with high-quality source 100 code repairs. Specifically, given the source code of a program, 80 INTGUARD first discovers the location of an integer overflow error by using static source code analysis and satisfiability modulo 60 theories (SMT) solving. INTGUARD then generates integer multi- precision code repairs based on modular manipulation of SMT 40 Number of VulnerabilitiesNumber of constraints as well as an extensible set of customizable code repair 20 patterns. We evaluated INTGUARD with 2052 C programs (≈1 0 Mil. LOC) available in the currently largest open-source test suite 2000 2002 2004 2006 2008 2010 2012 2014 2016 for C/C++ programs and with a benchmark containing large and Year complex programs. The evaluation results show that INTGUARD Fig. 1: Integer related vulnerabilities reported by U.S. NIST. can precisely (i.e., no false positives are accidentally repaired), with low computational and runtime overhead repair programs with very small binary and source code blow-up. In a controlled flows statically in order to avoid them during runtime. For experiment, we show that INTGUARD is more time-effective and example, Sift [35], TAP [56], SoupInt [63], AIC/CIT [74], and achieves a higher repair success rate than manually generated CIntFix [11] rely on a variety of techniques depicted in detail code repairs.
  • Fighting the War in Memory

    Fighting the War in Memory

    Fighting the War in Memory Software Vulnerabilities and Defenses Today Antonio Hüseyin Barresi 2014 2 MorrisMorris WormWorm 3 Long ago – late 1980s • On November 2, 1988 the Morris Worm was released • Mainstream media attention • Conviction under the Computer Fraud and Abuse Act • First well-known program exploiting a buffer overflow http://en.wikipedia.org/wiki/Morris_worm 4 25 years later Memory errors and memory corruption vulnerabilities are still an issue! 5 This talk is about • Why these bugs are still a concern • How exploits work • Modern defenses 6 MotivationMotivation 7 Today, 2014 • Memory errors are still a problem • “Unsafe“ languages like C/C++ very popular • Prediction: C/C++ will be with us for a long time • Yes, there are alternatives... sometimes • Criminals found ways of monetization • Software systems are gaining complexity http://www.langpop.com/ http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html 8 Terminology Exploit “An exploit is a piece of software, a chunk of data, or a sequence of commands that takes advantage of a bug, glitch or vulnerability in order to...“ Zero-Day Attack “A zero-day attack or threat is an attack that exploits a previously unknown vulnerability in a computer application, ...“ http://en.wikipedia.org/wiki/Exploit_(computer_security) http://en.wikipedia.org/wiki/Zero-day_attack 9 Attacks Victim Attacker Runs a malicious web server serving HTML documents that trigger a memory error within the web browser Runs a vulnerable web browser or PDF reader Sends a malicious PDF attachement by email Exploits memory error within vulnerable victim software GET /index.html HTTP/1.1 Host: www.vulnsite.com Keep-Alive: 300 Connection: keep-alive $>./exploit 192.168.1.28 Cookie: CID=r2t5uvjq43 5r4q7ib3vtdjq120f83jf8 ..
  • Ada for the C++ Or Java Developer

    Ada for the C++ Or Java Developer

    Quentin Ochem Ada for the C++ or Java Developer Release 1.0 Courtesy of July 23, 2013 This work is licensed under a Creative Commons Attribution- NonCommercial-ShareAlike 3.0 Unported License. CONTENTS 1 Preface 1 2 Basics 3 3 Compilation Unit Structure 5 4 Statements, Declarations, and Control Structures 7 4.1 Statements and Declarations ....................................... 7 4.2 Conditions ................................................ 9 4.3 Loops ................................................... 10 5 Type System 13 5.1 Strong Typing .............................................. 13 5.2 Language-Defined Types ......................................... 14 5.3 Application-Defined Types ........................................ 14 5.4 Type Ranges ............................................... 16 5.5 Generalized Type Contracts: Subtype Predicates ............................ 17 5.6 Attributes ................................................. 17 5.7 Arrays and Strings ............................................ 18 5.8 Heterogeneous Data Structures ..................................... 21 5.9 Pointers .................................................. 22 6 Functions and Procedures 25 6.1 General Form ............................................... 25 6.2 Overloading ............................................... 26 6.3 Subprogram Contracts .......................................... 27 7 Packages 29 7.1 Declaration Protection .......................................... 29 7.2 Hierarchical Packages .........................................
  • Flashdetect: Actionscript 3 Malware Detection

    Flashdetect: Actionscript 3 Malware Detection

    FlashDetect: ActionScript 3 malware detection Timon Van Overveldt1, Christopher Kruegel23, and Giovanni Vigna23 1 Katholieke Universiteit Leuven, Belgium, [email protected] 2 University of California, Santa Barbara, USA, {chris,vigna}@cs.ucsb.edu 3 Lastline, Inc. Abstract. Adobe Flash is present on nearly every PC, and it is in- creasingly being targeted by malware authors. Despite this, research into methods for detecting malicious Flash files has been limited. Similarly, there is very little documentation available about the techniques com- monly used by Flash malware. Instead, most research has focused on JavaScript malware. This paper discusses common techniques such as heap spraying, JIT spraying, and type confusion exploitation in the context of Flash mal- ware. Where applicable, these techniques are compared to those used in malicious JavaScript. Subsequently, FlashDetect is presented, an off- line Flash file analyzer that uses both dynamic and static analysis, and that can detect malicious Flash files using ActionScript 3. FlashDetect classifies submitted files using a naive Bayesian classifier based on a set of predefined features. Our experiments show that FlashDetect has high classification accuracy, and that its efficacy is comparable with that of commercial anti-virus products. Keywords: Flash exploit analysis, malicious ActionScript 3 detection, Flash type confusion 1 Introduction Adobe Flash is a technology that provides advanced video playback and anima- tion capabilities to developers through an advanced scripting language. The files played by Flash, called SWFs, are often embedded into webpages to be played by a browser plugin, or are embedded into a PDF file to be played by a copy of the Flash Player included in Adobe’s Acrobat Reader.