Courses/Computer Science/CPSC 601.29.ISSA.F2011

This is the course wiki for CPSC 601.29 (Information Systems Security Analysis) for Fall 2011.

Course Logistics
When: WedFri 10AM to 11:15AM

Where: Wed SS 115, Fri ICT 616

Exam: No final exam

Communication: Use the class mailing list

Course Description
This course focuses on the principles of analyzing, penetrating, and defending computer systems. This subject complements a course of study that examines the theory and practice of securing computer networks. It is appropriate for graduate students or advanced undergraduates who want to learn fundamental concepts in security architecture and tools for computer system attack and defense. The course begins with a brief review of assembly programming and operating systems internals. For concreteness, concepts are demonstrated relative to the x86/Linux platform (and Windows, Solaris, or OS X as appropriate).

The instructor will cover topics including shellcode disassembly, memory protection, debugging, sandboxing (isolation & virtualization), reverse engineering, and intrusion recovery. We stress to students that this course is not solely a How-To training guide for a particular tool chest. This course relies on underlying principles for thinking about how systems can be made to fail, and its central aim is to help students understand the following abstract concepts:


 * cross-layer interactions -- root of trust; hardware supporting software security
 * composition and trust -- how these concepts affect system assurance
 * execution analysis -- how to analyze programs by reversing or removing abstraction, encapsulation, and other system organization principles
 * flaws as programming models -- understanding vulnerabilities and exploits as de facto primitives of an unintended programming environment
 * countermeasure efficacy -- understanding the context and relative merits of protection measures

The course will start with an overview of the ethical considerations involved in adopting a security analysis mindset. Additional ethical considerations will be introduced as necessary. Students will be required to adhere to the Agreement and Ethical Statement documents.

Course Syllabus
This course provides an overview of system instrumentation techniques related to the analysis of the security properties of running code. The course will cover concepts in such analysis as well as some practical tools and related literature from the application of these tools and concepts in academic research.

The course will cover a selection of the following topics as time allows:


 * The Security Mindset: Principles of the ``Hacker Curriculum''
 * IA-32 Architecture Overview
 * IA-32 Hardware Support for Security
 * x86 Assembly: Assembly programming, ELF toolchain
 * Common Vulnerability Classes
 * Operating Systems Security
 * Code Injection Countermeasures: Control Flow Integrity, Automated Diversity, Other Techniques
 * Shellcode Disassembly: Basic Tools and Samples, Advanced Techniques, Polymorphic Shellcode, English Shellcode
 * Program Supervision: Basic Mechanisms, Frameworks
 * Isolation: Isolation Primitives, Isolation Systems, Virtualization and Security
 * Reverse Engineering Protocols and File Formats, Reverse Engineering Protected Code
 * Intrusion Analysis: Classic Examples and the Invention of Honeypots, Intrusion Recovery
 * Language-theoretic security

= Course Schedule =

This lists the dates and topics for each day along with the reading assignments.

14 Sept 2011: Introduction (no class, read on own)
Prof. Locasto is away at a conference. Class will be rescheduled or appended to another session. Our first meeting is Friday, 16 Sept. at 10:00AM.


 * Course mailing list is at: http://mailman.ucalgary.ca/mailman/listinfo/cpsc601-29-l
 * Please read both the Agreement and the Statement. Sign Agreement and submit to Prof. Locasto on Friday the 16th.
 * You will probably want access to a Linux environment for this class. Backtrack Linux is a good choice, but you can also use Fedora, Ubuntu, or a BSD if you'd like. It may be easiest to boot from a LiveCD image rather than install a VM or configure your machine to dual-boot, but I leave that choice to you.
 * You should have received an email asking you to read the following items:
 * Reflections on Trusting Trust http://cm.bell-labs.com/who/ken/trust.html
 * The Security Mindset http://www.schneier.com/blog/archives/2008/03/the_security_mi_1.html
 * E-Prime for Security, Steve Greenwald, NSPW 2006 (get from the ACM DL or )
 * Some Thoughts on Security After Ten Years of qmail 1.0, DJB, CSAW 2007
 * Why Do Street Smart People Do Stupid Things Online?, Bratus et al. IEEE S&P Magazine May/June 2008
 * Security By Checklist, Steve Bellovin
 * http://portal.acm.org/citation.cfm?id=360303.360333
 * http://www.cs.virginia.edu/~cs216/Fall2005/notes/x86-doc.pdf

