Launchpad entry: https://launchpad.net/distros/ubuntu/+spec/automated-problem-reports-tagging-for-security
Created: 2006-07-12 by JohnMoser
Contributors: JohnMoser
Packages affected:
Summary
This spec describes using AutomatedProblemReports and AutomatedProblemReportsTagging to help bring developer focus to likely new security vulnerabilities.
Rationale
In the course of generating AutomatedProblemReports, the details of what triggered the report can indicate certain classes of potential security vulnerabilities. We should take advantage of this to give Ubuntu developers an edge in locating and correcting security vulnerabilities.
Use cases
There are many use cases:
- Rhythmbox spontaneously crashes, and the end user doesn't know why. The automated report reveals termination due to a Stack Smash detected in libvorbis.
Firefox certain Java Script causes a double-free(), but the data that triggered it came from a PRNG seeded by the date and the user has no idea why it can't be reproduced. The automated report reveals that glibc was detecting a double-free() and bailing out.
A user assumes an image is corrupt because every image application crashes when opening it. The automated problem report reveals malloc() detected allocation chain corruption and bailed, indicating a possible heap overflow.
- A rare and mostly harmless segmentation fault in an application is reported as a bug. Reviewing the automated problem report shows the fault occurs when the application attempts to execute the heap, which may indicate a way to trick the application into executing user-supplied data.
- Several thousand problems have been reported this month, thirty of which are likely security vulnerabilities. The data is sorted to show likely security vulnerabilities first, and likely plain bugs last.
In each of these cases the AutomatedProblemReports daemon would report a problem back to Ubuntu. On the server, these reports would be tagged and prioritized so that likely security vulnerabilities could be examined first.
Scope
The scope of this spec includes a handful of reliably detectable security situations. Our goal is to tag and prioritize these as likely security holes that need immediate attention when submitting AutomatedProblemReports, as opposed to other simple crashes.
Stack Smash. These are easy to detect due to GccSsp; we have to modify the handler in glibc so it triggers AutomatedProblemReports, but that is not a problem. These are effectively always security vulnerabilities, and detecting one is always a true positive.
double-free(). This may require a little patching of glibc to call AutomatedProblemReports. glibc can detect double-free() events. A detected double-free() will almost always indicate a security vulnerability such as with zlib-1.1.3; this is almost always a true positive.
Heap Corruption. This may require a little patching of glibc to trigger AutomatedProblemReports. glibc is capable of detecting some heap badness, which can indicate heap overflows, free() of invalid addresses, or the like. We should try to report free() of invalid vs. malloc() finding corrupt heap chain entries along the way. Just guessing, this is likely occasionally or possibly often indicative of a security bug and sometimes a false positive.
In addition to specific detection systems, SIGSEGV and SIGILL in various conditions may indicate specific security flaws. These situations show certain conditions where code can be altered or data can be executed, indicating the possibility that externally supplied data can alter the execution of a program. See Priority under Unresolved issues below for details.
We are only minimally interested in overflows trapped with FORTIFY_SOURCE at run-time; these are highly specific and do not work if invoked from wrapper functions, i.e. using glib will defeat this. As Ubuntu doesn't use FORTIFY_SOURCE, we don't care right now. Still, we should trap these as well later.
Design
glibc is already capable of malloc() and free() checks, but needs to trigger our daemon.
glibc needs to trigger our daemon from __stack_chk_fail() when GccSsp goes off.
AutomatedProblemReportsTagging should tag reports as Stack Smashes, double-free()s, and Heap Corruption.
The database of AutomatedProblemReports should preferably give some feedback on situations which are of potential security importance.
In addition, the tool for AutomatedProblemReportsNotification should display a security-related icon when a vulnerability is suspected.
- Should look somewhat vicious, perhaps in a red circle, with an '!' incorporated
- Maybe a picture of a lock, maybe broken in half
- We may want to pop a balloon up for this one that says, "Possible security vulnerability detected, click here for more information," when automatic reporting is off
- For that matter we may want to do this even when automatic reporting is on, but this has implications. It's going to get more end-users submitting the sensitive bits of the report if we draw their attention to it; but at the same time, it's going to annoy more end users.
- Should probably allow users to have specifically suspected security vulnerabilities automatically reported even if they don't report everything
Implementation
Will need to create an icon for AutomatedProblemReportsNotification and have it display as appropriate.
Code
Code will be needed in the areas described in Implementation.
Data preservation and migration
No issues exist.
Unresolved issues