1 / 22

CMSC 414 Computer and Network Security Lecture 24

CMSC 414 Computer and Network Security Lecture 24. Jonathan Katz. Application-level security. Application-level security. I.e., programming-language security Previous focus was on protocols and algorithms to prevent attacks Are they implemented correctly?

bonnie
Download Presentation

CMSC 414 Computer and Network Security Lecture 24

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. CMSC 414Computer and Network SecurityLecture 24 Jonathan Katz

  2. Application-level security

  3. Application-level security • I.e., programming-language security • Previous focus was on protocols and algorithms to prevent attacks • Are they implemented correctly? • Here, focus is on programming errors and how to deal with them • Reducing/eliminating/finding errors • Containing damage resulting from errors

  4. Classifying flaws • Intentional flaws • E.g., “backdoors” • Unintentional flaws • E.g., programmer errors

  5. Buffer overflows • 50% of reported vulnerabilities • Overflowing a buffer results in data written elsewhere: • User’s data space/program area • System data/program code • Including the stack, or memory heap • Can also occur in other contexts • E.g., parameters passed via URL

  6. topofstack buf sfp ret-addr str topofstack ret str *str Example • Suppose a web server contains a function:void func(char *str) { char buf[128]; strcpy(buf, str); do-something(buf); } • When the function is invoked the stack looks like: • What if *str is 136 bytes long?

  7. topofstack *str ret Code for P Program P: exec( “/bin/sh” ) Basic exploit • Suppose stack looks like: • When func() exits, user will be given a shell !! • Note: attack code runs in stack (exact shell code by Aleph One)

  8. Finding buffer overflows • Hackers find buffer overflows as follows: • Run web server on local machine • Issue requests with long tags. All long tags end with “$$$$$” • If web server crashes: search core dump for “$$$$$” to find overflow location.

  9. Incomplete mediation • E.g., changing symbolic link between checking and use • E.g., parameters passed via URL • Parameters may be checked at client-side… • …but checking still necessary server-side • E.g., changing prices in URL…

  10. Cross-site scripting • Violation of privacy… • General rule: always check inputs from untrusted source!

  11. Time-to-check vs. time-of-use • “Serialization/synchronization” flaw • E.g., presenting command; then changing command while it is being verified

  12. Covert channels • Intentionally inserted by programmers into software, to later leak information… • Examples in book…e.g., spacing information in printed page, formats, etc. • Other examples: “file lock” channel, existence/non-existence of file, etc.

  13. Analysis of covert channels • “Shared resource matrix” • Tabulates subjects and the resources thave have access to • Information flow analysis (in source code) • E.g., “B = A” supports info. flow from A to B • “If (D == 1) then B = A” supports info. flow from D to B also! • Trace information flow throughout program…

  14. Timing attacks • Password checking routines… • Web caching

  15. Finding/preventing flaws

  16. Penetration testing? • Limited to finding/patching existing flaws • Cannot be used to guarantee that software is free of all flaws • Patching flaws in this way has its own problems • Narrows focus to fixing a specific flaw, rather than addressing issues more broadly • May introduce new flaws

  17. Automated testing • Successful to some extent • Hard to catch all flaws • Traditional program verification/testing focuses on what a program should do • Here, we are concerned with things a program should not do

  18. Techniques for preventing flaws • Secure programming • Developmental controls • Better techniques • Secure programming languages • Static analysis • Secure compilation • Dynamic analysis • Software fault isolation

  19. Techniques… • Inferring trust • Source authentication/code signing • Proof-carrying code • OS controls • Sandboxing • System-call interposition techniques • Secure boot of OS

  20. Developmental controls… • Modularity • Improves ability to locate flaws • Easier to verify/fix code • Encapsulation/information hiding • Peer review/testing/analysis • Automated code testing

  21. Secure programming techniques (Based on: “Programming Secure Applications for Unix-Like Systems,” David Wheeler)

  22. Overview • Validate all input • Avoid buffer overflows • Program internals… • Careful calls to other resources • Send info back intelligently

More Related