1 / 32

CS363

Week 5 - Wednesday. CS363. Last time. What did we talk about last time? Attacks on hash functions. Questions?. Project 1. Assignment 2. Security Presentation. Tom Gorko. Program Security. Secure programs. For now, we will be pretty broad in our definition of programs OS Applications

bella
Download Presentation

CS363

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Week 5 - Wednesday CS363

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

  3. Questions?

  4. Project 1

  5. Assignment 2

  6. Security Presentation Tom Gorko

  7. Program Security

  8. Secure programs • 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. Fixing faults • 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. Penetrate and patch • 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. Terminology • 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 • 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. Why is life so hard? • It’s very difficult to eliminate program security flaws for two reasons: • 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 • Software engineering develops faster than computer security • We’re always playing catch-up

  14. Non-malicious program errors

  15. Flaws • Landwehr et al. divided flaws into intentional and inadvertent • The inadvertent flaws were divided into six categories • Validation: Incomplete or inconsistent permission checks • Domain: Poorly controlled access to data • Serialization and aliasing: Mistakes in program flow order • Identification and authentication: Incorrect basis for authentication • Boundary condition: Failure on the first or last case • 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. Buffer overflows • 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( inti = 0; i < 10; i++ ) buffer[i] = 'A'; buffer[10] = 'B';

  17. Buffer overflow • It could overwrite: • User data • User code • System data • System code User Data User Data User Code User Data System Data User Data System Code

  18. Buffer overflow security • 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 • 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. Incomplete mediation security • 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

  21. Bobby Tables

  22. Time-of-check to time-to-use • 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. Time-of-check to time-to-use • 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:

  24. Case Study: Therac-25

  25. Therac-25 background • 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. Tragedies • 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. Direct causes • 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. Indirect causes • 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

  29. Quiz

  30. Upcoming

  31. Next time… • Review for Exam 1

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

More Related