1 / 35

Software Security

Software Security. CS461/ECE422 Spring 2012. Reading Material. Chapter 12 of the text. Outline. Review common vulnerabilities in programs Input Checking Program Logic Errors Errors Interacting with the OS Output handling. Software Vulnerabilities.

colby-fox
Download Presentation

Software Security

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. Software Security CS461/ECE422 Spring 2012

  2. Reading Material • Chapter 12 of the text

  3. Outline • Review common vulnerabilities in programs • Input Checking • Program Logic Errors • Errors Interacting with the OS • Output handling

  4. Software Vulnerabilities • Generally a result of poor programming practices. • OWASP top 10 Web Application Security risks • https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project • A good number are developer bugs

  5. Security in Design and Architecture • Security concerns must be considered up front • Security impacts system architecture • Perhaps re-architect to ameliorate security concerns • Security architecture can be used to drive testing • True even for projects with no “security features” • Leaving security to the test phase (or later) is not a good idea to say the least

  6. Defensive Programming or Secure Coding • Mostly good software engineering • Except when considering security must consider a malicious actor • Traditional software engineering concentrates dealing with errors due to accidents • Goal • Continued functioning of software in spite of unforeseeable usage of said software. • Conflicts with time to market

  7. Make No Assumptions! • Don’t assume the user won’t enter more than 512 characters on the command line • Don’t that there will always be enough disk space • OR codify and enforce your assumptions

  8. Handling User Input • This is where the user (malicious or innocent) can directly impact the program • Always verify the user input • White list expected results • Input can come from a number of places • Text entry • Configuration files • Environment variables • Network

  9. Injection Attacks • Error in input handling that results in unexpected execution flow • Often occurs in scripting languages • Script writer expects user input to be data • But user inputs text that will be interpreted as code

  10. Unsafe Perl Script

  11. Running Script • With user = lpb • Finger userLogin Name lpbLawrie Brown • With user=‘xxx; echo attack success; ls finger*’ • Finger Userattack successfinger.cgi finger.html • Command injection. Running arbitrary commands at the privilege of the web user id.

  12. Safer Script • counter attack by validating input • compare to pattern that rejects invalid input • see example additions to script:

  13. SQL Injection • Or why is this XKCD comic funny • http://xkcd.com/327/

  14. SQL Injection • another widely exploited injection attack • when input used in SQL query to database • similar to command injection • SQL meta-characters are the concern • must check and validate input for these

  15. Code Injection • further variant • input includes code that is then executed • see PHP remote code injection vulnerability • variable + global field variables + remote include • this type of attack is widely exploited

  16. Cross Site Scripting (XSS) • Goal – Inject malicious code into web pages viewed by others. • Sites that allow HTML formatted user input to be stored, e.g. Blog comments, wiki entries. • Enter the following into a form that then shows the original query in the response. • <script>confirm("Do you hate purple dinosaurs?");</script>

  17. XSS Example • cf. guestbooks, wikis, blogs etc • where comment includes script code • e.g. to collect cookie details of viewing users • need to validate data supplied • including handling various possible encodings • attacks both input and output handling

  18. Alternate Encodings

  19. Input Checks • Example of evading input checks • Samy’s explanation of his Myspace worm • http://namb.la/popular/tech.html • Canonicalize input before performing checks • Map the multiple versions of ‘A’ to a particular value • Issue for numeric values too • Is the number 16 bits or 32? • Signed or unsigned? • Negative number or large positive

  20. Input Fuzzing • Generate “random” inputs to test programs • Environment variables • Input strings • Network values • Could be completely randomized or somewhat structured • Minifuzz • ShareFuzz • Spike • MuDynamics • Standard component of Microsoft’s Software Development Lifecycle

  21. More Fuzz - SPIKE • An input language for creating variant network packets • From WireShark output, make it easy to express new packets • a_binary(“00 01 02 03”)Data: <00 01 02 03> • a_block_size_big-endian_word(“Blockname”);Data: <00 01 02 03 00 00 00 00> • a_block_start(“Blockname”)a_binary(“05 06 07 08”)Data: <00 01 02 03 00 00 00 00 05 06 07 08> • a_block_end(“Blockname”);Data: <00 01 02 03 00 00 00 04 05 06 07 08>

  22. Writing Correct/Safe Code • Is your algorithm correct? • Incorrect use of random number generators • Bad seeds • E.g. Code Red and Netscape • TCP session hijacking • How random is the sequence number? • Leaving in test code • Used by Morris Worm

  23. Is there a bug in the compiler? • Ken Thompson Trojan compiler example • Required for higher levels of Common Criteria • Correspondence of design, source, and object code.

  24. Correct Use of Memory • Memory Leak • Run process out of memory. DoS • Free/Allocation errors • Heap overflow, can enable arbitrary execution • Could be solved by • Heap randomization • Tools to track heap utilization • Valgrind • Duma

  25. Race Conditions and Shared Memory • Multiple threads of control accessing a common memory location • Subtle (and not so subtle) errors in synchronization are possible • Multiple writers • Writing while another thread is reading • Deadlocks • Errors vary from invocation to invocation • Attacker could attempt to trigger a latent threading error

  26. Environment Variables • Another way for the program to get input • And should be treated as such • Generally set up for the user • Sysadmin creates a profile for the user that initializes the environment • Environment variables read by compiled programs and scripted program

  27. Example Vulnerable Scripts • using PATH or IFS environment variables • cause script to execute attackers program with privileges granted to script • SetUID root scripts would be attractive • almost impossible to prevent in some form • Though the use of IFS has been restricted in most modern shells

  28. Path Attack On Libraries • Dynamic libraries are loaded at invocation time • Loader must search the system to find the libraries needed by the executable • LD_LIBRARY_PATH • Flexibility vs attack avenue

  29. Least Privilege • Ideally run a program with as many privileges and access rights as it needs but no more • What’s the hard in too much access? • Root in Unix • Web servers and file access • What files does the web server process need to read? Need to write? • How long does a program need special privilege? • E.g., a low port network service program • Divide program into sets of processes • Move the privilege required elements into smaller, simpler processes

  30. System Calls andStandard Library Functions • programs use system calls and standard library functions for common operations • and make assumptions about their operation • if incorrect behavior is not what is expected may be a result of system optimizing access to shared resources • by buffering, re-sequencing, modifying requests • can conflict with program goals

  31. Secure File Shredder

  32. Race Conditions • Files can be used to synchronize access to OS resources between processes • If [ ! –e $file ]then touch $fileelse echo “You don’t have the lock”fi • Time of check to time of use (TOCTOU)

  33. Temporary Files • Many programs create temporary intermediate files • Can create unique names based on process id • How could an attacker leverage this? • do { filename = tempnam(NULL, “foo”);fd = open(filename, ….) free(filename);} while (fd == -1);

  34. Output Checking • Example 1 • Active display • VT100 command characters • Or X-terminal display hijack • Example 2 • Cross Site Scripting • Generate display from stored data • Data is interpreted as command

  35. Summary • Useful to look at common software vulnerabilities • Know common issues to avoid going forward • Even more important to consider security in the design architecture • More likely to catch/avoid problems if you think from the security perspective up front • Someone will be thinking from the security perspective eventually

More Related