16 Sept 2011 : Introduction and Security Definition
Topics
 * Offer an operational/constructive definition of security and trustworthiness
 * Discuss the semantics of the word "hacker"

Readings
 * http://www.hackercurriculum.org/ homepage

Sept 21 An Introduction to x86
Topics
 * The "Big" Picture: Instrumentation levels
 * x86 fundamentals

Reading Assignment
 * The Intel IA32 Developer Manuals, Volume 1: http://www.intel.com/products/processor/manuals/
 * Section 2.1 (skim this)
 * Section 2.2 (paying particular attention to the description of the pipelined microarchitecture)
 * Chapter 3 (paying particular attention to 3.1, 3.2, 3.3, 3.4, 3.7, 3.7.4, 3.7.4.1)
 * http://www.cs.virginia.edu/~cs216/Fall2005/notes/x86-doc.pdf

Sept 23 Layers of Abstraction
Today we discussed the general concept of breaking through layers of abstraction. Our muse was the general question "How do I know what my process is doing?"

We covered a concrete example by writing a "hello, world" C program and examining the results of a compile to assembly, a compile to binary (ELF), and executing the program under strace. We also put into practice some of our knowledge about x86 assembly code.

Sept 28 "Instrumentation" Picture
Today we discussed the big picture in terms of developing the skill necessary to instrument a system at many different layers of abstraction. We started off class discussing the "big picture": the major difference (and relationship) between static analysis of the properties of binary images and dynamic analysis of running programs (i.e., processes). The production and processing of each artifact involves a number of other systems, including IDEs, the lexer/parser/compiler, assembler, linker, and the OS loader. Each of these introduces a location for instrumenting the system.

We tried to define the term "system".

We particularly discussed the issue of the semantic gap and how the concept of Deep Introspection might help address this gap by placing efficient data extraction and aggregation primitives at different layers of the system stack.

We hinted at various tools and techniques for doing so, in both the static and dynamic views of the system.

Sept 30 System Call Interface via Custom Assembly
Today we discuss the system call interface and how to invoke system calls via assembly code. We introduce the use of nasm and some other disassembly tools (udcli, objdump -d, and disasm).

We also discussed academic system security conferences.

Finally, we discussed class project requirements. Your midterm exam will be an oral presentation of your progress on the project. Your literature review will be either related to the project or (if you choose to do the bug-finding exercise) a survey of 5..10 papers on a specific systems security topic.

Links
 * http://udis86.sourceforge.net/ (We will use this in our shellcode exercises)
 * http://www.nasm.us/ (NASM)

Reading
 * http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html
 * Intel Software Developers Manual, Volume 3A: System Programming Guide, Part 1
 * Sections 2.1, 2.2, 2.3, 2.4, 2.5 and 2.7

Oct 5 Shellcode Sample
In this course, we will gain familiarity with x86 code, how the x86 chip executes such code, how assembly code can be crafted into "shellcode", and how that shellcode interacts with the OS. We will ask:


 * What is "shellcode"? Is it inherently "evil" or malicious?
 * How does shellcode interact with the OS?
 * What is the system calling convention?
 * How does shellcode get executed?

http://www.shell-storm.org/shellcode/files/shellcode-606.php

Oct 7 Programming in Assembly
In this class, we will have a hands-on exploration of how to write very small assembly programs. This material reinforces what we learned about shellcode and how to use the system call interface directly, without involving loads of compiler-inserted code and libraries.

This lesson is based on the very excellent cross-layer article about making very small ELF files:

http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html

This article, besides being a great tutorial on x86 and the Linux system call interface, is a fantastic exploration of the ELF file format.


 * Resources
 * ELF Specification: http://www.muppetlabs.com/~breadbox/software/ELF.txt
 * A library for disassembly: http://bastard.sourceforge.net/libdisasm.html
 * See also the bfd library.
 * http://www.gnu.org/software/gawk/
 * UDIS86: http://udis86.sourceforge.net/ (We will use this in our shellcode exercises)
 * http://www.nasm.us/ (NASM)
 * http://www.nasm.us/xdoc/2.09.04/html/nasmdoc0.html (NASM documentation)
 * Reminders:
 * Remember that 10 October is Canadian Thanksgiving.

