## page was renamed from AutomatedSecurityVulnerabilityDetection ## page was renamed from GccSspSecurityHoleReporting ## page was renamed from GccSspEnhancements ##(see the SpecSpec for an explanation) * '''Launchpad entry''': https://launchpad.net/distros/ubuntu/+spec/automated-problem-reports-tagging-for-security * '''Created''': <> 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 == == BoF agenda and discussion == ---- CategorySpec