Software Security

Software Security, Autumn 2020

This course is taught by Erik Poll. It is part of the TRU/e Master specialisation in Cyber Security. More background on goals, prerequisites, etc. at the bottom of this web page.

Make sure you are registered in Osiris, which will then also register you in Brightspace. Beware that there is a 6EC version (ISOFSE) and a 5EC version (IMC051) of this course. The 5 EC version is for students doing the TRU/e Cyber Security specialisation.

For TU/e students: if you somehow cannot register for the course (yet), send me an email, so that I can make sure email announcements via Brightspace reach you. A pdf with links to the online lectures has been sent over the security mailing list, so make sure you get on that list (via this web form)!

Lectures & obligatory reading material

Lectures: Fridays 10:30-12:15

NB the description below will be updated as we go along, with slides and pointers to papers. The obligatory reading material and exam material for the course includes the slides, some academic research papers listed below, and the following textbook material:

Secure Software Lifecycle, CyBok chapter by Laurie Williams, Issue 1.0, 2019
Software Security, CyBok chapter by Frank Piessens, Issue 1.0, 2019
Lecture Notes on Language-based Security, 2019.

Recording of last year's lecture is in Brightspace.

day	slides	Mandatory reading & mini-assignments
Sept 4	Introduction & Security in the Software Development Life Cycle The last slides list some basic terminology & concepts I expect all of you should know; I skipped them in the lecture, but do look at them.	To read: Secure Software Lifecycle, CyBok chapter by Williams, 2019. To do: have a look at the latest US-CERT Bulletin and the CVE Twitter feed to get a feel for the scale of software security problems. To do: search the CVE list or NIST's Vulnerability Database for flaws in the browser you are using to view this webpage, and check out how CVSS score was determined. You can also search for known flaws in the other applications or operating systems that you commonly use, and maybe double-check that you are applying patches automatically.
Sept 11	Memory-corruption flaws	To read: Sections 3.1 & 3.2 of the lecture notes To read: SoK: Eternal War in Memory by Szekeres et al., IEEE Symposium on Security & Privacy, 2013 - You can skip Section VII. To do: have a look at some CVEs that involve buffer overflows, integer overflows, and format strings, to get an idea of the sheer numbers, the kind of software affected, etc. Maybe playing around with the exact search terms will give more complete results. To remind yourself of the HeartBleed bug, the most famous example of a buffer overread attack, this xkcd cartoon might be useful. Or this youtube movie, if you dislike cartoons.
Sept 18	Static analysis with PREfast & SAL
1st assignment (individual or in pairs): PREfast. Deadline: Thursday Sept 24, 23:59		Some generic feedback
Sept 25	Discussion PREfast project Security testing & Fuzzing (up to SAGE)	David Wheeler, The Apple goto fail vulnerability: lessons learned, personal blog, 2020. Mathias Payer, The Fuzzing Hype-Train: How Random Testing Triggers Thousands of Crashes, IEEE S&P, Vol. 17, No. 1, 2019. Patrice Godefroid et. al, SAGE: whitebox fuzzing for security testing ACM Queue, Vol. 10, No. 1, 2012 SAGE and the 'coverage-guided graybox fuzzing' approaches mentioned in Payer's article (more in particular afl) will be discussed next week.
Group fuzzing project. Deadline: Nov 30
Oct 2	For an introduction to SAGE and afl, and a wider discussion the the DARPA Cyber Grand Challenge, watch: The Smart Fuzzer Revolution by Dan Guido 'Safe' programming languages	To read: Chapters 2 & 3 of lecture notes
Oct 9	Sandboxing	To read: Chapter 4 of lecture notes
Oct 16	Input problems, validation & sanitisation	To read: the OWASP Top 10 [PDF,HTML] (If you want a more background on XXE than the brief description in the Top 10 document, this XML: external entities video gives a nice explanation.) Note that XXE, Cross Site Scription, and Insecure Deserialisation are essentially also injection attacks, and it could be argued that these should simply be included under Number 1. D. Kurilova et al, Wyvern: Impacting Software Security via Programming Language Design, PLATEAU 2014, ACM. Some interesting things to look at: nice example of bypassing crappy input filtering by a WAF (Web Application Firewall), because it rejects use of `..\..` in input parameters to stop path traversals, but happily allows `..\.\..` the SANS/CWE Top 25 creative attempt at SQL injection via a company name. The recent NSA list of Top 25 vulnerabilities exploited by Chinese state-sponsored hacking groups: the list is discussed ZDNet news article by Catalin Cimpanu but you can also look at the original NSA document.
Oct 23 & 30 : no lectures (midterm break/exam period) The lecture-free period may be a good time to read the CyBok chapter on Software Security, also listed at mandatory reading material. One of the topics mentioned, race conditions (aka TOCTOU), will still be discussed in weeks to come.
Nov 6	Guest lectures by Secura Pen-testing, by Geert Smelt Red Teaming for Operational Technologies, by Ben Brücker	Slides are in Brightspace.
Nov 13	Discussion fuzzing project Information Flow (slides)	To read: Chapter 5 of lecture notes
Nov 20	Q&A about last week's Information Flow lecture (in Discord) Discussion fuzzing project (in Discord) Information flow for Android Apps (slides) TOCTOU (slides)	Ernst et al., Collaborative Verification of Information Flow for a High-Assurance App Store, CCS 2014 TOCTOU aka race condition vulnerabilities are also discussed in the CyBok chapter on Software Security, so make sure you have read that by now.
Nov 27	Q&A about last week's lecture on Android Information Flow and TOCTOU. Discussion fuzzing project (6EC version only) Program Verification (slides)	(6EC version only) 2nd individual/pair verification assignment. Deadline: Dec 10
Dec 3		(6EC version only) Another online lab session to work on the verification assignment
Dec 4	Q&A Program Verification and online lab session to work on the verification assignment (6EC version only) LangSec & State Machine Learning (slides)	Poll et al., Protocol State Machines and session languages, LangSec 2015, IEEE S&P workshop, 2015. LangSec revisited: input security flaws of the second kind, LangSec 2018, IEEE S&P workshop, 2018. (The 'forwarding flaws' discussed in the lecture are called 'structured output generation vulnerabilities' in the CyBok chapter on Software Security.)
Dec 11	10:30 (6EC version only) Discussion verification assignment 11:30 Q&A LangSec and State Machine Inference Security Principles (slides)	Avoiding the Top 10 Security Design Flaws , IEEE, 2014.
Dec 18	NB in Brightspace Virtual Classroom, not in Discord. Discussion on fuzzing project Q & A about the material on Security Principles & Design Flaws
Jan 22	Exam at 12:45	Location: de Vereeniging (or for students with right to extra time: HG00.0065 in Huygens Building) BUT CHECK LOCATION IN THE OFFICIAL SCHEDULE The exam is closed book, and covers the material treated in class (and in the slides), the course lecture notes, the papers listed above, and the projects. Mock exam
March 30	Resit exam at 12:45 - see official schedule for location(s)

