Computer Systems Security (Winter 2016)

2016-03-08T19:11:52Z

Adamniazi: /* Lectures and Exams */

==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|Lecture 15]]

</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 14

2016-03-06T19:21:12Z

Adamniazi: Created page with " == '''Topics and Readings''' == * Aleph One (aka Elias Levy), Smashing The Stack For Fun And Profit (Phrack 49, 1996) *Crispin Cowan et al., StackGuard: Automatic Adaptive De..."

== '''Topics and Readings''' ==
* Aleph One (aka Elias Levy), Smashing The Stack For Fun And Profit (Phrack 49, 1996)
*Crispin Cowan et al., StackGuard: Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks (USENIX Security, 1998)
*Wikipedia, Buffer Overflow Protection

== '''Notes''' ==

'''How to cause a buffer overflow?'''
* buffer overflows are usually done by taking advantage of protocols that come standard across systems
* memory mapping is one concept that is standardized across many systems, therefore, it can be guessed and predicted
* the similarities/standardization is based on machine instructions
* this can be changed using randomized instruction sets but it is not done on modern systems
* another regularity/standardization is memory layout but can be protected against using randomize memory layout (ASLR)
* another regularity is runnable code (executable memory), but can be protected by changing parts of memory to non-executable memory
* but changing parts of memory to non-exec code breaks the use of generating code on the fly
* StackGuard is a technique used to protect against buffer overflows
* the regularities/standardizations are the most modified part of memory to protect against overflows
* the cost of these things (armour the stack) causes process to be slow as more computations are required for security

'''Stackguard'''
* works by inserting a canary word; a special value on every function exit, that is checked at every function exit
* The compiler does not know it
* It must be generated at runtime
* Placed between Ret and local variables
* Idea is that if overflow occurs, the canary word will be overwritten and when the canary word is checked, it won't match and the process will blow up

ff 
|-------------------| 
|---Main + offs---| SP (main) 
|---------------| canary word can be put here 
|---------SP-------| all the registers*, SP -> FP 
|-------------------| 
|----Locals-----| 
|---Ret Addr----| 
|-----locals-------| address 20000 
|-------------------| 
|--code (text)--| 
|--code (text)--| 
|--code (text)--| 
|--code (text)--| 
0 

* Hardware changing really fast is misleading in CS, but software lags behind
* ex is speech recognition and learning. The algorithms are old, but the HW thats finally caught up so these slow algos can be run faster
* there are many other defences against buffer overflow, but they are not really deployed (see wikipedia link)
* in hardware, there is an idea called control flow integrity (CFI) to detect an attack (waste of time according to anil), good way of protecting buffer overflows but maybe not protect against backdoors

'''Why do we still care about buffer overflows?'''
* legacy code still exists in the world, that is why we will care about buffer overflows.
* not all legacy code has or can be updated
* fixing legacy code can cause important parts of code to break
* buffer overflows usually occur because the protections are not enabled properly
* C is considered unsafe language, and because so much of code in the world is written in C/C++, these exploits can be used

'''Other Defence: watching program behaviour'''
* watching how program behaves, looking for security violation
* done by profiling code the program executes
* can lead to slowing the processes, this is fixed by not monitoring everything, just where things can go wrong.
* what to monitor?
** sys calls
** anomaly detection can be used to protect against backdoors
* problem is, either layout everything that is permissible (white list) or what is not allowed (blacklist)
** White list do not account for how system might used
** Black lists do not specify everything that can be disallowed
* even with stupid models, we can do a lot
* used to check privileged entities is different ways
* defences beat by acting normally but mixing in things you want to do (''mimicry attack'')
* a buffer overflows fit into this by having the attack run code that acts normally, not detected by anomaly detection
** very hard to do when included with canary and randomizing

Soma-notes - User contributions [en]

Computer Systems Security (Winter 2016)

SystemsSec 2016W Lecture 14