Oct 12 Hardware Support for Trapping, Debugging, and Protection
In this class, we will consider some of the hardware support available for protection under x86. These mechanisms are the primitives that higher-level security and protection mechanisms depend on. Take careful note of their cost, granularity, and ability to express higher-level semantics (or lack thereof). This class session will also explore how trapping occurs on x86.


 * Concepts
 * Address translation
 * rings, segments, descriptors
 * Notes/References
 * http://wiki.osdev.org/Interrupt_Descriptor_Table
 * http://www.logix.cz/michal/doc/i386/chp09-00.htm
 * http://ece.wpi.edu/~wrm/Courses/EE3803/Labs/roehrl.html
 * http://wiki.osdev.org/GDT_Tutorial
 * VDSO definition: http://kernelnewbies.org/KernelGlossary#V
 * Linux-gate vdso insight: http://www.trilithium.com/johan/2005/08/linux-gate/
 * SYSENTER/SYSEXIT trivia: http://lkml.org/lkml/2002/12/18/218
 * Readings
 * Intel Software Developers Manual, Volume 3A: System Programming Guide, Part 1
 * Chapter 3
 * Chapter 5
 * Chapter 6, Interrupt and Exception Handling
 * Chapter 16, Sections 16.1, 16.2, and 16.3
 * Section 6.1 (Interrupt and Exception Overview)
 * Section 6.2 (Exception and Interrupt Vectors)
 * Section 6.10 (Interrupt Descriptor Table (IDT))
 * Section 6.11 IDT Descriptors
 * Figure 2-1 (specifically, the IDTR+IDT use)
 * Section 2.7 (System Instruction Summary)
 * Table 2-2
 * "Handling the IDT for Fun and Profit" http://www.phrack.com/issues.html?issue=59&id=4&mode=txt
 * "Mistifying the debugger" http://www.phrack.com/issues.html?issue=65&id=8&mode=txt

Oct 14 Polymorphic Shellcode
One recent (depending on how you count years) shift in attack and defense is the shift from trying to detect malicious code to detecting malicious computation; the former is hard, and the latter is impossible. Score one for the ba^h^Hcreative guys.

In this class we will cover a polymorphic shellcode example as well as English Shellcode. You should read the following articles before class:


 * http://www.cs.jhu.edu/~sam/ccs243-mason.pdf
 * From the hacker community:
 * "Writing ia32 alphanumeric shellcodes" http://phrack.org/issues.html?issue=57&id=15&mode=txt
 * http://www.blackhat.com/html/bh-usa-05/bh-usa-05-speakers.html (grep Shakespearean Shellcode)
 * http://media.blackhat.com/bh-usa-05/audio/2005_BlackHat_Vegas-V31-D_Barrall-Shakespearean_Shellcode.mp3
 * http://mirror.fpux.com/HackerCons/Blackhat%202005/CD/BH_US_05_BARRALL.PDF

Oct 19 Control Flow: Calling Conventions
This session will discuss x86 calling conventions, and how mixing control data and normal data in the same contiguous memory location entails risk.

This is preparation for understanding basic stack-based buffer overflows, but the larger lesson is that anywhere control information and pointers are mixed with writeable data, you have an opportunity for employing a "write primitive" as an attacker.

More importantly, this demonstrates how x86 systems fail to take advantage of segmentation support to differentiate between different types of memory. Systems need support for fine-grained separation of memory segments that can be efficiently enforced.

Readings
 * http://www.unixwiz.net/techtips/win32-callconv-asm.html

