Soma-notes - User contributions [en]

Computer Systems Security (Winter 2016)

2016-03-24T21:29:12Z

Jsimpson: /* Security Reading Analysis Guidelines */ - fix really annoying typo

==Course Outline==

[[Computer Systems Security: Winter 2016 Course Outline|Here]] is the course outline.

==Hacking Opportunities==

The [[SystemsSec 2016W Hacking Opportunities|Hacking Opportunities]] page lists potential hacking opportunities that you can attempt for your hacking journal. If you attempt but do not successfully accomplish one of them, be sure to document what you tried. As you learn more, you may come back to them and try again.

==Resources==

===Readings===

* For the first part of the course we will be reading selections from Trent Jaeger's [http://www.morganclaypool.com/doi/abs/10.2200/S00126ED1V01Y200808SPT001 Operating Systems Security] textbook. You can download the PDF [http://www.morganclaypool.com.proxy.library.carleton.ca/doi/abs/10.2200/S00126ED1V01Y200808SPT001 through Carleton's library]. In the reading assignments this text will be referred to as "Jaeger".
* An excellent but dated text on browser security is Michal Zalewski's [https://code.google.com/p/browsersec/wiki/Main Browser Security Handbook].

===Other Courses===

* Dan Boneh ran an excellent course at Stanford in Spring 2015 on [https://crypto.stanford.edu/cs155/ Computer and Network Security]. This course has many interesting readings that we will not be covering. Also, the assignments are very good sources for hacking opportunities.
* The assignments from the Winter 2015 run of COMP 4108 [https://ccsl.carleton.ca/~dmccarney/COMP4108/ are available]. They are a reasonable start for several hacking opportunities.

==Lectures and Exams==

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Date
</th>
<th>
Topic
</th>
<th>
Readings
</th>
</tr>
<tr>
<td>
Jan. 7

</td>
<td>
[[SystemsSec 2016W Lecture 1|Introduction]]

</td>
<td>Jaeger, Chapter 1 (Introduction)</td></tr>
<tr>
<td>
Jan. 12

</td>
<td>
[[SystemsSec 2016W Lecture 2|Access Control, Security Hacking 101]]

</td>
<td>Jaeger, Chapter 2 (Access Control Fundamentals)</td></tr>
<tr>
<td>
Jan. 14

</td>
<td>
[[SystemsSec 2016W Lecture 3|Multics, UNIX, and Windows]]

</td>
<td>Jaeger, Chapter 3 (Multics) and Chapter 4 (UNIX & Windows) </td></tr>
<tr>
<td>
Jan. 19

</td>
<td>
[[SystemsSec 2016W Lecture 4|Secure OSs, theory and practice]]

</td>
<td>Jaeger, Chapter 6 (Security Kernels) and Chapter 7 (Securing Commercial Operating Systems)</td></tr>
<tr>
<td>
Jan. 21

</td>
<td>
[[SystemsSec 2016W Lecture 5|LSM, SELinux, & Capabilities]]

</td>
<td>Jaeger, Chapter 9 (LSM & SELinux) and Chapter 10 (Secure Capability Systems)</td></tr>
<tr>
<td>
Jan. 26

</td>
<td>
[[SystemsSec 2016W Lecture 6|Secure Virtual Machines, Systems Assurance]]

</td>
<td>Jaeger, Chapter 11 (Secure Virtual Machine Systems) and Chapter 12 (System Assurance)</td></tr>
<tr>
<td>
Jan. 28

</td>
<td>
[[SystemsSec 2016W Lecture 7|Lecture 7]]

</td>
<td></td></tr>
<tr>
<td>
Feb. 2

</td>
<td>
[[SystemsSec 2016W Lecture 8|Lecture 8]]

</td>
<td></td></tr>
<tr>
<td>
Feb. 4

</td>
<td>
[[SystemsSec 2016W Lecture 9|Defensive Security Technologies / Hacking Opportunities]]

</td>
<td></td></tr>
<tr>
<td>
Feb. 9

</td>
<td>
[[SystemsSec 2016W Lecture 10|Security Research, Hashes, and Secure Protocols]]

</td>
<td></td></tr>
<tr>
<td>
Feb. 11

</td>
<td>
[[SystemsSec 2016W Lecture 11|Modeling a potential attack/ Midterm FAQ]]

</td>
<td></td></tr>
<tr>
<td>
Feb. 23

</td>
<td>
[[SystemsSec 2016W Lecture 12|Midterm Review]]

</td>
<td></td></tr>
<tr>
<td>
Feb. 25

</td>
<td>
Midterm (in class)

</td>
<td></td></tr>
<tr>
<td>
Mar. 1

</td>
<td>
[[SystemsSec 2016W Lecture 13|Buffer Overflow/Memory Corruption Attacks]]

</td>
<td>Aleph One (aka Elias Levy), [http://www.phrack.com/issues/49/14.html#article Smashing The Stack For Fun And Profit] (Phrack 49, 1996)</td></tr>
<tr>
<td>
Mar. 3

</td>
<td>
[[SystemsSec 2016W Lecture 14|Buffer Overflow/Memory Corruption Defenses]]

</td>
<td>
Wikipedia, [https://en.wikipedia.org/wiki/Buffer_overflow_protection Buffer Overflow Protection] 
Crispin Cowan et al., [https://www.usenix.org/legacy/publications/library/proceedings/sec98/cowan.html StackGuard: Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks] (USENIX Security, 1998)
</td>
</tr>
<tr>
<td>
Mar. 8

</td>
<td>
[[SystemsSec 2016W Lecture 15|Bypassing ASLR and Buffer Overflow Exploits using return-into-libc]]

</td>
<td>Hovav Shacham et al., [http://dx.doi.org/10.1145/1030083.1030124 On the effectiveness of address-space randomization] (ACM CCS, 2004) [http://dl.acm.org.proxy.library.carleton.ca/ft_gateway.cfm?id=1030124&ftid=285463&dwn=1&CFID=588127386&CFTOKEN=74533951 (proxy)] 
Hovav Shachem [http://dx.doi.org/10.1145/1315245.1315313 The geometry of innocent flesh on the bone: return-into-libc without function calls (on the x86)] (ACM CCS 2007) [http://dl.acm.org.proxy.library.carleton.ca/ft_gateway.cfm?id=1315313&ftid=476749&dwn=1&CFID=588127386&CFTOKEN=74533951 (proxy)]</td></tr>
<tr>
<td>
Mar. 10

</td>
<td>
[[SystemsSec 2016W Lecture 16|Lecture 16]]

</td>
<td>Bellovin and Cheswick, [http://dx.doi.org/10.1109/35.312843 Network Firewalls] (IEEE Communications Magazine, 1994) [http://ieeexplore.ieee.org.proxy.library.carleton.ca/stamp/stamp.jsp?tp=&arnumber=312843 (proxy)]</td></tr>
<tr>
<td>
Mar. 15

</td>
<td>
[[SystemsSec 2016W Lecture 17|Lecture 17]]

</td>
<td>Dingledine, Mathewson, and Syverson, [https://www.usenix.org/legacy/events/sec04/tech/dingledine.html Tor: The Second-Generation Onion Router] (USENIX Security 2004) Albert Kwon et al., [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/kwon Circuit Fingerprinting Attacks: Passive Deanonymization of Tor Hidden Services] (USENIX Security 2015) (background)[https://www.torproject.org/about/overview.html.en Tor: Overview]</td></tr>
<tr>
<td>
Mar. 17

</td>
<td>
[[SystemsSec 2016W Lecture 18|Lecture 18]]

</td>
<td>Blase Ur et al., [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/ur Measuring Real-World Accuracies and Biases in Modeling Password Guessability] (USENIX Security 2015) 
Nikolaos Karapanos et al., [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/karapanos Sound-Proof: Usable Two-Factor Authentication Based on Ambient Sound] (USENIX Security 2015)</td></tr>
<tr>
<td>
Mar. 22

</td>
<td>
[[SystemsSec 2016W Lecture 19|Lecture 19]]

</td>
<td>Giancarlo Pellegrino et al., [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/pellegrino In the Compression Hornet’s Nest: A Security Study of Data Compression in Network Services] (USENIX Security 2015) Ramya Jayaram Masti et al., [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/masti Thermal Covert Channels on Multi-core Platforms] (USENIX Security 2015)</td></tr>
<tr>
<td>
Mar. 24

</td>
<td>
[[SystemsSec 2016W Lecture 20|Lecture 20]]

</td>
<td>Seyed K. Fayaz et al., [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/fayaz Bohatei: Flexible and Elastic DDoS Defense] (USENIX Security 2015) Marten Oltrogge and Yasemin Acar, [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/oltrogge To Pin or Not to Pin—Helping App Developers Bullet Proof Their TLS Connections] (USENIX Security 2015)</td></tr>
<tr>
<td>
Mar. 29

</td>
<td>
[[SystemsSec 2016W Lecture 21|Lecture 21]]

</td>
<td>David A. Ramos and Dawson Engler, [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/ramos Under-Constrained Symbolic Execution: Correctness Checking for Real Code] (USENIX Security 2015) Nav Jagpal et al., [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/jagpal Trends and Lessons from Three Years Fighting Malicious Extensions] (USENIX Security 2015)</td></tr>
<tr>
<td>
Mar. 31

</td>
<td>
[[SystemsSec 2016W Lecture 22|Lecture 22]]

</td>
<td>Xiaofeng Zheng et al., [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/zheng Cookies Lack Integrity: Real-World Implications] (USENIX Security 2015) Sebastian Lekies et al., [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/lekies The Unexpected Dangers of Dynamic JavaScript] (USENIX Security 2015)</td></tr>
<tr>
<td>
Apr. 5

</td>
<td>
[[SystemsSec 2016W Lecture 23|Lecture 23]]

</td>
<td>Michael Backes et al., [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/backes Boxify: Full-fledged App Sandboxing for Stock Android] (USENIX Security 2015) Primal Wijesekera et al., [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/wijesekera Android Permissions Remystified: A Field Study on Contextual Integrity] (USENIX Security 2015)</td></tr>
<tr>
<td>
April 7

</td>
<td>
[[SystemsSec 2016W Lecture 24|Lecture 24]]

</td>
<td></td></tr>
<tr>
<td>
April 19, 9 AM

</td>
<td>
Final Exam

</td>
<td></td></tr>
</table>

==Lecture Notes Guidelines==

Part of your participation mark is doing notes for at least one of the lectures. Here are the guidelines for those notes.

The class TA Borke (BorkeObadaObieh at cmail.carleton.ca) will be handling course notes. Please contact her to schedule your class to take notes.

Borke or Anil will set you up with an account on this wiki. You'll enter your initial draft notes here and then work with Borke to make sure they are of sufficient quality. This may require a few rounds of revisions; however, if you follow the guidelines below it shouldn't be too bad.

You should plan on organizing your notes as follows:
* Organize them in at least the following sections: Topics & Readings and Notes.
* The Topics & Readings section lists the main topics covered in the class, e.g. "buffer overflows". Please use an unordered bulleted list (using *'s in wiki markup). In this section also list readings relevant to the lecture that were mentioned in class.
* Put your notes in the Notes section.

Use (nested) lists if appropriate for the notes; however, please have some text that isn't bulleted. Please try to make the notes even if you did not attend lecture; however, you don't need to cover every small bit of information that was covered. In particular the notes do not need to include digressions into topics only tangentially related to the course. Complete sentences are welcome but not required.

==Security Reading Analysis Guidelines==

A security reading analysis is a detailed analysis of a security research paper. In it you analyze the key arguments of the paper and give your informed opinion.

Most security papers can be classified as attack or defense papers. You should analyze them differently.

For attack papers:
* What systems are vulnerable to the attack?
* What is the nature of the vulnerability?
* What is the the exploit? In particular, what is its technical core?
* How reproducible is the exploit?
* Are there likely to be many similar exploits, in the targeted system or other systems?
* How difficult will it be mitigate/fix the vulnerability in targeted systems?

For defense papers:
* What is the security problem the paper addresses? In what kind of threat model(s) does the problem exist?
* How significant is the problem? Specifically, to what degree do existing solutions not work sufficiently well?
* What is the defense? How does it work?
* To what degree will the defense potentially solve the targeted security problem? In particular, how difficult will it be for attackers to adapt to this defense?
* What are the challenges facing deployment of the defense? Are they likely to be overcome?

For both kinds of papers, you should give your reaction by addressing questions like the following:
* Did you like the paper?
* Was it easy to understand, or was it hard to read?
* Did you learn much from the paper?
* How surprised were you by the result?

Your analysis should not cover the above questions separately (this would tend to make for a very wordy analysis); instead, use these questions as a guide in writing a short essay (1-2 pages) on the paper in question.

Each analysis will be graded out of 10 as follows:
* U: 3 for demonstrating understanding of the content (preferably without summarizing)
* T: 3 for technical analysis (does it work)
* C: 3 for contextual analysis (does it matter)
* V: 1 for your viewpoint

Computer Systems Security (Winter 2016)

2016-03-10T05:01:30Z

Jsimpson: /* Lectures and Exams */ add lecture 15 title

==Course Outline==

[[Computer Systems Security: Winter 2016 Course Outline|Here]] is the course outline.

==Hacking Opportunities==

The [[SystemsSec 2016W Hacking Opportunities|Hacking Opportunities]] page lists potential hacking opportunities that you can attempt for your hacking journal. If you attempt but do not successfully accomplish one of them, be sure to document what you tried. As you learn more, you may come back to them and try again.

==Resources==

===Readings===

* For the first part of the course we will be reading selections from Trent Jaeger's [http://www.morganclaypool.com/doi/abs/10.2200/S00126ED1V01Y200808SPT001 Operating Systems Security] textbook. You can download the PDF [http://www.morganclaypool.com.proxy.library.carleton.ca/doi/abs/10.2200/S00126ED1V01Y200808SPT001 through Carleton's library]. In the reading assignments this text will be referred to as "Jaeger".
* An excellent but dated text on browser security is Michal Zalewski's [https://code.google.com/p/browsersec/wiki/Main Browser Security Handbook].

===Other Courses===

* Dan Boneh ran an excellent course at Stanford in Spring 2015 on [https://crypto.stanford.edu/cs155/ Computer and Network Security]. This course has many interesting readings that we will not be covering. Also, the assignments are very good sources for hacking opportunities.
* The assignments from the Winter 2015 run of COMP 4108 [https://ccsl.carleton.ca/~dmccarney/COMP4108/ are available]. They are a reasonable start for several hacking opportunities.

==Lectures and Exams==

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Date
</th>
<th>
Topic
</th>
<th>
Readings
</th>
</tr>
<tr>
<td>
Jan. 7

</td>
<td>
[[SystemsSec 2016W Lecture 1|Introduction]]

</td>
<td>Jaeger, Chapter 1 (Introduction)</td></tr>
<tr>
<td>
Jan. 12

</td>
<td>
[[SystemsSec 2016W Lecture 2|Access Control, Security Hacking 101]]

</td>
<td>Jaeger, Chapter 2 (Access Control Fundamentals)</td></tr>
<tr>
<td>
Jan. 14

</td>
<td>
[[SystemsSec 2016W Lecture 3|Multics, UNIX, and Windows]]

</td>
<td>Jaeger, Chapter 3 (Multics) and Chapter 4 (UNIX & Windows) </td></tr>
<tr>
<td>
Jan. 19

</td>
<td>
[[SystemsSec 2016W Lecture 4|Secure OSs, theory and practice]]

</td>
<td>Jaeger, Chapter 6 (Security Kernels) and Chapter 7 (Securing Commercial Operating Systems)</td></tr>
<tr>
<td>
Jan. 21

</td>
<td>
[[SystemsSec 2016W Lecture 5|LSM, SELinux, & Capabilities]]

</td>
<td>Jaeger, Chapter 9 (LSM & SELinux) and Chapter 10 (Secure Capability Systems)</td></tr>
<tr>
<td>
Jan. 26

</td>
<td>
[[SystemsSec 2016W Lecture 6|Secure Virtual Machines, Systems Assurance]]

</td>
<td>Jaeger, Chapter 11 (Secure Virtual Machine Systems) and Chapter 12 (System Assurance)</td></tr>
<tr>
<td>
Jan. 28

</td>
<td>
[[SystemsSec 2016W Lecture 7|Lecture 7]]

</td>
<td></td></tr>
<tr>
<td>
Feb. 2

</td>
<td>
[[SystemsSec 2016W Lecture 8|Lecture 8]]

</td>
<td></td></tr>
<tr>
<td>
Feb. 4

</td>
<td>
[[SystemsSec 2016W Lecture 9|Defensive Security Technologies / Hacking Opportunities]]

</td>
<td></td></tr>
<tr>
<td>
Feb. 9

</td>
<td>
[[SystemsSec 2016W Lecture 10|Security Research, Hashes, and Secure Protocols]]

</td>
<td></td></tr>
<tr>
<td>
Feb. 11

</td>
<td>
[[SystemsSec 2016W Lecture 11|Modeling a potential attack/ Midterm FAQ]]

</td>
<td></td></tr>
<tr>
<td>
Feb. 23

</td>
<td>
[[SystemsSec 2016W Lecture 12|Midterm Review]]

</td>
<td></td></tr>
<tr>
<td>
Feb. 25

</td>
<td>
Midterm (in class)

</td>
<td></td></tr>
<tr>
<td>
Mar. 1

</td>
<td>
[[SystemsSec 2016W Lecture 13|Buffer Overflow/Memory Corruption Attacks]]

</td>
<td>Aleph One (aka Elias Levy), [http://www.phrack.com/issues/49/14.html#article Smashing The Stack For Fun And Profit] (Phrack 49, 1996)</td></tr>
<tr>
<td>
Mar. 3

</td>
<td>
[[SystemsSec 2016W Lecture 14|Buffer Overflow/Memory Corruption Defenses]]

</td>
<td>
Wikipedia, [https://en.wikipedia.org/wiki/Buffer_overflow_protection Buffer Overflow Protection] 
Crispin Cowan et al., [https://www.usenix.org/legacy/publications/library/proceedings/sec98/cowan.html StackGuard: Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks] (USENIX Security, 1998)
</td>
</tr>
<tr>
<td>
Mar. 8

</td>
<td>
[[SystemsSec 2016W Lecture 15|Bypassing ASLR and Buffer Overflow Exploits using return-into-libc]]

</td>
<td>Hovav Shacham et al., [http://dx.doi.org/10.1145/1030083.1030124 On the effectiveness of address-space randomization] (ACM CCS, 2004) [http://dl.acm.org.proxy.library.carleton.ca/ft_gateway.cfm?id=1030124&ftid=285463&dwn=1&CFID=588127386&CFTOKEN=74533951 (proxy)] 
Hovav Shachem [http://dx.doi.org/10.1145/1315245.1315313 The geometry of innocent flesh on the bone: return-into-libc without function calls (on the x86)] (ACM CCS 2007) [http://dl.acm.org.proxy.library.carleton.ca/ft_gateway.cfm?id=1315313&ftid=476749&dwn=1&CFID=588127386&CFTOKEN=74533951 (proxy)]</td></tr>
<tr>
<td>
Mar. 10

</td>
<td>
[[SystemsSec 2016W Lecture 16|Lecture 16]]

</td>
<td>Bellovin and Cheswick, [http://dx.doi.org/10.1109/35.312843 Network Firewalls] (IEEE Communications Magazine, 1994) [http://ieeexplore.ieee.org.proxy.library.carleton.ca/stamp/stamp.jsp?tp=&arnumber=312843 (proxy)]</td></tr>
<tr>
<td>
Mar. 15

</td>
<td>
[[SystemsSec 2016W Lecture 17|Lecture 17]]

</td>
<td></td></tr>
<tr>
<td>
Mar. 17

</td>
<td>
[[SystemsSec 2016W Lecture 18|Lecture 18]]

</td>
<td></td></tr>
<tr>
<td>
Mar. 22

</td>
<td>
[[SystemsSec 2016W Lecture 19|Lecture 19]]

</td>
<td></td></tr>
<tr>
<td>
Mar. 24

</td>
<td>
[[SystemsSec 2016W Lecture 20|Lecture 20]]

</td>
<td></td></tr>
<tr>
<td>
Mar. 29

</td>
<td>
[[SystemsSec 2016W Lecture 21|Lecture 21]]

</td>
<td></td></tr>
<tr>
<td>
Mar. 31

</td>
<td>
[[SystemsSec 2016W Lecture 22|Lecture 22]]

</td>
<td></td></tr>
<tr>
<td>
Apr. 5

</td>
<td>
[[SystemsSec 2016W Lecture 23|Lecture 23]]

</td>
<td></td></tr>
<tr>
<td>
April 7

</td>
<td>
[[SystemsSec 2016W Lecture 24|Lecture 24]]

</td>
<td></td></tr>
<tr>
<td>
April 19, 9 AM

</td>
<td>
Final Exam

</td>
<td></td></tr>
</table>

==Assignments==
<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Due Date
</th>
<th>
Assignments
</th>
</tr>
<tr>
<td>
Jan. 30

</td>
<td>
[[SystemsSec 2016W: Assignment 1|Assignment 1]]

</td>
</tr>
<tr>
<td>
Feb. 22

</td>
<td>
[[SystemsSec 2016W: Assignment 2|Assignment 2]]

</td>
</tr>
<tr>
<td>
Mar. 19

</td>
<td>
[[SystemsSec 2016W: Assignment 3|Assignment 3]]

</td>
</tr>
<tr>
<td>
April 4

</td>
<td>
[[SystemsSec 2016W: Assignment 4|Assignment 4]]

</td>
</tr>
</table>

==Lecture Notes Guidelines==

Part of your participation mark is doing notes for at least one of the lectures. Here are the guidelines for those notes.

The class TA Borke (BorkeObadaObieh at cmail.carleton.ca) will be handling course notes. Please contact her to schedule your class to take notes.

Borke or Anil will set you up with an account on this wiki. You'll enter your initial draft notes here and then work with Borke to make sure they are of sufficient quality. This may require a few rounds of revisions; however, if you follow the guidelines below it shouldn't be too bad.

You should plan on organizing your notes as follows:
* Organize them in at least the following sections: Topics & Readings and Notes.
* The Topics & Readings section lists the main topics covered in the class, e.g. "buffer overflows". Please use an unordered bulleted list (using *'s in wiki markup). In this section also list readings relevant to the lecture that were mentioned in class.
* Put your notes in the Notes section.

Use (nested) lists if appropriate for the notes; however, please have some text that isn't bulleted. Please try to make the notes even if you did not attend lecture; however, you don't need to cover every small bit of information that was covered. In particular the notes do not need to include digressions into topics only tangentially related to the course. Complete sentences are welcome but not required.

==Security Reading Analysis Guidelines==

A security reading analysis is a detailed analysis of a security research paper. In it you analyze the key arguments of the paper and give your informed opinion.

Most security papers can be classified as attack or defense papers. You should analyze them differently.

For attack papers:
* What systems are vulnerable to the attack?
* What is the nature of the vulnerability?
* What is the the exploit? In particular, what is its technical core?
* How reproducible is the exploit?
* Are there likely to be many similar exploits, in the targeted system or other systems?
* How difficult will it be mitigate/fix the vulnerability in targeted systems?

For defense papers:
* What is the security problem the paper addresses? In what kind of threat model(s) does the problem exist?
* How significant is the problem? Specifically, to what degree do existing solutions not work sufficiently well?
* What is the defense? How does it work?
* To what degree will the defense potentially solve the targeted security problem? In particular, how difficult will it be for attackers to adapt to this defense?
* What are the challenges facing deployment of the defense? Are they likely to be overcome?

For both kinds of papers, you should give your reaction by addressing questions like the following:
* Did you like the paper?
* What it easy to understand, or was it hard to read?
* Did you learn much from the paper?
* How surprised were you by the result?

Your analysis should not cover the above questions separately (this would tend to make for a very wordy analysis); instead, use these questions as a guide in writing a short essay (1-2 pages) on the paper in question.

SystemsSec 2016W Lecture 15

2016-03-10T04:53:39Z

Jsimpson: initial formatting and editing of notes

The two assigned readings for this class were analysed in small groups to determine which sections should be discussed, then the class had an open discussion on each section.

== Paper: On the effectiveness of address-space randomization ==
* What is [https://en.wikipedia.org/wiki/PaX PaX]?
** patches put together to harden Linux
** Mainline kernel has adopted the address space layout randomization (ASLR) mechanism

* Pool of entropy is used to decide where to load sections of executable
* Executables are in the ELF format, consisting of different sections. Each section can be loaded into different areas of memory
* for Intel x86 you get 16 bits of entropy for ASLR
** Its not enough since it doesn't take long to try 32,000 tries
* 24 bits of ASLR entropy is 16 million
** still possible to brute force

* When any of the three delta (randomization) variables are leaked/stolen it's trivial for the attacker to know the addresses of everything

* In the paper the authors use a return-to-libc attack, bypassing the stack protection
** uses return addresses on the stack
** any process on Unix uses the libc library. ie. the functions are always loaded into every program
*** other os'es have a similar library
** each executable contains the system() system call
*** allows the program to start a shell

* What if the defender turns off execution on the stack
** This method is called Write or Execute pages (W or X)
** return-to-libc bypasses the memory protection from W or X

* The problem introduced in the paper is how can they find the libc library when ASLR and W or X is used
** This is a derandomization attack
** Try jumping to addresses at random
** If the address to jump to was invalid, a segfault occurs
** The authors assume that the service starts a new process for each request (Default Apache web server behaviour)
*** Its costly to spawn new processes to do work, but it's more secure since it's an entirely separate memory space
*** In cases where the service doesn't fork requests to a new process, it's common for the memory to be re-randomized after a segfault

* the attackers want to find the delta_mmap variable
** contains the randomization code
*** keys to the kingdom
*** allows you to know how ASLR randomizes the memory

* It's important to understand the assumptions that the paper makes when doing these attacks
* Assumptions can make the attack much easier

* 64 bit systems running 64 bit processes has a huge memory space that allows for much more randomization of memory addresses
** at least 40 bits of entropy
** Increases the number of tries

* Server's crashing all the time should be a big notice that there's an issue but program's aren't designed with that in thought
** ie. an attacker
** investigating in the Apache web server attack
*** block the IP address that's causing the process to crash
*** See the data of the incoming request to determine if it's malicious or not
** pausing the process stops the hacker but causes a DoS for the users of the service

== Paper: The Geometry of Innocent Flesh on the Bone: Return-into-libc without Function Calls(on the x86) ==

* shows a new way of organizing [https://en.wikipedia.org/wiki/Return-to-libc_attack return-into-libc exploits]
* static analysis can be used to find code sequences for the return-into-libc attack
* basic idea: put a return address on the stack - but not the return address of a function - an arbitrary instruction that's near the end of the function
** runs the last few instructions of the function, then it does a return
** that return address is then another jump into arbitrary instructions, repeating the above

* This allows you to assemble arbitrary functions
* static analysis allows you to use libraries other than libc
* with enough functions, you're able to build any sort of exploit
* each sequence of useful code from the end of functions are called "gadgets"

* How are sequences chained together?
** you push many return addresses and all the needed parameters
** need a lot of bytes to perform this type of attack

* Once you figure out where the library is randomly loaded, its trivial to jump to any function in the library

== What have we learned about buffer overflows? (attack and defence) ==

* What lessons have we learned?
** Don't use unsafe languages (ie. C, C++)
** attacks are very specific, but potentially robust
** Side: Pwn2Own - if you compromise the machine/device, you take it home or get a reward
*** Attackers chain together many, many techniques to pwn devices
*** This stuff is real, but it is not easy. Depends on lots of little tricks
* What's required to perform a memory corruption attack?
** access to the same system
** same programs, patches, versions
** All of these are required because memory corruption attacks are fragile and very platform specific
* How do you defeat these attacks in general?
** software distribution
*** all the code that we put out there are the same - we all run the same code/binaries
*** if attacker has the same binaries, they can study them and develop attacks
* Its silly that we can do crazy things to binaries (ie. crash them 30,000 times) without the binary doing anything