Positive Outcomes from Zero Days

In March 2017 the RAND Corporation released a report “Zero Days, Thousands of Nights: The Life and Times of Zero-Day Vulnerabilities and Their Exploits”. The goal was to assess the public policy of governments stockpiling or releasing so-called 0-day exploits. While that remains an open question, the report and underlying data set of real-world exploits provides valuable insights into software engineering for security and resilience. This talk will provide an overview of the report and what it means for builders and defenders.

1. Positive Outcomes from Zero Days Insights into Software Engineering from the RAND Corporation RR1751 Report Nick Galbreath ✼ CTO/Founder Signal Sciences ✼ nickg@signalsciences.com
2. In March 2017 the RAND Corporation released a report “Zero Days, Thousands of Nights: The Life and Times of Zero-Day Vulnerabilities and Their Exploits”. The goal was to assess the public policy of governments stockpiling or releasing so-called 0-day exploits. While that remains an open question, the report and underlying data set of real-world exploits provides valuable insights into software engineering for security and resilience. This talk will provide an overview of the report and what it means for builders and defenders.
3. Citation Ablon, Lillian and Timothy Bogart, Zero Days, Thousands of Nights: The Life and Times of Zero-Day Vulnerabilities and Their Exploits, Santa Monica, Calif.: RAND Corporation, RR-1751-RC, 2017. As of June 20, 2017: https://www.rand.org/pubs/research_reports/RR1751.html
4. Just to be clear... There is no connection or association between Signal Sciences/Nick Galbreath and RAND Corporation. RAND Corporation has not reviewed or approved this presentation.
5. Outline • What is RAND Corporation? • What is RR1751 and what is its goal? • What is the data? • What can we say about software engineering and security from it? • Final conclusions and questions
6. Rand Corporation, Santa Monica
7. 0day “Zero-day vulnerabilities are software vulnerabilities for which no patch or fix has been publicly released. The term zero-day refers to the number of days a software vendor has known about the vulnerability” True, but context often matters
8. What question is the report answering? Should the (US) government hoard or release 0days? • If lifetime short or easily found then maybe release to make sure your systems are patched before others attack. • If lifetime long or rarely rediscovered then maybe hoard, since there is low defensive risk. I'm not the guy to comment on ethics or public policy of zero-days.
9. Data Source Code named “BUSBY” develops, markets, and sells zero-days and provided access to their historical and current 0day supply. “Some BUSBY researchers have worked for nation-states (so their skill level and methodology rival that of nation-state teams), and many of BUSBY’s products are used by nation-states.”
10. These 0days • These aren’t just 0days • They are productionalized “weaponized” 0days • That are sold and used.
11. The 0day Data Set • ~ 235 actual 0-days from 2002 to 2016 • 20 - 30 redacted (hmmmm) • 207 exploits in data set • Lots of metadata: date created, length of development, when died, etc. (this is better than most internal bug tracking)
12. • n=207 is not a lot over 14 years • The data set is not public (duh). • Source is mysterious. • Data only summaries/grouped only in one dimension. We have data on platform, and data on flaw, but not by platform, by flaw, etc. Assume this is done for privacy reasons. Data Size and Transparency
13. Vendors and Platforms: Everything Vendors: • Microsoft: 55 • Linux: 39 • Apple: 14 64 Total Vendors Platforms: • Windows: 93 • Linux: 56 • “Open Source”: 16 • OS X: 18 • PHP: 11
14. What is the exploit? Logic: 28% vs Memory: 72% C/C++ applications or libraries? Applications, biz logic?
15. Good News, Bad News on Memory • Improvements in compiler and kernel tech has more or less stopped stack based exploits • Unfortunately it has not stopped or slowed down heap-based exploits so total rate of discovery has not changed.
16. Logic Vulnerabilities • API misuse • Auth bypass • Auto execution • Command Execution • Directory traversal • DNS • Environment var insertion • File normalization • File permissions • Sqli or other injection • Leak • Hardcored password • Serialization 25% of these were “race conditions” No real trends with everything else. This smells a lot like application code.
17. How Long Do They Live? A graph would help! • 25% die in a year • 25% die after 10 years • Average is 7 years! No correlation on lifetime with any other characteristic.
18. Death 33% of data were killed off by patches 10% were killed off by (unintentional?) code refactoring in newer versions. but..
19. Code Churn Kills 0days “...we do have qualitative assessments from several vulnerability researchers and individuals with whom we spoke. They said the majority of their exploits die (i.e., their vulnerabilities became known) due to code churn and, less commonly, to independent rediscovery by a vulnerability researcher performing a code audit. “ (page 33)
20. Life • 32% alive and working • 3% of exploits are “public” but not patched, no CVE • 6% are immortal: product is obsolete but exploit works and will never be patched (not clear if found before or after EOL).
21. Close Collisions 12% of exploits had or are involved with “close collisions”. A patch was made, but didn’t fix the whole problem, fixed something close to problem, or exposed new problems. Strongly suspect these are memory vulnerabilities vs logic, but have no evidence.
22. On Vulnerabilities and CVE • Vulnerability sometimes patched without CVE • CVE may understate vulnerability • Some vulnerabilities still alive, publically disclosed, but no CVE, no patch. • CVE patches sometimes are shallow (close collisions) • Patched CVEs can be reopened if new architecture. (not mentioned in report but huge backlog in reporting CVE).
23. True Statements, And What To Do About it
24. Everything is in scope Reduce how big “everything” is. Simplify, standardize, reduce, turn-off, remove unneeded systems, libraries, packages, services. I know, I know, easier said than done.
25. 0days Exist And Will Continue To Exist While you can minimize risk, you can’t eliminate it. Monitoring and breach detection are critical.
26. Immortal 0days Exist Stop using EOL products. They aren’t overlooked.
27. EOL • CentOS 5 (CentOS 6 EOL in 2020) • Ubuntu 12.04 • Nodejs 0.10, 0.12 (4.X EOL in Apr 2018) • Ruby 1.8, 1.9, 2.0, 2.1 (2.2 EOL in Mar 2018) • Java 5,6,7 all EOL, Java 8 unclear. • Python 2.7 EOL in 2020 OS vendors will support some of this, but...
28. Strategies of • patch only if CVE • patch only if severe CVE • patch only if CVE applies (cherry pick) do not do what you think they do. Always stay at patch level provided by your OS vendor The CVE System is Imperfect
29. The Majority of 0day and CVEs are from C/C++ code • Stop the bleeding • Can you reduce exposure? • Start investigation and strategy for alternatives
30. Further Conclusions
31. Use the Latest OS • And make it easy and common to update. • Compiler and kernel improvements are real. • Effects of latest improvements likely not reflected in report.
32. Build Your Own Servers and Languages • And track upstream releases. • Faster (OS versions are not optimized well) • More secure (latest compiler tech) • Less surface area (OS versions are very broad) • More code churn, more killed 0days. • More patches (unreported vulns fixed). • Oh yeah, your devs will be happier too.
33. Faster, more updates = more secure. Yes, there is stability and operational cost tradeoff. Have a discussion on risk!
34. Does this sound like Continuous Deployment? But instead of apps it’s for OS Platforms? YES!
35. Security is DevOps. DevOps is Security. We need you to get involved.
36. nickg@signalsciences.com @NGalbreath