Oct 21 Program Supervision Basics (ptrace)
We will particularly look at how ptrace(2) is implemented and can be used by one process to trace another. We will pay particular attention to how ptrace support is expressed in the kernel.


 * Notes
 * We looked at the manual page for ptrace to understand the variety of services/request types it offers and understand some of the constraints governing its behavior
 * We examined a number of places in the kernel source code dealing with the implementation of ptrace
 * we first started out by understanding how the system call handling mechanism is actually coded in the kernel
 * we also looked up the task_struct definition in the kernel's code and reviewed the data members of this structure relevant to ptrace
 * we looked up ptrace's system call number and the definition of its prototype
 * we saw how the kernel defines macros for handling different system calls with different numbers of arguments
 * we understood that the implementation of ptrace has two logical parts: the general abstract part and the architecturally-dependent part, as reflected by the ptrace implementation and header files in different sections of the kernel source tree
 * we looked closely at the implementation of the "highest" layer of ptrace's implementation: the actual entry into the sys_ptrace function
 * After diving into shallow waters in the kernel, we started to look at this topic from the user-level side
 * Links
 * These links point to various places in the Linux kernel source code dealing with ptrace.
 * The ptrace API: http://lxr.linux.no/#linux+v2.6.37/include/linux/ptrace.h (defines function prototypes for internal kernel service routines related to ptrace and "types" for ptrace requests)
 * The platform-specific ptrace API: http://lxr.linux.no/#linux+v2.6.37/arch/x86/include/asm/ptrace.h
 * The architecture-specific ABI: http://lxr.linux.no/#linux+v2.6.37/arch/x86/include/asm/ptrace-abi.h
 * Definition of sys_ptrace system call function signature: http://lxr.linux.no/#linux+v2.6.37/include/linux/syscalls.h#L704
 * enumeration of sys_ptrace in the system call list (number 26): http://lxr.linux.no/#linux+v2.6.37/arch/x86/kernel/syscall_table_32.S#L28
 * Definition of Linux "task_struct", the Process Control Block. Note particularly the location of ptrace-related flags and signal-related flags like 'ptrace', 'parent', 'real_parent', etc. http://lxr.linux.no/#linux+v2.6.37/include/linux/sched.h#L1182
 * The "highest" layer of ptrace's implementation dealing with finding the process to trace and attaching: http://lxr.linux.no/#linux+v2.6.37/kernel/ptrace.c#L697 (note the use of the SYSCALL_DEFINE4 macro)
 * See definition of the SYSCALL_DEFINE macros: http://lxr.linux.no/#linux+v2.6.37/include/linux/syscalls.h#L188
 * The part of ptrace's implementation dealing with architecturally-specific requests: http://lxr.linux.no/#linux+v2.6.37/arch/x86/kernel/ptrace.c#L804
 * Exercises
 * Can program A ptrace program B which ptraces program A?
 * Can program A ptrace program B which is ptracing program C?
 * Try to write a ptrace-based program that outputs all the return values (i.e., the value of eax) after a return from each function (i.e., after a RET instruction is executed).
 * Frameworks
 * GDB: download GDB docs
 * Pin: http://www.pintool.org/
 * Valgrind: http://www.valgrind.org/
 * DynamoRio: http://dynamorio.org/
 * Ollydbg http://www.ollydbg.de/
 * Immunity Debugger http://www.immunityinc.com/products-immdbg.shtml
 * IDAPro http://www.hex-rays.com/idapro/
 * DTrace: http://www.oracle.com/technetwork/systems/dtrace/dtrace/index.html
 * SystemTap / Kprobes: http://sourceware.org/systemtap/kprobes/
 * Linux LKM HOWTO: http://tldp.org/HOWTO/Module-HOWTO/
 * Readings
 * x86 runtime process manipulation http://www.hick.org/code/skape/papers/needle.txt
 * Chi-Keung Luk, Robert Cohn, Robert Muth, Harish Patil, Artur Klauser, Geoff Lowney, Steven Wallace, Vijay Janapa Reddi, Kim Hazelwood. "Pin: Building Customized Program Analysis Tools with Dynamic Instrumentation," Programming Language Design and Implementation (PLDI), Chicago, IL, June 2005, pp. 190-200 http://doi.acm.org/10.1145/1065010.1065034

Oct 26 Discussion of ptrace implementation (cont.)
Today we continued our discussion of the implementation of ptrace.

Oct 28 Implementing a Small Debugger
In this class session we will show how to implement a small, special-purpose debugger.

A tarball of the code from class:

snyfer ptrace-based syscall tracer

Nov 2 Introduction to GDB
In this session, we looked at some basic usage and commands in GDB.

