Courses/Computer Science/CPSC 525.W2013/Bug Project

From wiki.ucalgary.ca
Jump to: navigation, search

Project Specification

Bug Hunting Project (400 points total)
Initial Release: Jan 26, 2013
First Bug Due By: March 17, 2013 23:59
Second Bug Due By: April 8, 2013 23:59
Update: First Bug Due By: March 31, 2013 23:59

Note to vendors or software maintainers

The purpose of this assignment is to perform a public service as a hands-on learning exercise. Students learning about information and computer security have the right to question trust assumptions in systems as a way to hone their vulnerability analysis and security design skills. The intent of this assignment is to have a positive impact on the state of cybersecurity by identifying flaws in real software and reporting these flaws to the vendor or software maintainer. These flaws are also reported to the course instructor, but are not publicly released unless the student and the vendor agree on an appropriate procedure for doing so.

The bugs that students find are not meant to be earth-shattering disclosures, but rather evidence that:

  • students have the skills to find and analyze software flaws
  • bug-free software is hard to write and maintain
  • students can "give back" to the community by diagnosing and reporting such flaws
  • there is no danger in letting students have this knowledge

The TSG bug reporting policy helps guide our disclosure policy for this assignment.

Learning Outcomes

The purpose of this project is to help you achieve the following outcomes:

  • practice at the security mindset by questioning the trust assumptions in code and systems
  • directly challenge your ethical framework by finding bugs in real software and raising the question of how best to document and report such flaws
  • build experience finding vulnerabilities based on observable errors, faults, or bug conditions
  • practice the skills necessary to debug, analyze, disassemble, or otherwise discover the underlying conditions necessary to reliably reproduce a vulnerability
  • hone your ability to briefly document the security implications of software flaws and system failures
  • provide you with the opportunity to develop professional engagement skills when presenting bug and vulnerability reports to software vendors or maintainers

Task Description

Your task is to find two flaws in any piece of software on any system you own, control, or have lawful access to. The software you choose to analyze can be proprietary, open source, professional, hobbyist, etc. It can be desktop software, a mobile app, a web app, or any combination. You need not restrict yourself to trying to find remote x86 code injection attacks against a popular piece of desktop or server software.

For each flaw you find, you should produce a report that contains the following elements. Each report is worth 200 points. Points for each element are listed below.

  1. a brief, 2-sentence summary of the flaw in the style of CVE announcements (or similar bug reports) (5 points)
  2. information identifying the software and system you analyzed (e.g., Apache 2.0.3 on Fedora 12, kernel 2.6.44-XXX). You should identify, as much as possible, the name and version of the compiler that produced the software, the versions of any relevant runtime libraries, the version of the OS and kernel running the software, and generally enough information so that someone else can reproduce the same testing or analysis environment (5 points)
  3. Any initial evidence of the flaw, error condition, or vulnerability's existence (such as a screen shot of an error message or other symptom) (5 points)
  4. a description of the process you used to analyze the software or system, including the names and versions of any tools or debuggers you used, where you found them, whether you wrote them (or a script, or plug-in, or module for them). This description should document in clear, brief steps, how you localized the flaw in the target system, including whether you looked at source code or assembly or a combination of the two (if applicable). (50 points)
  5. a list and brief description of any relevant file formats, network protocols, data types, or data transport layers involved in exercising the flaw (10 points)
  6. the exact lines of code (or equivalent) containing the flaw (5 points)
  7. a proof-of-concept input or set of actions, including the correct environment conditions, configuration, or settings necessary to reproduce or trigger the flaw (50 points)
  8. a discussion of the security implications of the flaw, if any (25 points)
  9. an informed estimate of the severity of this flaw (e.g., how many systems or users it might affect, how quickly you judge it should be patched) and your perception of the difficulty of fixing the flaw (for example, does the flaw require a fundamental redesign, or is it a relatively simple condition check) (25 points)
  10. a description of any interaction you had with the software maintainer or vendor in reporting the flaw (10 points)

In identifying a target to study, you may wish to consider the following points:

  • the two bugs may be from the same system, but they need not be.
  • the stated security reporting policy of the system owner, vendor, or software maintainer, if any. You should also consider the legal environment surrounding the issue of vulnerability identification and analysis. As a result, you should only analyze systems you directly own or control (such as a copy of a piece of software you can download to your personal machine). Read and consider the applicable software license terms for the system you plan to analyze
  • whether or not you can operate on a copy of the software or system, or if you can only analyze a production copy of the system (the latter is not advised; for example, you may be able to easily find some sort of flaw in UofC's PeopleSoft implementation, but exercising or exploiting that flaw might have the potential to damage a production system valuable to the UofC community). Consider the implications of the vulnerabilities you find before trying to exercise them or produce a reliable exploit.
  • you should not create a "weaponized" exploit; that is, you should work toward characterizing the conditions necessary to reliably reproduce the flaw or evidence of the vulnerability, and this activity may extend to producing a "proof-of-concept" exploit (i.e, an input sequence leading to exposes the vulnerability symptoms), but you should not cause your PoC to contain a payload that would have an adverse affect on the system
  • In reporting the flaw, you may include a reference to the course wiki page for this assignment (i.e., this page). You should send this communication from your University of Calgary account. If you experience a negative interaction, please inform the instructor promptly.

Background Reading on Vulnerability Disclosure

  1. http://seclists.org/dailydave/2010/q2/58
  2. CERT's stance: http://www.cert.org/kb/vul_disclosure.html
  3. http://seclists.org/bugtraq/1996/May/0
  4. http://seclists.org/fulldisclosure/2002/Jul/7
  5. https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
  6. http://isc.sans.edu/diary.html?storyid=6820&rss
  7. http://arstechnica.com/science/2012/06/controversial-h5n1-bird-flu-papers-published-fuels-fears-of-airborne-mutations/
  8. http://www.reddit.com/r/netsec/comments/1ix3it/application_sandboxes_a_pentesters_perspective_pdf/cbiu03c
  9. http://threatpost.com/relax-you-dont-have-to-fix-every-vulnerability/101927

A Case Study

Example Bugs

Retrieved from "http://wiki.ucalgary.ca/index.php?title=Courses/Computer_Science/CPSC_525.W2013/Bug_Project&oldid=66447"