8/11/2019 Session.pdf

http://slidepdf.com/reader/full/sessionpdf 1/2

Session 1 Reading List

This is a list of useful documents that will enhance your understanding of the course material.

The reading list is session-by-session. “Primary” material means something you would be

expected to read if you are serious about the course, and may help you to do the weeklyexercise; “Additional” material you may want to read if you would like to deepen your

understanding on a specific area.

Primary material

!  Graff and van Wyk: Secure Coding: Principles and Practices, Chapter 1: No Straight

Thing, subsections “The Vulnerability Cycle”, “What is an attack?”, and “Why Good

People Write Bad Code”.

!  Have a look at the CWE (Common Weakness Enumeration) project. It classifies different

types of security failures - an example would be

http://cwe.mitre.org/data/definitions/118.html. Click on the “Research View”, and you see

a list of all the weaknesses catalogued by CWE.

!  Have a look at the National Vulnerability Database. Each publicly known vulnerability

gets a CVE (Common Vulnerabilities and Exposures) number that can be used as a

shorthand to refer to the issue (“Have you already fixed CVE-XXXX-YYYY?”). As an

example, see https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-1472. You will

see an explanation of the issue, affected systems, the CWE classification of the problem

(see previous bullet) and a CVSS (Common Vulnerability Scoring System) score, which

is intended to convey how serious the issue is. Almost all security reports and release

notes use CVE numbers nowadays.

Additional material!  The rest of Chapter 1 from Secure Coding  (see above).

!  van der Veen, dutt-Sharma, Cavallaro, Bos: Memory Errors: The Past, the Present, and

the Future, http://www.isg.rhul.ac.uk/sullivan/pubs/tr/technicalreport-ir-cs-73.pdf. This is

a concise article that collects the history of memory errors on a timeline, but doesn’t

explain them technically.

!  Programs with exploitable bugs can be viewed as weird machines that are programmed

with exploits; for example, a ROP attack could be seen as a language that specifies an

execution flow for a machine that is the vulnerable program. If you’re interested, see

http://www.cs.dartmouth.edu/~sergey/langsec/papers/Bratus.pdf  and Bratus, et al.:

Beyond Planted Bugs in “Trusting Trust”: The Input-Processing Frontier  in IEEE Security

& Privacy, January 2014.

!  Pietikäinen et al.: Security Testing of Web Browsers, http://www.cloudsw.org/under-

review/ec2266cf-8d22-4bfe-a70c-3fa1569c7007/security-testing-of-web-

browsers/at download/file. This article describes how the Oulu University group used

their Radamsa fuzzer to perform security testing against web browsers. This is a fairly

high level description of Radamsa, and given that you are going to use Radamsa for the

weekly exercise, this may be useful to read.

8/11/2019 Session.pdf

http://slidepdf.com/reader/full/sessionpdf 2/2

!  Ormandy et al.: Fuzzing at scale. http://googleonlinesecurity.blogspot.fi/2011/08/fuzzing-

at-scale.html and the presentation that is linked from this blog post,

http://taviso.decsystem.org/making_software_dumber.pdf. This 2011 blog post by

Google’s security team gives insight to real-life effective fuzzing technologies. They use

sample-based fuzzing but they choose set of valid samples carefully (“corpus

distillation”). We did not go into this during the session, but this has the effect of greatlyincreasing the effectiveness. You can (and perhaps should) do corpus distillation before

rolling out “industrial grade” fuzzing.

!  If you want to get more technical details on the mitigations and bypass techniques, here

are three summaries.

"  Aleph One (Elias Levy): Smashing the Stack for Fun and Profit . Phrack

Magazine, vol. 7, issue 49.

http://www.phrack.org/issues.html?issue=49&id=14&mode=txt. This article, from

1996, is the seminal work on the “old school” exploitation of buffer overflows. It is

not purely of historical interest - it is a very readable and concise explanation of

what is happening in a system which doesn’t have modern protection measures.

"  Theo de Raadt: Exploit Mitigation Techniques.

http://www.openbsd.org/papers/ven05-deraadt/index.html. This presentation from

2005 describes the anti-exploitation techniques as implemented in OpenBSD

(and currently in most other general-use OSes). Explains stack canaries, non-

executable data areas, and address space layout randomization, with a lots of

pictures of what they mean. Typeset in glorious Comic Sans.

"  Buchanan et al.: Return-Oriented Programming: Exploitation without Code

Injection. http://cseweb.ucsd.edu/~hovav/dist/blackhat08.pdf . This 2008

presentation describes the generalisation of return-to-libc attacks into ROP. It

gives a view of exploitation techniques in operating systems that implement the

mitigation systems above.