Nov 4: Debugging Session of a Basic Code Injection Attack
Reminder: class will be in ICT 643, not ICT 616.

Today we will use gdb to look at a simple strcpy-based injection. Your machine likely has a number of countermeasures to basic code injection in place already, and performing basic exploit research to understand the basic concepts (e.g., those presented in "Smashing the Stack for Fun and Profit" http://www.phrack.com/issues.html?issue=49&id=14&mode=txt ) requires you to turn them off to remove some complexity. The idea was to shut off all protections (execstack, turn off ASLR, turn off stack protector):
 * compiling programs with fno-stack-protector
 * turning off ASLR: as root, `echo 0 > /proc/sys/kernel/randomize_va_space'
 * marking executables as needing executable data areas: `execstack -s a.out'

write a small program that uses strcpy(3) unsafely:

http://pages.cpsc.ucalgary.ca/~locasto/teaching/2011/ISSA/code/scopy.c

int do_work(char* src){ char dst[10]; strcpy(dst, src); return 0; } int main(int argc, char* argv[]){ if(2==argc){ do_work(argv[1]); }else{ fprintf(stdout, "./scopy [arg]\n"); return -1; }  return 0; }
 * 1) include 
 * 2) include 

and then proceed to look at the stack using GDB.

http://pages.cpsc.ucalgary.ca/~locasto/teaching/2011/ISSA/code/session.txt

We also looked at how to examine the stack through a C pre-processor macro: Courses/Computer Science/CPSC 601.29.ISSA/20110307CodeSession

Classic Reading
 * http://www.phrack.com/issues.html?issue=49&id=14&mode=txt