Prerequisites

Basic programming skills, incl. familiarity with C and Java. In more detail:

For C, you should at least know how pointers, C strings, malloc(), and free(), work, and understand how pointer arithmetic can be used to access elements in a string or an array.
For Java, you should understand the idea of visibility modifiers (public, private, protected, and the default package), making fields final to make them constant, making classes final so that they cannot be subclassed, and the concepts of (de)serialisation and reflection. All these concepts will be briefly explained in the course, but this assumes basic knowledge of object-oriented programming languages, with classes with fields and method and sub-classing aka inheritance.

Topics

Software is the root cause behind most IT security problems. This course addresses two questions:

What are common security problems in software and what are their underlying root causes?
What are techniques, guidelines, principles, and tools that can help to prevent or detect them?

Common security problems include memory corruption, integer overflows, various injection attacks (command injection, SQL injection, XSS, deserialisation attacks ...), race conditions... The LangSec paradigm explains some of these underlying root causes, namely buggy or unintended parsing of many input languages, which are often too complex, too expressive, or ill-specified.

Techniques to prevent or detect problems include threat modeling, checklists and coding standards, code reviews, "safe" programming languages, LangSec (language-theoretic security), fuzzing and other forms of security testing, static analysis tools and source code analyzers, information flow analysis (incl. tainting), program verification, and proof-carrying code.

The focus of this course is not on pen-testing or hacking to find vulnerabilities, as in the RU bachelor courses 'Hacking in C' and 'Web Security', but more on (addressing) the underlying causes and general techniques to improve the security of software.

Grading

The course will be graded based on a written exam. The group project work can earn you a bonus point. The individual exercises are not graded. You MUST seriously participate in the project work to take the exam, and do all individual exercises.

The exam will cover the material presented in the lectures, the obligatory literature listed below, and the project work. The exam is closed book, ie. you cannot bring copies of slides, papers etc to the exam. You're not expected to be able to reproduce technical details from the papers, but you should be able to explain the core ideas. I will only ask about technical details from the papers that have been discussed in the lectures (and are covered by the slides). You are expected to be able to spot simple buffer overflow problems given some hints, but are not expected to spot tricky ones even with hints.

Optional background reading

For additional background info I can recommend:

Common software security flaws
If you are completely new to things like SQL injection, XSS, etc., it is useful to look through The 24 Deadly Sins of Software Security. There is a copy of this book in the library of the Faculty of Science. You can't take it out, but you can always read it there. More information on typical security issues can be found in the OWASP Top 10 and CWE/SANS Top 25 Most Dangerous Programming Errors.
General cyber security interest
Not always directly related to this course: a good way to keep up to date with the news and developments in cybersecurity is following Risky Biz podcast, which also pays plenty of attention to software problems, and Bruce Schneier's blog.