Derandomizing Kernel Address Space Layout for Memory Introspection and Forensics
|
|
|
- Eustace Elliott
- 6 years ago
- Views:
Transcription
1 Derandomizing Kernel Address Space Layout for Memory Introspection and Forensics Yufei Gu, and Zhiqiang Lin The University of Texas at Dallas March 9 th, 2016
2 What is ASLR [Tea00] 0xbfffd5d8 0xbfffd618 caller s ebp buf 0xbfffd5d8 Shellcode
3 What is ASLR [Tea00] 0xbfffd5d8 0xbfffd618 caller s ebp buf 0xbfffd5d8 Shellcode ASLR
4 What is ASLR [Tea00] 0xbfffd5d8 0xbfffd5d8 0xbfffd618 caller s ebp buf 0xbfffe428 caller s ebp buf Shellcode ASLR Shellcode 0xbfffd5d8 0xbfffe3f8
5 What is ASLR [Tea00] 0xbfffd5d8 0xbfffd5d8 0xbfffd618 caller s ebp buf 0xbfffe428 caller s ebp buf Shellcode ASLR Shellcode 0xbfffd5d8 0xbfffe3f8 0xbfffd5d8 Oops
6 Why Kernel ASLR Kernel exploits Kernel buffer overflow Kernel ROP [Sha07, BRSS08] Kernel rootkits Tampering with the same virtual address
7 Why Kernel ASLR Kernel exploits Kernel buffer overflow Kernel ROP [Sha07, BRSS08] Kernel rootkits Tampering with the same virtual address Modern OS kernels including Windows, Linux, and Mac OS all have adopted kernel ASLR
8 Kernel ASLR 2007
9 Kernel ASLR 2007 Windows Vista
10 Kernel ASLR OS X Mountain Lion Windows Vista
11 Kernel ASLR OS X Mountain Lion Windows Vista Linux Kernel 3.14
12 Consequences of Kernel ASLR It significantly decreases the success rate of kernel memory exploits as well as some kernel rootkit attacks
13 Consequences of Kernel ASLR It significantly decreases the success rate of kernel memory exploits as well as some kernel rootkit attacks It also hinders the applications of 1 Kernel introspection [GR03] 2 Kernel memory forensics [Wal05]
14 Introspection [GR03] and Memory Forensics [Wal05] Linux Win 7 Introspection Product VM Product VM Virtualization Layer Hardware Layer
![Introspection [GR03] and Memory Forensics [Wal05] Linux Win 7 Introspection Product VM Product VM](/docs-images/76/73030398/images/15-3.jpg "Virtualization Layer Hardware Layer Introspection and forensic often need to know where kernel code and data")
15 Introspection [GR03] and Memory Forensics [Wal05] Linux Win 7 Introspection Product VM Product VM Virtualization Layer Hardware Layer Introspection and forensic often need to know where kernel code and data is located
16 Knowning the specific kernel address is important For an instrospection tool: 1 To interpret a system call event, it requires to know the address of the system call tables (e.g., [FLH13]) 2 To intercept the kernel object allocation and deallocation, it requires to know the addresses of the functions that manages the kernel heaps (e.g., [ZL15]) 3 To traverse certain dynamically allocated kernel objects, it needs to know their rooted global addresses (e.g., [FLB15])
17 Knowning the specific kernel address is important For an instrospection tool: 1 To interpret a system call event, it requires to know the address of the system call tables (e.g., [FLH13]) 2 To intercept the kernel object allocation and deallocation, it requires to know the addresses of the functions that manages the kernel heaps (e.g., [ZL15]) 3 To traverse certain dynamically allocated kernel objects, it needs to know their rooted global addresses (e.g., [FLB15]) For virtual machine introspection and forensics to be effective, we must derandomize kernel ASLR
18 Derandomizing ASLR at User Space
19 Derandomizing ASLR at User Space 1 Brute-force linear search [SPP + 04], which only requires 2 16 probes to derandomize the address space of a vulnerable program for a 32-bit ASLR implementation.
20 Derandomizing ASLR at User Space 1 Brute-force linear search [SPP + 04], which only requires 2 16 probes to derandomize the address space of a vulnerable program for a 32-bit ASLR implementation. 2 Information leakage [RMPB09] by exploiting information about the base address of libc, also code fragments available at fixed locations to discover the address of libc functions.
21 Derandomizing ASLR at User Space 1 Brute-force linear search [SPP + 04], which only requires 2 16 probes to derandomize the address space of a vulnerable program for a 32-bit ASLR implementation. 2 Information leakage [RMPB09] by exploiting information about the base address of libc, also code fragments available at fixed locations to discover the address of libc functions. 3 JIT-ROP [SMD + 13] attack, which leverages multiple memory disclosures to bypass the ASLR
22 Derandomizing ASLR at User Space 1 Brute-force linear search [SPP + 04], which only requires 2 16 probes to derandomize the address space of a vulnerable program for a 32-bit ASLR implementation. 2 Information leakage [RMPB09] by exploiting information about the base address of libc, also code fragments available at fixed locations to discover the address of libc functions. 3 JIT-ROP [SMD + 13] attack, which leverages multiple memory disclosures to bypass the ASLR These offensive approaches only have the remote access of the target machine
23 VMI and Forensics Have Local Access Linux Win 7 Introspection Product VM Product VM Virtualization Layer Hardware Layer
24 VMI and Forensics Have Local Access Linux Introspection Product VM Virtualization Layer Hardware Layer Win 7 Product VM VMI and forensics applications have the physical access of the target machine CPU registers Physical memory Too many options (e.g., too many signatures) for derandomization
25 Derandomization Kernel ASLR by Volatility [Wal05] Kernel Version Signature (Byte Sequence) Size (Bytes) VistaSP0x b VistaSP1x b VistaSP2x b VistaSP0x64 00 f8 ff ff 4b VistaSP1x64 00 f8 ff ff 4b VistaSP2x64 00 f8 ff ff 4b Win7SP1x64 00 f8 ff ff 4b Win7SP1x b Win7SP0x b Win7SP0x64 00 f8 ff ff 4b Win2008SP1x b Win2008SP2x b Win2008SP1x64 00 f8 ff ff 4b Win2008SP2x64 00 f8 ff ff 4b Win2008R2SP0x64 00 f8 ff ff 4b Win2008R2SP1x64 00 f8 ff ff 4b Win8SP0x b Win8SP1x b Win8SP0x64 03 f8 ff ff 4b Win8SP1x64 03 f8 ff ff 4b Win2012x64 03 f8 ff ff 4b Win2012R2x64 03 f8 ff ff 4b Table: KDBG Signatures used by Volatility to Derandomize the Kernel.
26 Problem Statement, Scope, Threat Model Problem Statement Investigate the optimal solutions for derandomizing the kernel address space for introspection and forensics 1 Robust 2 Efficient
27 Problem Statement, Scope, Threat Model Problem Statement Investigate the optimal solutions for derandomizing the kernel address space for introspection and forensics 1 Robust 2 Efficient Scope We focus on Linux kernel
28 Problem Statement, Scope, Threat Model Problem Statement Investigate the optimal solutions for derandomizing the kernel address space for introspection and forensics 1 Robust 2 Efficient Scope We focus on Linux kernel Threat Model Non Cooperative OS OS has been compromised
29 Solution Space Linux Win 7 Introspection Product VM Product VM Virtualization Layer Hardware Layer
30 Solution Space Linux Win 7 Introspection Product VM Virtualization Layer Hardware Layer Product VM Deriving signatures from Kernel Code Kernel Data
31 Solution Space Operating Systems Linux Kernel Virtualization Layer
32 Solution Space OS Kernel
33 Solution Space.rodata data heap text
34 Solution Space.rodata data heap text trusted rodata rodata text trusted text
35 Challenges from (Modifiable) Kernel Code 1 Relocation 2 Alternative Instructions 3 Symmetric Multiprocessing 4 Function Tracing
36 Relocation Relocation is typically needed by a linker when linking object code to produce the final executable. Relocation is also needed when loading kernel modules or loading ASLR-enabled kernel. Example 0xc : b9 00 b0 a7 00 mov ecx,0xa7b000 0xcc200033: b9 00 b0 b7 0c mov ecx,0xcb7b000 0xc : 89 0c c5 00 a0 9e c0 mov DWORD PTR [eax*8-0x3f616000],ecx 0xcc203045: 89 0c c5 00 a0 ae cc mov DWORD PTR [eax*8-0x ],ecx
37 Alternative Instructions Kerne will dynamically replace some (old) instructions with more efficient alternatives. Example #define mb() alternative("lock; addl $0,0(%%esp)", "mfence", X86_FEATURE_XMM2) 0xc : 8d lea esi,[esi+eiz*1+0x0] 0xcc201149: 0f xcc20114c: 90 prefetchnta BYTE PTR [eax] nop 0xc012c793: 8d lea esi,[esi+0x0] 0xcc22c793: 0f ae e8 lfence
38 An Overview of the Investigated Approaches Kernel memory
39 An Overview of the Investigated Approaches Kernel memory Kernel code Kernel data
40 An Overview of the Investigated Approaches Kernel memory Kernel code Kernel data Patched Kernel code Unpatched Kernel code
41 An Overview of the Investigated Approaches Kernel memory Kernel code Kernel data Patched Kernel code Unpatched Kernel code Patched code based Approach Unpatchedcode based Approach
42 An Overview of the Investigated Approaches Kernel memory Kernel code Kernel data Patched Kernel code Unpatched Kernel code 4.1 Brute-force Approach Patched code based Approach Unpatchedcode based Approach
43 An Overview of the Investigated Approaches Kernel memory Kernel code Kernel data 4.1 Patched Kernel code Unpatched Kernel code Brute-force Approach Read-only Kernel data Writable Kernel data Patched code based Approach Unpatchedcode based Approach
44 An Overview of the Investigated Approaches Kernel memory Kernel code Kernel data 4.1 Patched Kernel code Unpatched Kernel code Brute-force Approach Read-only Kernel data Writable Kernel data Patched code based Approach Unpatchedcode based Approach Read-only values,strings Read-only code pointers
45 An Overview of the Investigated Approaches Kernel memory Kernel code Kernel data 4.1 Patched Kernel code Unpatched Kernel code Brute-force Approach Read-only Kernel data Writable Kernel data Patched code based Approach Unpatchedcode based Approach Read-only values,strings Read-only code pointers 5.1 Read-only pointer based Approach
46 An Overview of the Investigated Approaches Kernel memory Kernel code Kernel data 4.1 Patched Kernel code Unpatched Kernel code Brute-force Approach Read-only Kernel data Writable Kernel data Patched code based Approach Unpatchedcode based Approach Read-only values,strings Read-only code pointers Robust Graph Signature 5.1 Robust Value Invariant Signature Read-only pointer based Approach
47 Approach-I: Brute-force Code Matching
48 Pros and Cons The simplest (no sophisticated analysis required), and has very strong robustness since it uses the entire kernel code as the signatures. May have false negatives when facing strong adversaries.
49 Approach-II: Using Patched Code (Relocation Entries [ARG15]) Code in Disk Image Base Address: 0xc c : c d c0 movl $0xc08015d8,(%esp) c : c mov %eax,0xc(%esp) c010045b: e call c c : e9 3c ff ff ff jmp c01003a1 c : 8d lea 0x0(%esi,%eiz,1),%esi c : 8d bc lea 0x0(%edi,%eiz,1),%edi c : 55 push %ebp c : 89 e5 mov %esp,%ebp c : e call c0683c80 c : a3 80 a7 8c c0 mov %eax,0xc08ca780 Code in Memory Snapshot Base Address: 0xcc cc200450: c d cc movl $0xcc9015d8,(%esp) cc200457: c mov %eax,0xc(%esp) cc20045b: e call cc cc200460: e9 3c ff ff ff jmp cc2003a1 cc200465: 8d lea 0x0(%esi,%eiz,1),%esi cc200469: 8d bc lea 0x0(%edi,%eiz,1),%edi cc200470: 55 push %ebp cc200471: 89 e5 mov %esp,%ebp cc200473: xchg %ax,%ax cc200478: a3 80 a7 9c cc mov %eax,0xcc9ca780
50 Approach-II: Using Patched Code (Relocation Entries [ARG15]) Code in Disk Image Base Address: 0xc c : c d c0 movl $0xc08015d8,(%esp) c : c mov %eax,0xc(%esp) c010045b: e call c c : e9 3c ff ff ff jmp c01003a1 c : 8d lea 0x0(%esi,%eiz,1),%esi c : 8d bc lea 0x0(%edi,%eiz,1),%edi c : 55 push %ebp c : 89 e5 mov %esp,%ebp c : e call c0683c80 c : a3 80 a7 8c c0 mov %eax,0xc08ca780 Code in Memory Snapshot Base Address: 0xcc cc200450: c d cc movl $0xcc9015d8,(%esp) cc200457: c mov %eax,0xc(%esp) cc20045b: e call cc cc200460: e9 3c ff ff ff jmp cc2003a1 cc200465: 8d lea 0x0(%esi,%eiz,1),%esi cc200469: 8d bc lea 0x0(%edi,%eiz,1),%edi cc200470: 55 push %ebp cc200471: 89 e5 mov %esp,%ebp cc200473: xchg %ax,%ax cc200478: a3 80 a7 9c cc mov %eax,0xcc9ca780
51 Approach-II: Using Patched Code (Relocation Entries [ARG15]) Code in Disk Image Base Address: 0xc c : c d c0 movl $0xc08015d8,(%esp) c : c mov %eax,0xc(%esp) c010045b: e call c c : e9 3c ff ff ff jmp c01003a1 c : 8d lea 0x0(%esi,%eiz,1),%esi c : 8d bc lea 0x0(%edi,%eiz,1),%edi c : 55 push %ebp c : 89 e5 mov %esp,%ebp c : e call c0683c80 c : a3 80 a7 8c c0 mov %eax,0xc08ca780 Relocation Entries Offset Type Name 1: c R_386_32.rodata 2: c010045c R_386_PC32 warn_slowpath_fmt 3: c R_386_PC32 mcount 4: c R_386_32.data Code in Memory Snapshot Base Address: 0xcc cc200450: c d cc movl $0xcc9015d8,(%esp) cc200457: c mov %eax,0xc(%esp) cc20045b: e call cc cc200460: e9 3c ff ff ff jmp cc2003a1 cc200465: 8d lea 0x0(%esi,%eiz,1),%esi cc200469: 8d bc lea 0x0(%edi,%eiz,1),%edi cc200470: 55 push %ebp cc200471: 89 e5 mov %esp,%ebp cc200473: xchg %ax,%ax cc200478: a3 80 a7 9c cc mov %eax,0xcc9ca780
52 Approach-II: Using Patched Code (Relocation Entries [ARG15]) Code in Disk Image Base Address: 0xc c : c d c0 movl $0xc08015d8,(%esp) c : c mov %eax,0xc(%esp) c010045b: e call c c : e9 3c ff ff ff jmp c01003a1 c : 8d lea 0x0(%esi,%eiz,1),%esi c : 8d bc lea 0x0(%edi,%eiz,1),%edi c : 55 push %ebp c : 89 e5 mov %esp,%ebp c : e call c0683c80 c : a3 80 a7 8c c0 mov %eax,0xc08ca780 Code in Memory Snapshot Base Address: 0xcc cc200450: c d cc movl $0xcc9015d8,(%esp) cc200457: c mov %eax,0xc(%esp) cc20045b: e call cc cc200460: e9 3c ff ff ff jmp cc2003a1 cc200465: 8d lea 0x0(%esi,%eiz,1),%esi cc200469: 8d bc lea 0x0(%edi,%eiz,1),%edi cc200470: 55 push %ebp cc200471: 89 e5 mov %esp,%ebp cc200473: xchg %ax,%ax cc200478: a3 80 a7 9c cc mov %eax,0xcc9ca780 Relocation Entries Offset Type Name 1: c R_386_32.rodata 2: c010045c R_386_PC32 warn_slowpath_fmt 3: c R_386_PC32 mcount 4: c R_386_32.data CodeIdentifier Approach V d V b = S V m V x = S 1: 0xc08015d8 0xc = 0x7015d8 1: 0xcc9015d8 0xcc = 0x7015d8 4: 0xc08ca780 0xc = 0x7ca780 4: 0xcc9ca780 0xcc = 0x7ca780
53 Approach-II: Using Patched Code (Relocation Entries [ARG15]) Code in Disk Image Base Address: 0xc c : c d c0 movl $0xc08015d8,(%esp) c : c mov %eax,0xc(%esp) c010045b: e call c c : e9 3c ff ff ff jmp c01003a1 c : 8d lea 0x0(%esi,%eiz,1),%esi c : 8d bc lea 0x0(%edi,%eiz,1),%edi c : 55 push %ebp c : 89 e5 mov %esp,%ebp c : e call c0683c80 c : a3 80 a7 8c c0 mov %eax,0xc08ca780 Code in Memory Snapshot Base Address: 0xcc cc200450: c d cc movl $0xcc9015d8,(%esp) cc200457: c mov %eax,0xc(%esp) cc20045b: e call cc cc200460: e9 3c ff ff ff jmp cc2003a1 cc200465: 8d lea 0x0(%esi,%eiz,1),%esi cc200469: 8d bc lea 0x0(%edi,%eiz,1),%edi cc200470: 55 push %ebp cc200471: 89 e5 mov %esp,%ebp cc200473: xchg %ax,%ax cc200478: a3 80 a7 9c cc mov %eax,0xcc9ca780 Relocation Entries Offset Type Name 1: c R_386_32.rodata 2: c010045c R_386_PC32 warn_slowpath_fmt 3: c R_386_PC32 mcount 4: c R_386_32.data CodeIdentifier Approach V d V b = S V m V x = S 1: 0xc08015d8 0xc = 0x7015d8 1: 0xcc9015d8 0xcc = 0x7015d8 4: 0xc08ca780 0xc = 0x7ca780 4: 0xcc9ca780 0xcc = 0x7ca780 Our approach V m V d = RandomizeOffset 1: 0xcc9015d8 0xc08015d8 = 0x0c : 0xcc9ca780 0xc08ca780 = 0x0c100000
54 Approach-III: Using Unpatched Patched Code Code in Disk Image Base Address: 0xc c : c d c0 movl $0xc08015d8,(%esp) c : c mov %eax,0xc(%esp) c010045b: e call c c : e9 3c ff ff ff jmp c01003a1 c : 8d lea 0x0(%esi,%eiz,1),%esi c : 8d bc lea 0x0(%edi,%eiz,1),%edi c : 55 push %ebp c : 89 e5 mov %esp,%ebp c : e call c0683c80 c : a3 80 a7 8c c0 mov %eax,0xc08ca780 Code in Memory Snapshot Base Address: 0xcc cc200450: c d cc movl $0xcc9015d8,(%esp) cc200457: c mov %eax,0xc(%esp) cc20045b: e call cc cc200460: e9 3c ff ff ff jmp cc2003a1 cc200465: 8d lea 0x0(%esi,%eiz,1),%esi cc200469: 8d bc lea 0x0(%edi,%eiz,1),%edi cc200470: 55 push %ebp cc200471: 89 e5 mov %esp,%ebp cc200473: xchg %ax,%ax cc200478: a3 80 a7 9c cc mov %eax,0xcc9ca780
55 Approach-III: Using Unpatched Patched Code Code in Disk Image Base Address: 0xc c : c d c0 movl $0xc08015d8,(%esp) c : c mov %eax,0xc(%esp) c010045b: e call c c : e9 3c ff ff ff jmp c01003a1 c : 8d lea 0x0(%esi,%eiz,1),%esi c : 8d bc lea 0x0(%edi,%eiz,1),%edi c : 55 push %ebp c : 89 e5 mov %esp,%ebp c : e call c0683c80 c : a3 80 a7 8c c0 mov %eax,0xc08ca780 Code in Memory Snapshot Base Address: 0xcc cc200450: c d cc movl $0xcc9015d8,(%esp) cc200457: c mov %eax,0xc(%esp) cc20045b: e call cc cc200460: e9 3c ff ff ff jmp cc2003a1 cc200465: 8d lea 0x0(%esi,%eiz,1),%esi cc200469: 8d bc lea 0x0(%edi,%eiz,1),%edi cc200470: 55 push %ebp cc200471: 89 e5 mov %esp,%ebp cc200473: xchg %ax,%ax cc200478: a3 80 a7 9c cc mov %eax,0xcc9ca780 Align two kernel code run-time images, and remove the diffed code Search code that never patched
56 Approach-IV: Using Read-Only Pointers Pointers in.rodata section Using.rel.rodata to locate them, similary to Approach-II in locating.rel.text
57 Implementation Approach Total Signature Generation Signature Matching Brute Force Patched Code Unpatched Code Readonly Pointer Table: Implementation Complexity (Units: LOC). C++ Python
58 Experiment Setup Using 20 Linux kernels from version 3.14 to 4.0. Running each of the tested Linux kernels in a VMware Workstation configured with 512M bytes RAM for the guest OS.
59 Effectiveness: Robustness OS-kernels Brute Force Patched code Unpatched code Readonly pointer Sig Bytes/Page Sig Bytes/Page Sig Bytes/Page Sig Bytes/Page Linux ,787,280 4, , , , Linux ,788,560 4, , , , Linux ,802,328 4, , , , Linux ,793,980 4, , , , Linux ,794,108 4, , , , Linux ,794,940 4, , , , Linux ,844,284 4, , , , Linux ,846,844 4, , , , Linux ,850,044 4, , , , Linux ,889,452 4, , , , Linux ,889,324 4, , , , Linux ,894,696 4, , , , Linux ,929,000 4, , , , Linux ,929,704 4, , , , Linux ,930,280 4, , , , Linux ,931,816 4, , , , Linux ,977,424 4, , , , Linux ,980,280 4, , , , Linux ,982,136 4, , , , Linux-4.0 6,015,102 4, , , , mean 5,882,580 4, , , , Table: Signature Size
60 Effectiveness: Match Ratio OS-kernels Brute Force Patched code Unpatched Data Readonly pointer Linux % % % % Linux % % % % Linux % % % % Linux % % % % Linux % % % % Linux % % % % Linux % % % % Linux % % % % Linux % % % % Linux % % % % Linux % % % % Linux % % % % Linux % % % % Linux % % % % Linux % % % % Linux % % % % Linux % % % % Linux % % % % Linux % % % % Linux % % % % mean 95.41% % % %
61 Performance Matching Time(s) Linux Linux Linux Linux-3.15 Linux Linux Linux-3.16 Brute Force Patched Code Unpatched Code Readonly Pointer Linux Linux Linux-3.17 Linux Linux Linux-3.18 Linux Linux Linux Linux-3.19 Linux Linux Linux-4.0 Fig. 7. Signature Matching Performance Figure: Signature Matching Performance
62 Discussions Open Problems When attacker learns the signatures, he/she can generate data with these sigatures though they cannot modify the signatures. e.g., load a copy of the kernel code into the kernel memory Prunning bogus signatures.
63 Discussions Open Problems When attacker learns the signatures, he/she can generate data with these sigatures though they cannot modify the signatures. e.g., load a copy of the kernel code into the kernel memory Prunning bogus signatures. Future Work Writable data (e.g., SigGraph [LRZ + 11]) Other read-only data (e.g., Robust Signatures [DGSTG09])
64 Summary Derandomizing Kernel ASLR for Introspection and Forensics We examined the possible optimal approaches from both kernel code and kernel data. Brute-force Approach Patched code based Approach Unpatched code based Approach Read-only pointer based Approach
65 Q&A Kernel memory Kernel code Kernel data 4.1 Patched Kernel code Unpatched Kernel code Brute-force Approach Read-only Kernel data Writable Kernel data Patched code based Approach Unpatchedcode based Approach Read-only values,strings Read-only code pointers Robust Graph Signature 5.1 Robust Value Invariant Signature Read-only pointer based Approach Source code is available at
66 References I Irfan Ahmed, Vassil Roussev, and Aisha Ali Gombe, Robust fingerprinting for relocatable code, Proceedings of the 5th ACM Conference on Data and Application Security and Privacy, CODASPY 2015, San Antonio, TX, USA, March 2-4, 2015, 2015, pp Erik Buchanan, Reins Roemer, Hovav Shacham, and Stefan Savage, When good instructions go bad: generalizing return-oriented programming to risc, Proc. 15th ACM Conf. Computer and communications security (CCS 08) (Alexandria, Virginia, USA), ACM, 2008, pp Brendan Dolan-Gavitt, Abhinav Srivastava, Patrick Traynor, and Jonathon Giffin, Robust signatures for kernel data structures, Proc. 16th ACM Conf. Computer and Communications Security (CCS 09) (Chicago, Illinois, USA), ACM, 2009, pp Yangchun Fu, Zhiqiang Lin, and David Brumley, Automatically deriving pointer reference expressions from executions for memory dump analysis, Proceedings of the 2015 ACM SIGSOFT International Symposium on Foundations of Software Engineering (FSE 15) (Bergamo, Italy), September Yangchun Fu, Zhiqiang Lin, and Kevin Hamlen, Subverting systems authentication with context-aware, reactive virtual machine introspection, Proceedings of the 29th Annual Computer Security Applications Conference (ACSAC 13) (New Orleans, Louisiana), December Tal Garfinkel and Mendel Rosenblum, A virtual machine introspection based architecture for intrusion detection, Proc. Network and Distributed Systems Security Sym. (NDSS 03), February Zhiqiang Lin, Junghwan Rhee, Xiangyu Zhang, Dongyan Xu, and Xuxian Jiang, Siggraph: Brute force scanning of kernel data structure instances using graph-based signatures, Proc. 18th Annual Network and Distributed System Security Sym. (NDSS 11) (San Diego, CA), February 2011.
67 References II Giampaolo Fresi Roglia, Lorenzo Martignoni, Roberto Paleari, and Danilo Bruschi, Surgically returning to randomized lib(c), Proceedings of the 25 th Annual Computer Security Applications Conference (ACSAC), IEEE Computer Society, December 2009, Honolulu, Hawaii, USA, pp Hovav Shacham, The geometry of innocent flesh on the bone: return-into-libc without function calls (on the x86), Proc. 14th ACM Conf. Computer and communications security (CCS 07) (Alexandria, Virginia, USA), ACM, 2007, pp Kevin Z Snow, Fabian Monrose, Lucas Davi, Alexandra Dmitrienko, Christopher Liebchen, and Ahmad-Reza Sadeghi, Just-in-time code reuse: On the effectiveness of fine-grained address space layout randomization, Security and Privacy (SP), 2013 IEEE Symposium on, IEEE, 2013, pp Hovav Shacham, Matthew Page, Ben Pfaff, Eu-Jin Goh, Nagendra Modadugu, and Dan Boneh, On the effectiveness of address-space randomization, Proceedings of the 11th ACM Conference on Computer and Communications Security (New York, NY, USA), CCS 04, ACM, 2004, pp PaX Team, Pax address space layout randomization (aslr), (2000). AAron Walters, The volatility framework: Volatile memory artifact extraction utility framework, 2005, Junyuan Zeng and Zhiqiang Lin, Towards automatic inference of kernel object semantics from binary code, Proceedings of the 18th International Symposium on Research in Attacks, Intrusions and Defenses (RAID 15) (Kyoto, Japan), November 2015.
CSE 127: Computer Security Control Flow Hijacking. Kirill Levchenko
CSE 127: Computer Security Control Flow Hijacking Kirill Levchenko October 17, 2017 Control Flow Hijacking Defenses Avoid unsafe functions Stack canary Separate control stack Address Space Layout Randomization
On The Effectiveness of Address-Space Randomization. H. Shacham, M. Page, B. Pfaff, E.-J. Goh, N. Modadugu, and D. Boneh Stanford University CCS 2004
On The Effectiveness of Address-Space Randomization H. Shacham, M. Page, B. Pfaff, E.-J. Goh, N. Modadugu, and D. Boneh Stanford University CCS 2004 Code-Injection Attacks Inject malicious executable code
The Geometry of Innocent Flesh on the Bone
The Geometry of Innocent Flesh on the Bone Return-into-libc without Function Calls (on the x86) Hovav Shacham hovav@cs.ucsd.edu CCS 07 Technical Background Gadget: a short instructions sequence (e.x. pop
Robust Shell Code Return Oriented Programming and HeapSpray. Zhiqiang Lin
CS 6V81-05: System Security and Malicious Code Analysis Robust Shell Code Return Oriented Programming and HeapSpray Zhiqiang Lin Department of Computer Science University of Texas at Dallas April 16 th,
OS-SOMMELIER: Memory-Only Operating System Fingerprinting in the Cloud
OS-SOMMELIER: Memory-Only Operating System Fingerprinting in the Cloud Yufei Gu, Yangchun Fu, Aravind Prakash Dr. Zhiqiang Lin, Dr. Heng Yin University of Texas at Dallas Syracuse University October 16
Return-orientated Programming
Return-orientated Programming or The Geometry of Innocent Flesh on the Bone: Return-into-libc without Function Calls (on the x86) Hovav Shacham, CCS '07 Return-Oriented oriented Programming programming
Outline. Memory Exploit
Outline CS 6V81-05: System Security and Malicious Code Analysis Robust Shell Code Return Oriented Programming and HeapSpray Zhiqiang Lin Department of Computer Science University of Texas at Dallas April
Lecture 08 Control-flow Hijacking Defenses
Lecture 08 Control-flow Hijacking Defenses Stephen Checkoway University of Illinois at Chicago CS 487 Fall 2017 Slides adapted from Miller, Bailey, and Brumley Control Flow Hijack: Always control + computation
Inject malicious code Call any library functions Modify the original code
Inject malicious code Call any library functions Modify the original code 2 Sadeghi, Davi TU Darmstadt 2012 Secure, Trusted, and Trustworthy Computing Chapter 6: Runtime Attacks 2 3 Sadeghi, Davi TU Darmstadt
Virtual Machine Introspection Bhushan Jain
Virtual Machine Introspection Bhushan Jain Computer Science Department Stony Brook University 1 Traditional Environment Operating System 2 Traditional Environment Process Descriptors Kernel Heap Operating
This time. Defenses and other memory safety vulnerabilities. Everything you ve always wanted to know about gdb but were too afraid to ask
This time We will continue Buffer overflows By looking at Overflow Defenses and other memory safety vulnerabilities Everything you ve always wanted to know about gdb but were too afraid to ask Overflow
Leveraging Relocations in ELF-Binaries for Linux Kernel Version Identification
DIGITAL FORENSIC RESEARCH CONFERENCE Leveraging Relocations in ELF-Binaries for Linux Kernel Version Identification By Manish Bhatt, Irfan Ahmed From the proceedings of The Digital Forensic Research Conference
Module: Return-oriented Programming. Professor Trent Jaeger. CSE543 - Introduction to Computer and Network Security
CSE543 - Introduction to Computer and Network Security Module: Return-oriented Programming Professor Trent Jaeger 1 1 Anatomy of Control-Flow Exploits Two steps in control-flow exploitation First -- attacker
Advanced Buffer Overflow
Pattern Recognition and Applications Lab Advanced Buffer Overflow Ing. Davide Maiorca, Ph.D. davide.maiorca@diee.unica.it Computer Security A.Y. 2016/2017 Department of Electrical and Electronic Engineering
The geometry of innocent flesh on the bone: Return-into-libc without function calls (on the x86) Hovav Shacham presented by: Fabian Fäßler
The geometry of innocent flesh on the bone: Return-into-libc without function calls (on the x86) Hovav Shacham presented by: Fabian Fäßler return-oriented programming Hovav Shacham presented by: Fabian
Q: Exploit Hardening Made Easy
Q: Exploit Hardening Made Easy E.J. Schwartz, T. Avgerinos, and D. Brumley. In Proc. USENIX Security Symposium, 2011. CS 6301-002: Language-based Security Dr. Kevin Hamlen Attacker s Dilemma Problem Scenario
Background SigGraph KOP Summary CS 6V Kernel Rootkit Defense I: Graph-based Scanning Approach. Zhiqiang Lin
CS 6V81-05 Kernel Rootkit Defense I: Graph-based Scanning Approach Zhiqiang Lin Department of Computer Science The University of Texas at Dallas September 2 nd, 2011 Outline 1 Background 2 SigGraph 3 KOP
Return-Oriented Rootkits
Return-Oriented Rootkits Ralf Hund Troopers March 10, 2010 What is Return-Oriented Programming? New emerging attack technique, pretty hyped topic Gained awareness in 2007 in Hovav Shacham s paper The Geometry
Exercise 6: Buffer Overflow and return-into-libc Attacks
Technische Universität Darmstadt Fachbereich Informatik System Security Lab Prof. Dr.-Ing. Ahmad-Reza Sadeghi M.Sc. David Gens Exercise 6: Buffer Overflow and return-into-libc Attacks Course Secure, Trusted
2 Sadeghi, Davi TU Darmstadt 2012 Secure, Trusted, and Trustworthy Computing Chapter 6: Runtime Attacks
Runtime attacks are major threats to today's applications Control-flow of an application is compromised at runtime Typically, runtime attacks include injection of malicious code Reasons for runtime attacks
20: Exploits and Containment
20: Exploits and Containment Mark Handley Andrea Bittau What is an exploit? Programs contain bugs. These bugs could have security implications (vulnerabilities) An exploit is a tool which exploits a vulnerability
Space Traveling across VM
Space Traveling across VM Automatically Bridging the Semantic-Gap in Virtual Machine Introspection via Online Kernel Data Redirection Yangchun Fu, and Zhiqiang Lin Department of Computer Sciences The University
Abstraction Recovery for Scalable Static Binary Analysis
Abstraction Recovery for Scalable Static Binary Analysis Edward J. Schwartz Software Engineering Institute Carnegie Mellon University 1 The Gap Between Binary and Source Code push mov sub movl jmp mov
Return-Oriented Rootkits: Bypassing Kernel Code Integrity Protection Mechanisms
Return-Oriented Rootkits: Bypassing Kernel Code Integrity Protection Mechanisms Ralf Hund Thorsten Holz Felix C. Freiling University of Mannheim Page 1 Motivation (1) Operating systems separate system
Selected background on ARM registers, stack layout, and calling convention
Selected background on ARM registers, stack layout, and calling convention ARM Overview ARM stands for Advanced RISC Machine Main application area: Mobile phones, smartphones (Apple iphone, Google Android),
Advanced Buffer Overflow
Pattern Recognition and Applications Lab Advanced Buffer Overflow Ing. Davide Maiorca, Ph.D. davide.maiorca@diee.unica.it Computer Security A.Y. 2017/2018 Department of Electrical and Electronic Engineering
CSC 591 Systems Attacks and Defenses Return-into-libc & ROP
CSC 591 Systems Attacks and Defenses Return-into-libc & ROP Alexandros Kapravelos akaprav@ncsu.edu NOEXEC (W^X) 0xFFFFFF Stack Heap BSS Data 0x000000 Code RW RX Deployment Linux (via PaX patches) OpenBSD
Module: Return-oriented Programming. Professor Trent Jaeger. CSE543 - Introduction to Computer and Network Security
CSE543 - Introduction to Computer and Network Security Module: Return-oriented Programming Professor Trent Jaeger 1 Anatomy of Control-Flow Exploits 2 Anatomy of Control-Flow Exploits Two steps in control-flow
HideM: Protecting the Contents of Userspace Memory in the Face of Disclosure Vulnerabilities
HideM: Protecting the Contents of Userspace Memory in the Face of Disclosure Vulnerabilities Jason Gionta, William Enck, Peng Ning 1 JIT-ROP 2 Two Attack Categories Injection Attacks Code Integrity Data
Memory corruption vulnerability exposure can be mitigated through memory hardening practices
Memory corruption vulnerability exposure can be mitigated through memory hardening practices OS vendors have a unique opportunity to fight memory corruption vulnerabilities through hardening the memory
CS 161 Computer Security
Paxson Spring 2017 CS 161 Computer Security Discussion 2 Question 1 Software Vulnerabilities (15 min) For the following code, assume an attacker can control the value of basket passed into eval basket.
Overview REWARDS TIE HOWARD Summary CS 6V Data Structure Reverse Engineering. Zhiqiang Lin
CS 6V81-05 Data Structure Reverse Engineering Zhiqiang Lin Department of Computer Science The University of Texas at Dallas September 2 nd, 2011 Outline 1 Overview 2 REWARDS 3 TIE 4 HOWARD 5 Summary Outline
Extended Page Tables (EPT) A VMM must protect host physical memory Multiple guest operating systems share the same host physical memory VMM typically implements protections through page-table shadowing
CSE 127: Computer Security. Memory Integrity. Kirill Levchenko
CSE 127: Computer Security Memory Integrity Kirill Levchenko November 18, 2014 Stack Buffer Overflow Stack buffer overflow: writing past end of a stackallocated buffer Also called stack smashing One of
Defeating Return-Oriented Rootkits with Return-less Kernels
5 th ACM SIGOPS EuroSys Conference, Paris, France April 15 th, 2010 Defeating Return-Oriented Rootkits with Return-less Kernels Jinku Li, Zhi Wang, Xuxian Jiang, Mike Grace, Sina Bahram Department of Computer
kguard++: Improving the Performance of kguard with Low-latency Code Inflation
kguard++: Improving the Performance of kguard with Low-latency Code Inflation Jordan P. Hendricks Brown University Abstract In this paper, we introduce low-latency code inflation for kguard, a GCC plugin
Just-in-Time Code Reuse
Just-in-Time Code Reuse The more things change, the more they stay the same Kevin Z. Snow 1 Luca Davi 2 & A. Dmitrienko 2 C. Liebchen 2 F. Monrose 1 A.-R. Sadeghi 2 1 Department of Computer Science University
CS 161 Computer Security
Paxson Spring 2013 CS 161 Computer Security Discussion 2 January 30, 2013 Question 1 Buffer Overflow Mitigations (10 min) Buffer overflow mitigations generally fall into two categories: (i) eliminating
Using Hashing to Improve Volatile Memory Forensic Analysis
Using Hashing to Improve Volatile Memory Forensic Analysis American Academy of Forensic Sciences Annual Meeting February 21, 2008 AAron Walters awalters@volatilesystems.com Blake Matheny, LLC Center for
Applying Return Oriented and Jump Oriented Programming Exploitation Techniques with Heap Spraying
Acta Polytechnica Hungarica Vol. 12, No. 5, 2015 Applying Return Oriented and Jump Oriented Programming Exploitation Techniques with Heap Spraying László Erdődi Óbuda University, Faculty of Applied Informatics
Remix: On-demand Live Randomization
Remix: On-demand Live Randomization Yue Chen, Zhi Wang, David Whalley, Long Lu* Florida State University, Stony Brook University* Background Buffer Overflow -> Code Injection Attack Background Buffer Overflow
CMPSC 497 Buffer Overflow Vulnerabilities
Systems and Internet Infrastructure Security Network and Security Research Center Department of Computer Science and Engineering Pennsylvania State University, University Park PA CMPSC 497 Buffer Overflow
Outline. Format string attack layout. Null pointer dereference
CSci 5271 Introduction to Computer Security Day 5: Low-level defenses and counterattacks Stephen McCamant University of Minnesota, Computer Science & Engineering Null pointer dereference Format string
Toward Guest OS Writable Virtual Machine Introspection
Toward Guest OS Writable Virtual Machine Introspection Zhiqiang Lin The University of Texas at Dallas zhiqiang.lin@utdallas.edu Abstract Over the past decade, a great deal of research on virtual machine
What Cannot be Read, Cannot be Leveraged?
What Cannot be Read, Cannot be Leveraged? Revisiting Assumptions of JIT-ROP Defenses Giorgi Maisuradze, Michael Backes, Christian Rossow CISPA, Saarland University, Germany Overview Code Reuse Attacks/Defenses
Software Security: Buffer Overflow Defenses
CSE 484 / CSE M 584: Computer Security and Privacy Software Security: Buffer Overflow Defenses Fall 2017 Franziska (Franzi) Roesner franzi@cs.washington.edu Thanks to Dan Boneh, Dieter Gollmann, Dan Halperin,
CSE543 - Computer and Network Security Module: Virtualization
CSE543 - Computer and Network Security Module: Virtualization Professor Trent Jaeger CSE543 - Introduction to Computer and Network Security 1 1 Operating System Quandary Q: What is the primary goal of
Architecture-level Security Vulnerabilities
Architecture-level Security Vulnerabilities Björn Döbel Outline How stacks work Smashing the stack for fun and profit Preventing stack smashing attacks Circumventing stack smashing prevention The Battlefield:
Software Security: Buffer Overflow Attacks (continued)
CSE 484 / CSE M 584: Computer Security and Privacy Software Security: Buffer Overflow Attacks (continued) Spring 2015 Franziska (Franzi) Roesner franzi@cs.washington.edu Thanks to Dan Boneh, Dieter Gollmann,
CS261 Scribe Notes: Secure Computation 1
CS261 Scribe Notes: Secure Computation 1 Scriber: Cameron Rasmussen October 24, 2018 1 Introduction It is often the case that code is being run locally on our system that isn t completely trusted, a prime
Lecture 10 Return-oriented programming. Stephen Checkoway University of Illinois at Chicago Based on slides by Bailey, Brumley, and Miller
Lecture 10 Return-oriented programming Stephen Checkoway University of Illinois at Chicago Based on slides by Bailey, Brumley, and Miller ROP Overview Idea: We forge shellcode out of existing application
Testing System Virtual Machines
Testing System Virtual Machines Lorenzo Martignoni 1 Roberto Paleari 2 Giampaolo Fresi Roglia 2 Danilo Bruschi 2 1 Università degli Studi di Udine 2 Università degli Studi di Milano International Conference
Launching Return-Oriented Programming Attacks against Randomized Relocatable Executables
2011 International Joint Conference of IEEE TrustCom-11/IEEE ICESS-11/FCST-11 Launching Return-Oriented Programming Attacks against Randomized Relocatable Executables Limin Liu Jin Han Debin Gao Jiwu Jing
Countermeasures in Modern Operating Systems. Yves Younan, Vulnerability Research Team (VRT)
Countermeasures in Modern Operating Systems Yves Younan, Vulnerability Research Team (VRT) Introduction Programs in C/C++: memory error vulnerabilities Countermeasures (mitigations): make exploitation
Stephen Checkoway, Lucas Davi, Alexandra Dmitrienko, Ahmad-Reza Sadeghi, Hovav Shacham, Marcel Winandy. ACM CCS 2010, Chicago, USA
Stephen Checkoway, Lucas Davi, Alexandra Dmitrienko, Ahmad-Reza Sadeghi, Hovav Shacham, Marcel Winandy ACM CCS 2010, Chicago, USA Ad hoc defense against code injection: W X DEP Code injection unnecessary
CSE543 - Computer and Network Security Module: Virtualization
CSE543 - Computer and Network Security Module: Virtualization Professor Trent Jaeger CSE543 - Introduction to Computer and Network Security 1 Operating System Quandary Q: What is the primary goal of system
Exploiting Stack Buffer Overflows Learning how blackhats smash the stack for fun and profit so we can prevent it
Exploiting Stack Buffer Overflows Learning how blackhats smash the stack for fun and profit so we can prevent it 29.11.2012 Secure Software Engineering Andreas Follner 1 Andreas Follner Graduated earlier
CSC 405 Computer Security Stack Canaries & ASLR
CSC 405 Computer Security Stack Canaries & ASLR Alexandros Kapravelos akaprav@ncsu.edu How can we prevent a buffer overflow? Check bounds Programmer Language Stack canaries [...more ] Buffer overflow defenses
Introduction to Reverse Engineering. Alan Padilla, Ricardo Alanis, Stephen Ballenger, Luke Castro, Jake Rawlins
Introduction to Reverse Engineering Alan Padilla, Ricardo Alanis, Stephen Ballenger, Luke Castro, Jake Rawlins Reverse Engineering (of Software) What is it? What is it for? Binary exploitation (the cool
Multi-Aspect Profiling of Kernel Rootkit Behavior
Multi-Aspect Profiling of Kernel Rootkit Behavior Ryan Riley, Xuxian Jiang, Dongyan Xu Purdue University, North Carolina State University EuroSys 2009 Nürnberg, Germany Rootkits Stealthy malware Hide attacker
Architecture-level Security Vulnerabilities. Julian Stecklina
Architecture-level Security Vulnerabilities Julian Stecklina Outline How stacks work Smashing the stack for fun and profit Preventing stack smashing attacks Circumventing stack smashing prevention The
Information Leaks. Kyriakos Kyriakou
Information Leaks Kyriakos Kyriakou kkyria16@cs.ucy.ac.cy University of Cyprus EPL 682: Advanced Security Topics 1 Just-in-time Code Reuse On the effectiveness of Fine-Grained Address Space Layout Randomization
BUFFER OVERFLOW DEFENSES & COUNTERMEASURES
BUFFER OVERFLOW DEFENSES & COUNTERMEASURES CMSC 414 FEB 01 2018 RECALL OUR CHALLENGES How can we make these even more difficult? Putting code into the memory (no zeroes) Finding the return address (guess
Runtime attacks are major threats to today's applications Control-flow of an application is compromised at runtime Typically, runtime attacks include
2 Runtime attacks are major threats to today's applications Control-flow of an application is compromised at runtime Typically, runtime attacks include injection of malicious code Reasons for runtime attacks
CS 6V Program Analysis I: Dynamic Detection of Likely Invariants and Robust Signatures for Kernel Data Structure.
CS 6V81-05 Program Analysis I: Dynamic Detection of Likely Invariants and Robust Signatures for Kernel Data Structure Junyuan Zeng Department of Computer Science The University of Texas at Dallas November
The first Secure Programming Laboratory will be today! 3pm-6pm in Forrest Hill labs 1.B31, 1.B32.
Lab session this afternoon Memory corruption attacks Secure Programming Lecture 6: Memory Corruption IV (Countermeasures) David Aspinall, Informatics @ Edinburgh 2nd February 2016 The first Secure Programming
AIT 682: Network and Systems Security
AIT 682: Network and Systems Security Topic 9. Moving Target Defenser Instructor: Dr. Kun Sun Outline Introduction of Moving Target Defense How to defeat Buffer Overflow attacks? Address Space Layout Randomization
CNIT 127: Exploit Development. Ch 14: Protection Mechanisms. Updated
CNIT 127: Exploit Development Ch 14: Protection Mechanisms Updated 3-25-17 Topics Non-Executable Stack W^X (Either Writable or Executable Memory) Stack Data Protection Canaries Ideal Stack Layout AAAS:
Secure Programming Lecture 6: Memory Corruption IV (Countermeasures)
Secure Programming Lecture 6: Memory Corruption IV (Countermeasures) David Aspinall, Informatics @ Edinburgh 2nd February 2016 Outline Announcement Recap Containment and curtailment Tamper detection Memory
CSE543 - Computer and Network Security Module: Virtualization
CSE543 - Computer and Network Security Module: Virtualization Professor Trent Jaeger CSE543 - Introduction to Computer and Network Security 1 Operating System Quandary Q: What is the primary goal of system
Runtime Attacks: Buffer Overflow and Return-Oriented Programming
Runtime Attacks: Buffer Overflow and Prof. Dr.-Ing. Ahmad-Reza Sadeghi M.Sc. Lucas Davi Course Secure, Trusted and Trustworthy Computing, Part 1 System Security Lab http://trust.cased.de Technische Universität
Software Security: Buffer Overflow Attacks
CSE 484 / CSE M 584: Computer Security and Privacy Software Security: Buffer Overflow Attacks (continued) Autumn 2018 Tadayoshi (Yoshi) Kohno yoshi@cs.washington.edu Thanks to Dan Boneh, Dieter Gollmann,
Automated Signature Generation: Overview and the NoAH Approach. Bernhard Tellenbach
Automated Signature Generation: Overview and the NoAH Approach Structure Motivation: The speed of insecurity Overview Building Blocks and Techniques The NoAH approach 2 The speed of insecurity Source:
Isomeron: Code Randomization Resilient to (Just-In-Time) Return-Oriented Programming
Isomeron: Code Randomization Resilient to (Just-In-Time) Return-Oriented Programming Lucas Davi, Christopher Liebchen, Ahmad-Reza Sadeghi CASED/Technische Universität Darmstadt, Germany Email: {lucas.davi,christopher.liebchen,
Autodesk AutoCAD DWG-AC1021 Heap Corruption
security research Autodesk AutoCAD DWG-AC1021 Heap Corruption Mar 2013 AutoCAD is a software for computer-aided design (CAD) and technical drawing in 2D/3D, being one of the worlds leading CAD design tools.
Lecture Embedded System Security A. R. Darmstadt, Runtime Attacks
2 ARM stands for Advanced RISC Machine Application area: Embedded systems Mobile phones, smartphones (Apple iphone, Google Android), music players, tablets, and some netbooks Advantage: Low power consumption
Runtime Code Reuse Attacks: A Dynamic Framework Bypassing Fine-Grained Address Space Layout Randomization
Runtime Code Reuse Attacks: A Dynamic Framework Bypassing Fine-Grained Address Space Layout Randomization Yi Zhuang 1, Tao Zheng 12, Zhitian Lin 1 Software Institute 1. National Key Laboratory for Novel
Atomizer: Fast, Scalable and Lightweight Heap Analyzer for Virtual Machines in a Cloud Environment
Atomizer: Fast, Scalable and Lightweight Heap Analyzer for Virtual Machines in a Cloud Environment Salman Javaid Aleksandar Zoranic Irfan Ahmed Golden G. Richard III University of New Orleans Greater New
Buffer Overflows Defending against arbitrary code insertion and execution
www.harmonysecurity.com info@harmonysecurity.com Buffer Overflows Defending against arbitrary code insertion and execution By Stephen Fewer Contents 1 Introduction 2 1.1 Where does the problem lie? 2 1.1.1
CS 161 Computer Security
Paxson Spring 2011 CS 161 Computer Security Discussion 1 January 26, 2011 Question 1 Buffer Overflow Mitigations Buffer overflow mitigations generally fall into two categories: (i) eliminating the cause
Secure Systems Engineering
Secure Systems Engineering Chester Rebeiro Indian Institute of Technology Madras Flaws that would allow an attacker access the OS flaw Bugs in the OS The Human factor Chester Rebeiro, IITM 2 Program Bugs
Outline. Heap meta-data. Non-control data overwrite
Outline CSci 5271 Introduction to Computer Security Day 5: Low-level defenses and counterattacks Stephen McCamant University of Minnesota, Computer Science & Engineering Non-control data overwrite Heap
Hacking Blind. Andrea Bittau, Adam Belay, Ali Mashtizadeh, David Mazières, Dan Boneh. Stanford University
Hacking Blind Andrea Bittau, Adam Belay, Ali Mashtizadeh, David Mazières, Dan Boneh Stanford University Hacking 101 Exploit GET /0xDEAD HTTP/1.0 shell $ cat /etc/passwd root:x:0:0:::/bin/sh sorbo:x:6:9:pac:/bin/sh
String Oriented Programming Exploring Format String Attacks. Mathias Payer
String Oriented Programming Exploring Format String Attacks Mathias Payer Motivation Additional protection mechanisms prevent many existing attack vectors Format string exploits are often overlooked Drawback:
Windows Memory Forensics and Direct Kernel Object Manipulation. Jesse Kornblum
Windows Memory Forensics and Direct Kernel Object Manipulation Jesse Kornblum Outline Introduction The Kernel Direct Kernel Object Manipulation Standard DKOM Devious DKOM Better Magic Relations Between
Advanced Security for Systems Engineering VO 05: Advanced Attacks on Applications 2
Advanced Security for Systems Engineering VO 05: Advanced Attacks on Applications 2 Clemens Hlauschek, Christian Schanes INSO Industrial Software Institute of Information Systems Engineering Faculty of
An initial evaluation of ROP-based JIT-compilation
An initial evaluation of ROP-based JIT-compilation Pablo Bravo 1, Francisco Ortin 2 1 Malwarebytes Corp., Anti-Exploit Technologies, EEUU 2 University of Oviedo, Computer Science Department, Spain Abstract
Introduction Mapping the ELF Pinpointing Fragmentation Evaluation Conclusion. Bin-Carver. Automatic Recovery of Binary Executable Files
Bin-Carver Automatic Recovery of Binary Executable Files Scott Hand, Zhiqiang Lin, Guofei Gu*, Bhavani Thuraisingham Department of Computer Science, The University of Texas at Dallas *Deparment of Computer
Mitigating Code-Reuse Attacks with. Tyler Bletsch, Xuxian Jiang, Vince Freeh Dec. 9, 2011
Mitigating Code-Reuse Attacks with Control-Flow Locking Tyler Bletsch, Xuxian Jiang, Vince Freeh Dec. 9, 2011 Introduction Computer systems run complicated software, which is vulnerable We keep finding
OS Security IV: Virtualization and Trusted Computing
1 OS Security IV: Virtualization and Trusted Computing Chengyu Song Slides modified from Dawn Song 2 Administrivia Lab2 More questions? 3 Virtual machine monitor +-----------+----------------+-------------+
Shuffler: Fast and Deployable Continuous Code Re-Randomization
Shuffler: Fast and Deployable Continuous Code Re-Randomization David Williams-King, Graham Gobieski, Kent Williams-King, James P. Blake, Xinhao Yuan, Patrick Colp, Michelle Zheng, Vasileios P. Kemerlis,
Is stack overflow still a problem?
Morris Worm (1998) Code Red (2001) Secure Programming Lecture 4: Memory Corruption II (Stack Overflows) David Aspinall, Informatics @ Edinburgh 31st January 2017 Memory corruption Buffer overflow remains
Advanced Systems Security: Program Diversity
Systems and Internet Infrastructure Security Network and Security Research Center Department of Computer Science and Engineering Pennsylvania State University, University Park PA Advanced Systems Security:
Intro to x86 Binaries. From ASM to exploit
Intro to x86 Binaries From ASM to exploit Intro to x86 Binaries I lied lets do a quick ctf team thing Organization Ideas? Do we need to a real structure right now? Mailing list is OTW How do we get more
Basic Buffer Overflows
Operating Systems Security Basic Buffer Overflows (Stack Smashing) Computer Security & OS lab. Cho, Seong-je ( 조성제 ) Fall, 2018 sjcho at dankook.ac.kr Chapter 10 Buffer Overflow 2 Contents Virtual Memory
Identifying and Analyzing Pointer Misuses for Sophisticated Memory-corruption Exploit Diagnosis
Identifying and Analyzing Pointer Misuses for Sophisticated Memory-corruption Exploit Diagnosis Mingwei Zhang ( ) Aravind Prakash ( ) Xiaolei Li ( ) Zhenkai Liang ( ) Heng Yin ( ) ( ) School of Computing,
Bit Flips in Memory Rowhammer Attacks and Defenses
Bit Flips in Memory Rowhammer Attacks and Defenses Memory Corruption Attacks Software code injection return-oriented programming Data Code Hardware Memory Corruption Attacks Software code injection return-oriented
CSE Spring Assignment 3: Return-oriented Programming
CSE 543 - Spring 2015 - Assignment 3: Return-oriented Programming 1 Dates Out: March 26, 2015 Due: April 22, 2015 2 Introduction In this assignment, you will produce return-oriented programming (ROP) attacks.
Digital Investigation
Digital Investigation 18 (2016) S23eS32 Contents lists available at ScienceDirect Digital Investigation journal homepage: www.elsevier.com/locate/diin DFRWS USA 2016 d Proceedings of the 16th Annual USA
Module: Advanced Program Vulnerabilities and Defenses. Professor Trent Jaeger. CSE543 - Introduction to Computer and Network Security
CSE543 - Introduction to Computer and Network Security Module: Advanced Program Vulnerabilities and Defenses Professor Trent Jaeger 29 Anatomy of Control-Flow Exploits Two steps in control-flow exploitation