Nov 9 Analysis of a Real Vulnerability
Using gdb, this session we will take a guided tour of the operation / execution of a real exploit on a real (but old) vulnerability. While the specific type of vulnerability is less likely to be a problem or easily exploitable for most current commodity systems, the principles involved are illustrative from both an attack and defense perspective.


 * Topics: the point of this lecture is to provide a hands-on assessment of an old stack-based buffer overflow vulnerability and the resulting exploit. This takes the previous class and cranks it up a notch: the vuln is in real, widely used software, and we get a richer address space than just a simple program copying a string from argv[1]
 * Notes: In this class, we looked at a wealth of information in both the source code (at the src-level definition of various functions) and at the assembly level. We first observed how rpng-x reacted when fed the proof-of-concept test case to exercise the vulnerability. We observed some output error messages and then a segfault. We started rpng-x in gdb and began to place breakpoints from the png_handle_tRNS function in the `pngrutil.c' file. We placed breakpoints at different related functions (e.g., png_crc_finish, png_read_data, png_default_read_data) and looked at them both at the source level as well as disassembly within gdb. We were able to modify the PoC exploit to include shellcode that spawned a shell once we got the return address correct (via stack examination of where the NOP sled landed on the stack). The key problem seemed to be that the length of a fixed-sized local buffer (256 declared bytes) -- and specifically the amount of space allocated on the stack (300 bytes) was smaller than the 512 bytes of data that fread(3) ultimately stuffs into that fixed-sized local buffer.
 * Links
 * http://scary.beasts.org/security/CESA-2004-001.txt
 * pngtest_bad.png
 * http://www.libpng.org/pub/png/libpng.html
 * http://www.kb.cert.org/vuls/id/388984

Nov 11: Reading Week (no class)
Reading week. Remembrance Day / Veteran's Day. University is closed Nov 10-13.

Nov 16: Heap-based Overwrites

 * Topics: observing how to overwrite heap-resident data structures, with some insight into overwriting heap management structures themselves
 * Code
 * Readings
 * "Once Upon a free": http://phrack.org/issues.html?issue=57&id=9&mode=txt
 * "Vudo - An object superstitiously believed to embody magical powers" http://phrack.org/issues.html?issue=57&id=8&mode=txt
 * "MALLOC DES-MALEFICARUM": http://phrack.org/issues.html?issue=66&id=10&mode=txt
 * See Patrick's collection of papers: http://wiki.ucalgary.ca/page/Protecting_Against_Heap-Based_Buffer_Overflows

Nov 18 Midterm Presentations
Today you will update the class on your progress with your project. You have 20 minutes. I'd like to see:


 * background (problem motivation)
 * the "gap" (specify what is wrong with the world that you'd like to address)
 * your approach
 * any related work
 * current state of implementation or investigation
 * any preliminary or current results
 * questions from the audience

Nov 23 Intrusion Analysis
Today we'll discuss some classic work in intrusion incident analysis and look at the debris left over from a real intrusion, discussed in my LISA 2009 paper:


 * http://pages.cpsc.ucalgary.ca/~locasto/papers/boulders.pdf
 * My slides: http://www.usenix.org/event/lisa09/tech/slides/locasto.pdf

Stories about post-mortem analysis of such incidents are rare. Here are a few links and pointers:


 * "Big-Box Breach: The Inside Story of Wal-Mart’s Hacker Attack"
 * Chronicle of a Server Break-In (HTML, see link to Paul’s actual postmortem)
 * Abe Singer. "Tempting Fate," ;login:, Volumn 30, #1, Usenix Association, November 2005. (grab a copy of ;login)
 * Eugene H. Spafford. The Internet Worm Program: An Analysis (PDF)
 * Cliff Stoll. "The Cuckoo’s Egg" (HTML)
 * Bill Cheswick. "An Evening With Berferd In Which a Cracker is Lured, Endured, and Studied" (PDF)


 * News
 * COMODO
 * http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html
 * http://blogs.comodo.com/it-security/data-security/the-changing-threat-model/
 * http://arstechnica.com/security/news/2011/03/how-the-comodo-certificate-fraud-calls-ca-trust-into-question.ars
 * RSA
 * http://blogs.rsa.com/rivner/anatomy-of-an-attack/
 * Epsilon
 * http://www.cbc.ca/news/business/story/2011/04/05/business-data-breach.html?ref=rss
 * http://www.thestreet.com/story/11070689/1/retailers-victims-of-e-mail-hackers.html?CM_VEN=AD|TWR|JC
 * Don't make me laugh: http://www.geeksquad.com/do-it-yourself/tech-tip/six-steps-to-keeping-your-data-safe.aspx
 * NASA
 * http://www.boingboing.net/2011/04/02/nasa-cybersecurity-r.html


 * Links Some sites collect data breach incidents, and Verizon's yearly data breach report is always interesting
 * http://newscenter.verizon.com/press-releases/verizon/2010/2010-data-breach-report-from.html
 * http://twitter.com/Privacy_Breach (BC-centric; doesn't seem terribly popular)
 * https://twitter.com/#!/datalossdb (see datalossdb.org)
 * http://www.privacyrights.org/

Nov 25: no class (US Thanksgiving)
Prof. Locasto will not be in Calgary.

We will double up the Nov 9 class. [done]

Nov 30: Countermeasures (basic and advanced)

 * Topics: libesafe, libverify, non-executable stack, W XOR X, Stack Canaries, Address space randomization,
 * Notes
 * libsafe/libverify paper: "Transparent Runtime Defense Against Stack Smashing Attacks" http://www.usenix.org/event/usenix2000/general/baratloo.html
 * http://www.usenix.org/publications/library/proceedings/sec98/full_papers/cowan/cowan.pdf "StackGuard: Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks"
 * OpenBSD slides: http://www.openbsd.org/papers/ven05-deraadt/ (you should read these)
 * "On the Effectiveness of Address Space Randomization": http://cseweb.ucsd.edu/~hovav/papers/sppgmb04.html
 * Propolice Website: http://www.trl.ibm.com/projects/security/ssp/ (see particularly: http://www.trl.ibm.com/projects/security/ssp/node4.html )
 * Links
 * "Return Oriented Rootkits" by Hund, Holz, and Freiling: http://www.usenix.org/events/sec09/tech/full_papers/hund.pdf

Advanced Countermeasures


 * Topics: tainted dataflow analysis, Artificial diversity, control flow integrity
 * Notes
 * Artificial diversity
 * n version programming
 * anomaly detection based on system call sequences: "A Sense of Self for Unix Processes" Somayaji et al.
 * asynchronous system calls
 * convergence of a profile & calibration
 * mimicry attacks
 * looking at arguments, not just syscall sequences (UCSB work)
 * ASLR (last time)
 * Instruction Set Randomization (Barrantes et al., Kc et al., CCS 2003)
 * mysql randomization, postgresql randomization
 * program reproduction by Somayaji et al.
 * Tainted Dataflow Analysis
 * TaintCheck (CMU)
 * mark sources of input (i.e., from system calls such as read(2) and recv(2)) with a tag, propagate tag with each assembly instruction
 * attack detection conditions
 * tainted data enters the contents of EIP
 * EIP points to an address containing tainted data
 * tainted data enters a system call argument, such as a parameter to execve(2)
 * Control Flow Integrity:
 * model control flow graph of an application statically; new injected control flow paths should not deviate from this static "complete" model; CFI paper
 * XFI: software guards
 * Advanced Topics: Signature Generation, Recovery
 * STEM
 * FLIPS, Shadow Honeypots, DIRA
 * Vigilante
 * VSEF: Vulnerability Specific Execution Filters
 * Application Communities
 * ShieldGen
 * Bouncer
 * Rx: execute through errors; see bugs as allergens, slightly change the environment and re-execute
 * ASSURE: model control flow, recover to a "safe" state
 * SEAD: Speculative Execution for Automated Defense: have an execution monitor that interprets "repair policy" (basically an after-production exeception handling mechanism) when a code injection attack is detected
 * http://technet.microsoft.com/en-us/security/dd285253.aspx (Mitigations by Matt Miller)
 * Code
 * We wrote a small piece of code to gather data on the value of ESP (position of stack in a randomized (i.e., ASLR environment) or non-randomized environment.

int main {  int* x = 0; int y = 0xDEADBEEF; x = &y; fprintf(stdout, "%u\n", ((unsigned int)x)); return ((int)x); }
 * 1) include 

This produces a distribution of values showing limited (max 3 in our experiment) reuse of the same stack state. Note that the return of x from main is truncated by the shell to a short int. We wrapped the binary in a bash shell script:

for do      ./a.out >> newstack.dat done
 * 1) !/bin/bash

and then passed newstack.dat through a chain of commands, first sorting -n the output, then passing to uniq -c, then awk to print $2 then $1, then sorting -n again. We directed that final output to a file newstack.sorted and plotted it with gnuplot (plot 'newstack.sorted' with impulses).

Turning ASLR off (via `echo '0' > /proc/sys/kernel/randomize_va_space produced a file with the same value (322122588).

