Outline Orientation
Motivations Secure Programming Lecture 1: Introduction Topics in the course This course is Secure Programming It is taught by David Aspinall Practicalities David Aspinall, Informatics @ Edinburgh In the School of Informatics at the University of Edinburgh. Recommended resources
13th January 2014 References
What is this course about? Why should you take this course? Why should you not take this course?
É Building software that’s more secure
É finding security flaws in existing software É avoiding flaws in new software É Want to work in the cyber security industry? É techniques, tools and understanding to do this É None of the previous points apply É security appraisal, system and code reviewing É You don’t have the right background (see next slide) A better title might be Software Security É ethical hacking É É malware analysis You don’t want to risk taking a new course It’s not only about the programming. . . É cyber defence (or attack, espionage, . . . ) É running earlier than expected É materials are still in development É Want to work in security research? É Infrastructure around software É will have teething troubles É academic (conceptual advances, fixing, breaking) É language, libraries, run-time; other programs É please bear with us É commercial (mainly breaking and fixing) É data storage, distributed software É honest, constructive feedback is very welcome É (Hopefully): you think it’s fun and interesting! É Security policies:
É what should be protected É what is trusted
É Risk assessment Target audience Learning outcomes Safety versus security
Here is the list from the Course Catalogue Entry: É Aimed at 4th year UGs É Should have passed 3rd year Computer Security 1. Know how to respond to security alerts (concerning Safety is concerned with ensuring bad things don’t É Programming practice software) happen accidently. For example, aeroplanes don’t fall É should be confident in programming 2. Identify possible security programming errors when out of the sky because maintenance checks are É necessarily will use a range of languages conducting code reviews in languages such as Java, forgotten. É . . . including some C C or Python Security is concerned with with ensuring that bad É but don’t have be “master hacker” 3. Define a methodology for security testing and use things don’t happen because of malicious actions by É Programming theory appropriate tools in its implementation others. For example, terrorists cannot drive bombs into 4. Apply new security-enhanced programming models É interest in PL concepts and design airport departure halls. É knowledge of compilers useful and tools which help ensure security goals, e.g., É also software engineering, esp testing with access control, information flow tracking, É theory courses helpful, semantics protocol implementation, or atomicity enforcement.
The challenge of software security Cost estimates are difficult But it’s agreed they’re increasing. . .
Software artefacts are among the most complex built.
É Design flaws are likely É Bugs are near inevitable
Flaws and bugs lead to vulnerabilities which are exploited by attackers. Usually: to learn secrets, obtain money. Cyber warfare is real And privacy is disappearing Why isn’t software security better?
Why (else) isn’t software security better? What’s the outlook? Dimensions: practice and theory Practice
É Programming securely, identifying security issues É Asymmetry: attackers have the advantage New frontiers: É Mistakes in language, APIs, crypto, comms. . . É just need to find one viable attack route É Ultimately: detailed, highly specific knowledge É defenders have to anticipate all É PCs in decline, but connected devices increasing É Attackers focus on weakest links: É Mobile new target point (convergence, mobility) Theory
É since 1990s, network security defences vastly É Cloud storage: storage providers, protocols improved É Cyber resilience: need for automatic response, É Understand reasons for failure, ways to mitigate patching É Understand advanced techniques, automated tools É Current penetrate-and-patch approach is broken É Secure programming practice must extend to new É In general: transferable concepts and methods. É understood by managers and developers (“show me domains, modes the problem!”) This is not really a “vocational” course. I hope it will É but no substitute for secure design give you the foundation to allow you to rapidly develop detailed specific knowledge needed later. There are a number of certification schemes for building practical knowledge. Overview of topics Threats Vulnerabilities
General organisation:
É Threats É What attackers want, can do É Overflows – example next É Vulnerabilities É Types of bad code: malware, spyware, PUPs É Injections É Defences É How bad code gets in É Race conditions É Processes É Classification of vulnerabilities and weaknesses, É Information leaks É Emerging Methods CVE/CWEs
We’ll look at details under each of these headings (in various orders).
Overflow example Overflow example What is a BDF file?
338 char charName[100]; STARTFONT 2.1 339 int ignore; 338 char charName[100]; COMMENT 340 339 int ignore; COMMENT Copyright (c) 1999, Thomas A. Fine 341 if (sscanf((char *) line, "STARTCHAR %s", charName) !=1){ 340 COMMENT 342 bdfError("bad character name in BDF file\n"); 341 if (sscanf((char *) line, "STARTCHAR %s", charName) !=1){ ... 343 goto BAILOUT; /* bottom of function, free and return error */ 342 bdfError("bad character name in BDF file\n"); FONT -atari-small 344 } 343 goto BAILOUT; /* bottom of function, free and return error */ SIZE 11 75 75 344 } FONTBOUNDINGBOX 4 8 0 -1 STARTCHAR C000 SYNOPSIS ENCODING 0 Jan. 7, 2014 - Stack buffer overflow in parsing of BDF SWIDTH 1 0 #include
[lib/libXfont/src/bitmap/bdfread.c:341]: (warning) scanf without field width limits can crash... diff --git a/src/bitmap/bdfread.c b/src/bitmap/bdfread.c index e2770dc..e11c5d2 100644 This bug appears to have been introduced in the initial --- a/src/bitmap/bdfread.c Evaluation of this report by X.Org developers concluded RCS version 1.1 checked in on 1991/05/10, and is +++ b/src/bitmap/bdfread.c that a BDF font file containing a longer than expected thus believed to be present in every X11 release @@ -338,7+338,7 @@ bdfReadCharacters(FontFilePtr file, FontPtr pFont, bdfFileState *pState, char charName[100]; string could overflow the buffer on the stack. starting with X11R5 up to the current libXfont 1.4.6. int ignore; Testing in X servers built with Stack Protector resulted (Manual inspection shows it is present in the sources in an immediate crash when reading a user-provided from the X11R5 tarballs, but not in those from the - if (sscanf((char *) line, "STARTCHAR %s", charName) !=1){ + if (sscanf((char *) line, "STARTCHAR %99s", charName) !=1){ specially crafted font. X11R4 tarballs.) bdfError("bad character name in BDF file\n"); goto BAILOUT; /* bottom of function, free and return error */ As libXfont is used to read user-specified font files in all } X servers distributed by X.Org, including the Xorg server which is often run with root privileges or as setuid-root in order to access hardware, this bug may lead to an unprivileged user acquiring root privileges in some systems.
Defences Processes Emerging methods
É Protection mechanisms É Secure design principles É Methods and tools to find problems É Avoidance by secure coding É Testing and reviewing to find vulnerabilities É Detecting buggy patterns automatically É Trade-offs in adding protection mechanisms É Assessing/measuring security of code É Building security in: language based security Delivery and assessment Lab sessions Formative feedback during Labs
Scheduled on Fridays at 2pm-5.30pm:
We will have É Week 3, 31st January One reason to introduce labs in this course is to allow É Week 5, 14th February É 16 lectures covering core course topics us to give face-to-face formative feedback on your É Week 7, 7th March learning. É 4 lab sessions É Week 9, 21st March É 1 coursework contributing 30% of final mark We plan to do this by reviewing the results from one lab É 1 written exam contributing 70% of final mark Each session will examine some software session at the next lab session. To do this effectively we vulnerabilities: why they exist, how they can be will ask that you submit your work and/or discuss it Lecture slides will be made available in several formats. discovered, exploited, and repaired. with us during the lab sessions. They have numerous embedded links to useful Labs will start with a guided introduction (up to 30 Lab sessions will be run by me together with the course resources (the links are more noticeable in the online mins). TA, who is Joseph Hallett. versions). Working together is encouraged. We want to foster a supportive learning environment. Students who have prior knowledge or expertise are especially welcome.
Coursework Ethics Communications
A repeat of the advice given in the Computer Security É New course: course: É honest, constructive feedback is very welcome The coursework will be an assignment following a Nothing in this course is intended as incitement É As with any course, I welcome similar pattern to the lab exercises: discover, exploit to crack into running systems! then repair. É questions after lectures É questions by email É Breaking into systems to “demonstrate” security 1. as usual: your work should be your own problems at best causes a headache to overworked Shall we have a course-wide online facility? Open to 2. no publication, please do not publish solutions sysadmins, at worst compromises systems for class opinion: even after the deadline many users and could lead to prosecution É If you spot a security hole in a running system, (at least two reasons for last point). 1. University forum (private in UoE) don’t exploit it, instead contact the relevant 2. University VLE tool (Learn) administrators or developers confidentially. The coursework deadline is scheduled for Week 8. 3. Nota Bene for asking questions, annotating É To experiment with security holes, play with your documents (public) own machine, or better, your own private 4. None, but FAQs sent to class list sp-students by network of machines. email Exam Older books Newer books (1) J. Viega and G. McGraw. Building Secure Software: How to Avoid Security Problems the Right Way. B. Chess and J. West. Secure Programming with Static Will follow the common format: Addison-Wesley, 2001. Analysis. Addison-Wesley, 2007.
É Choose 2 questions to answer from 3 One of the first books on the topic of Secure This book introduces ideas behind static Programming. Still useful to understand some É Two hours allowed analysis tools for detecting security flaws. of the principles, although details are not Written by the founders of Fortify, now a part of A new course; there are no past papers available. current. HP. Towards the end of the course I will provide: M. Howard and D. LeBlanc. Writing Secure Code. M. Dowd, J. McDonald and J. Schuh. The Art of Software Microsoft Press, second edition, 2003. É a list of topics and concepts that may be examined Security Assessment. Addison-Wesley 2007. É a hint about the format of the questions Another early book; this one focuses on A lengthy book with deailed guidance on code É one sample question Windows. Again highly influential and useful for reviewing for secure programming. reference, but not up-to-date for current use. More recent titles are available from the Microsoft Press.
Newer books (2) Online resources End notes (links to references)
David Basin, Patrick Schaller, Michael Schlapfer. Applied Information Security: A Hands-on Approach. Cost of cyber crime Springer, 2011. É OWASP, the web application security project is one É The 2007 US Government report estimated a cost A short practical introduction using Linux VMs of the best places to find out about software of $105bn pa to US to demonstrate some attacks and defences. security. É The 2011 UK Government report, which suggested
É The CERT secure coding website provides online a cost of £27bn pa to UK. Fred Long et al. The CERT Oracle Secure Coding versions of the CERT coding standards, which are É It was criticised for being overblown The 2013 Standard for Java, Addison-Wesley, 2012. developed in a Wiki. evidence-based review estimated “several billions”.
A set of guidelines for Java. Some need to be É SANS, a security training organisation, provides Ransomware enforced by design and code reviews; others some useful resource including some material on might be enforced automatically by tools. secure programming. É The CryptoLocker ransomware and copies of it infected PCs at the end of 2013. It uses CERT also provide a shorter book Java Coding vulnerabilities in Java and PDF plugins. Guidelines: 75 Recommendations . . . as well as books giving coding standards for C and C++. Stuxnet
É Stuxnet (2010) was the first example of cyber warfare made public. Designed to thwart Iran’s nuclear enrichment programme, in 2013, it was reported that Stuxnet also infected Russian facilities
Responsibility for insecure software
É See Microsoft’s licensing terms for their EULAs. Most manufacturers (and open source vendors) have similar terms, of course. É Bad Code: Should Software Makers Pay? in New Republic magazine, October 2013. É David Rice. Geekonomics: The Real Cost of Insecure Software, Addison-Wesley, 2007. Read an interview with the author on SANS. É The Rugged Software Manifesto, an attempt to start a grassroots movement among developers.