Launchpad entry: none yet
Created: 2006-08-01 by JohnMoser
This spec defines a source code auditing aspect of the Ubuntu Hardened Team specified in HardenedUbuntu: The Ubuntu Hardened Source Code Auditing Team
The HardenedUbuntu/Vulnerability Team can be made more effective if bolstered by a source code auditing effort to search for vulnerabilities using auditing techniques and to analyze potential vulnerabilities and determine if a real vulnerability exists.
- The Ubuntu Hardened Vulnerability Team finds a discussion on the GNOME mailing list about a segmentation fault in Epiphany. They direct the Ubuntu Hardened Source Code Auditing Team to the thread; after some debugging, reverse engineering, and source code examination, they determine a way to execute arbitrary code in GECKO using Java Script.
The Ubuntu Hardened Source Code Auditing Team locates a heap execution vulnerability in libpng, and shares the details with the Ubuntu Hardened Vulnerability Team and then with Gentoo, Debian, and RedHat security teams in order to help work on a fix and distribute a patch.
Security-critical and network-exposed programs such as openssh, gaim, firefox, or rhythmbox need to be audited along with the entire set of libraries they use periodically. The Ubuntu Hardened Source Code Auditing Team coordinates work with other source code auditing teams and security teams on other distributions in order to spread the focus and make sure repeated audits are performed temporally stratified instead of in tandem.
The Ubuntu Hardened Source Code Auditing team will have the following responsibilities:
Write patches for new vulnerabilities that have none and share with the HardenedUbuntu/Vulnerability Team and other distributions' security teams.
- Respond to crasher bugs by examining source code and binary packages to determine if certain classes of bugs are actually security holes.
- Communicate concerns and findings with other distributions' security teams and with the Ubuntu Hardened Vulnerability Team.
- Periodically source code audit important packages and libraries, especially network exposed programs such as daemons, Web browsers, IRC clients, and streaming media players.
- Communicate with other teams to coordinate auditing efforts to assure that the same package is not audited by too many people at the same time; multiple audits are preferable at different times to give the later auditors a look at newer code.
A team will be created that follows the above scope. Any current developers with the task of source code auditing may fall into this team.
Implementation is pretty straight forward. A few useful tools may be needed along the way:
- RATS, Flawfinder, and other source code auditing tools.
elfsh, a reverse engineering tool that can be used to manipulate running binaries and inject code into them to see what happens.
gdb, to debug "oddness" and get a feel for where to look when chasing a bug that may be a vuln.
Data preservation and migration