1. Week 5 - Wednesday

2.  What did we talk about last time?  Attacks on hash functions

6. Tom Gorko

8.  For now, we will be pretty broad in our definition of programs  OS  Applications  Databases  Almost any other software  What is a secure program?  How do we know?  How do we keep programs free from flaws?  How do we protect computing resources against programs that contain flaws?

9.  We can judge security by the number of faults found in a program  Count the number of faults found and fixed  Program is good if it has few faults to begin with, right?  But isn’t the program good if we’ve fixed a lot of faults?  Which is more meaningful?

10.  In the early days, security was shown by finding faults and patching them  Unfortunately, patching a fault often led to creating another one  Why?  The patch fixed a narrow problem, but the cause was more general  The fault had non-obvious side effects  Fixing one problem caused a problem somewhere else  The fault was poorly fixed because a proper fix might impact functionality or performance

11.  We talk about software bugs, but the term is vague  The IEEE favors the following:  Error: A human mistake in developing software (bad design, bad implementation, typo… )  Fault: An incorrect step inside of a program (many faults can be caused by a single error)  Failure: A system departing from its required behavior (a failure might not happen if a particular fault is never executed)

12.  Unexpected behavior is called a program security flaw  The IEEE terminology is for software engineering and doesn’t match exactly  A program security flaw could be a fault or a failure  Intentional security incidents are called cyber attacks  Cyber attacks are not as common as the problems caused by unintentional flaws

13.  It’s very difficult to eliminate program security flaws for two reasons: 1. Programs should do a long list of operations correctly and shouldn’t do another (possibly infinite) list of operations  The number of combinations to test is staggering 2. Software engineering develops faster than computer security  We’re always playing catch-up

15.  Landwehr et al. divided flaws into intentional and inadvertent  The inadvertent flaws were divided into six categories 1. Validation: Incomplete or inconsistent permission checks 2. Domain: Poorly controlled access to data 3. Serialization and aliasing: Mistakes in program flow order 4. Identification and authentication: Incorrect basis for authentication 5. Boundary condition: Failure on the first or last case 6. Logic: Any mistakes in logic not already covered  Other lists have been made, but this one is representative  The next slides will cover some common types

16.  A buffer overflow happens when data is written past the end (or beginning) of an array  Consider the following Java code:  In Java, this code will throw an ArrayIndexOutOfBoundsException, but it will not write memory where it shouldn’t  In C/C++, it would char[] buffer = new char[10]; for( int i = 0; i < 10; i++ ) buffer[i] = 'A'; buffer[10] = 'B'; char[] buffer = new char[10]; for( int i = 0; i < 10; i++ ) buffer[i] = 'A'; buffer[10] = 'B';

17.  It could overwrite:  User data  User code  System data  System code AAAAAAAAAAB User Data AAAAAAAAAAB User Code AAAAAAAAAAB User DataSystem Data AAAAAAAAAAB User DataSystem Code

18.  Without the presence of malicious attackers, buffer overflows can corrupt your data (or the system’s) or crash your program  A malicious attacker can exploit buffer overflows  By inserting data into system data or code so that the system does what he or she wants  By overwriting the stack pointer to cause arbitrary code in the attacker’s memory to be executed

19.  Incomplete mediation happens with a system does not have complete control over the data that it processes  Example URL:  http://www.security.com/query.php?date=2012March20  Wrong URL:  http://www.security.com/query.php?date=2000Hyenas  The HTML generates the URL, but the URL can be entered manually

20.  For a website, a carelessly altered URL might just mean a 404 error  For a program, bad data could cause any number of faults and failures  Malicious attackers could change data or mount an SQL injection attack to destroy or reveal database internals  Values should always be checked and sanitized

22.  A time-of-check to time-to-use flaw is one where one action is requested, but before it can be performed, the data related to the action is changed  The book’s example is a man who promises to buy a painting for $100 who puts five $20 bills on the counter and pulls one back when the clerk is turning to wrap up the painting  In this flaw, the first action is authorized, but the second may not be

23. FileCommand MyFile.txt Change byte 4 to 'A' FileCommand YourFile.txt Delete file  It seems like things happen instantly in a computer  Many operations, especially those on files, may be put into a queue of work  Imagine you give the OS a data structure with this command:  After it is authorized but before it can be executed, you change it to:

25.  Therac-25 was a radiation therapy machine built by the Atomic Energy of Canada Limited  It was the successor to the Therac-6 and Therac-20 machines  The machine had low power and high power modes  The low power mode shot a beam directly at the patient  The high power mode created X-rays by shooting the beam at a target, spread these X-rays with a flattening filter, shaped the beam with movable blocks, and tested the strength of the beam with an X- ray ion chamber

26.  In some situations, the high power beam was activated without the spreader in place  The software and hardware systems did not catch this particular problem  Over 100 times the intended dose was given  At least 2 people died and there were at least 6 overdoses total  Software bugs actually kill people!

27.  A certain unusual combination of keystrokes had to happen within 8 seconds  There were no hardware interlocks to prevent the problem if the user overrode the error code  Error codes were not well-documented and were displayed as a number  Software was reused from previous models that did have hardware interlocks  Arithmetic overflow caused safety checks to fail in some cases

28.  The software/hardware combination had never been tested before use  Personnel did not believe complaints due to confidence in the system  Code was not independently reviewed  Errors were easily overridden

31.  Review for Exam 1

32.  Keep reading Chapter 3  Finish Assignment 2  Due this Friday  Keep working on Project 1  Due next Friday