{"id":962,"date":"2016-10-18T21:46:05","date_gmt":"2016-10-19T04:46:05","guid":{"rendered":"https:\/\/outflux.net\/blog\/?p=962"},"modified":"2016-10-20T16:02:54","modified_gmt":"2016-10-20T23:02:54","slug":"security-bug-lifetime","status":"publish","type":"post","link":"https:\/\/outflux.net\/blog\/archives\/2016\/10\/18\/security-bug-lifetime\/","title":{"rendered":"Security bug lifetime"},"content":{"rendered":"

In several of my recent presentations<\/a>, I’ve discussed the lifetime of security flaws in the Linux kernel. Jon Corbet did an analysis in 2010<\/a>, and found that security bugs appeared to have roughly a 5 year lifetime. As in, the flaw gets introduced in a Linux release, and then goes unnoticed by upstream developers until another release 5 years later, on average. I updated this research for 2011 through 2016, and used the Ubuntu Security Team’s CVE Tracker<\/a> to assist in the process. The Ubuntu kernel team already does the hard work of trying to identify when flaws were introduced in the kernel, so I didn’t have to re-do this for the 557 kernel CVEs since 2011.<\/p>\n

As the README<\/a> details, the raw CVE data is spread across the active\/<\/code>, retired\/<\/code>, and ignored\/<\/code> directories. By scanning through the CVE files to find any that contain the line “Patches_linux:”, I can extract the details on when a flaw was introduced and when it was fixed. For example CVE-2016-0728<\/a> shows:<\/p>\n

\r\nPatches_linux:\r\n break-fix: 3a50597de8635cd05133bd12c95681c82fe7b878 23567fd052a9abb6d67fe8e7a9ccdd9800a540f2\r\n<\/pre>\n
This means that CVE-2016-0728 is believed to have been introduced by commit 3a50597de8635cd05133bd12c95681c82fe7b878<\/a> and fixed by commit 23567fd052a9abb6d67fe8e7a9ccdd9800a540f2<\/a>. If there are multiple lines, then there may be multiple SHAs identified as contributing to the flaw or the fix. And a “-<\/code>” is just short-hand for the start of Linux git history<\/a>.<\/p>\n
Then for each SHA, I queried git to find its corresponding release, and made a mapping of release version to release date, wrote out the raw data<\/a>, and rendered graphs. Each vertical line shows a given CVE from when it was introduced to when it was fixed. Red is “Critical”, orange is “High”, blue is “Medium”, and black is “Low”:<\/p>\n
\"CVE<\/p>\n
And here it is zoomed in to just Critical and High:<\/p>\n
\"Critical<\/p>\n
The line in the middle is the date from which I started the CVE search (2011). The vertical axis is actually linear time, but it’s labeled with kernel releases (which are pretty regular). The numerical summary is:<\/p>\n