Dec 2 : Language-Theoretic Security
Last day of class. Literature Reviews and Projects Due

Topic: we will watch a video talk by Len Sassaman and Meredith L. Patterson related to their 2010 ph-neutral talk (link below)


 * ISTS Seminar on YouTube: http://www.youtube.com/watch?v=AqZNebWoqnc&feature=player_embedded
 * "Exploiting Computational Slack in Protocol Grammars" http://ph-neutral.darklab.org/previous/0x7da/talks/grammars.html
 * USENIX ;login: articles in the December "Security" issue: http://www.usenix.org/publications/login/2011-12/index.html
 * Exploit Programming: From Buffer Overflows to "Weird Machines" and Theory of Computation. Sergey Bratus, Michael E. Locasto, Meredith L. Patterson, Len Sassaman, and Anna Shubina. USENIX ;login: vol. 36, no. 6, pp. 13--21 December 2011. Paper
 * The Halting Problems of Network Stack Insecurity by Len Sassaman, Meredith L. Patterson, Sergey Bratus, and Anna Shubina Paper

Dec 7: No Class (held extra on 16 Nov)
Prof. Locasto will be at ACSAC 2011 in Orlando and LISA 2011 in Boston.

We will double up Nov 16's class on heap overflows. [done]

Dec 9: No Class (held extra on 23 Nov)
Prof. Locasto will be away at a conference.

We will double up Nov 23's class on Intrusion Analysis. [done]

= Links =


 * Kernel Bug (Compiler Interference)
 * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1895
 * http://www.grsecurity.net/~spender/exploit.txt
 * https://groups.google.com/forum/#!msg/fa.linux.kernel/k8EIhFH9NSI/jahV97fsKEoJ