Disclosure Samsara

Disclosure Samsara or "The Endless Responsible Vulnerability Disclosure Debate" (presented at NAISG and OWASP Boston, 2009)

Transcript

1. Disclosure Samsara or “The Endless Responsible Vulnerability Disclosure Debate”
2. Disclaimer Side effects of this presentation may include: anger; giddiness; joy; introspection and navel gazing; debate; yelling; nausea and hallucination; patting me on the back; or punching me in the face
3. “Long is the night to the wakeful, long is the league to one who is exhausted. Long is samsara1 for the foolish who do not know saddhamma2.”
   -from the Dhammapada
   1 Endless cycle of suffering caused by birth and death
 2 The highest truth
4. Quick “about me” I’m Zach Lanier and I'm... • a hacker • a security consultant/researcher • co-founder of Midnight Research Labs Boston • manager of the Security Twits list
5. Agenda Foundations WWYD? A dose of truth “Ancient” and Modern History Current challenges Nirvana(-ish)
6. Foundations Full disclosure Revealing all details of a security weakness, flaw, or vulnerability Pro: More information for workarounds; can pressure vendors/providers; public scrutiny Con: Quicker time to exploit development; 0-day buffet!
7. Foundations Partial disclosure Revealing only details that are deemed relevant (minimal disclosure?) Pro: May reduce likelihood of exploit development; may increase time-to-publish Con: “Relevant” is totally subjective; may miss important details
8. Foundations Zero disclosure Revealing no (or almost no) details of a vulnerability; “security through obscurity” Pro: “Almost zero likelihood of exploit development” (well, it’ll probably happen anyway) Con: Less public scrutiny may reduce trust if/when disclosure does occur; “Many eyes make bugs shallow”
9. What Would You Do? PHOTO CC LICENSED FROM LEO REYNOLDS
10. You’re a software giant, known for your popular operating system. Late last night, an independent security researcher released exploit code for a previously unknown buffer overflow that leads to remote code execution. What Would You Do?
11. You visit the promotional website of a very popular beverage, wherein you can find local tasting events and participate in a forum for fellow connoisseurs. You discover that the whole site is riddled with SQL injection and cross-site scripting vulnerabilities. What Would You Do?
12. You’re a SaaS-based CRM provider. You help businesses succeed. You just received an email from a small security consultancy suggesting that they’ve discovered a privilege escalation bug in the web services API of your flagship application. What Would You Do?
13. A Dose of Truth PHOTO CC LICENSED FROM ANDRES RUEDA
14. Truth Vulnerability disclosure is... Sexy Helpful Ugly Loathed Destructive Appreciated Stupid Awesome Heroic Criminal Painful Pleasant Rewarded Penalized
15. Truth Vulnerability disclosure is... Sexy Helpful Ugly Loathed Destructive Appreciated Stupid Awesome Heroic Criminal Painful Pleasant Rewarded Penalized
16. Truth Vulnerability disclosure is... probably going to happen whether you like it or not, so let’s be smarter about handling it.
17. Truth Attacking researchers with gag orders, lawsuits, and other threats doesn’t stop research and it doesn’t stop vulnerability disclosure
18. Truth Vulnerability details generally yield corresponding exploits Vulnerability details help administrators and security pros craft workarounds Exploits help test the effectiveness of compensating controls
19. (Ancient) History Recognize this? PHOTO CC LICENSED FROM EASTBAYANT
20. (Ancient) History Multics information disclosure vulnerability -- reported in 1965 • “Accident” led to password file being displayed in the MOTD • From OSVDB vuln #23257: • Multics CTSS on IBM 7094 contains a flaw that may disclose the contents of the password file...when multiple instances of the system text editor were invoked, causing the editor to create temporary files with a constant name...cause the contents of the system CTSS password file to display to any user logging into the system.
21. (Modern) History Recognize these? PHOTO BORROWED FROM WIRED PHOTO CC LICENSED FROM VFLOCK.COM
22. (Modern) History Kryptonite bike lock vulnerability • Broken with a ballpoint pen • Video circulated in 2004 • Kryptonite knew 12 years earlier; did nothing. Medeco M3 vulnerabilities • Picking and “bumping” • Disclosed in 2008 by Mark Tobias
23. (Modern) History IMAGE BORROWED FROM ATTRITION.ORG -- I HOPE JERICHO DOESN’T FIND ME.
24. (Modern) History June 12, 2000: rain forest puppy publishes RFPolicy, forebear to modern responsible full disclosure. Current incarnation says: • Vendor/provider must respond within five (5) days, and maintain contact no less than every five (5) days • Researcher and vendor/provider can agree upon delayed disclosure • Five (5) days w/o initial response from vendor/provider -> full, public disclosure
25. (Modern) History October 2001: Microsoft Security Response Center manager, Steve Culp, makes statements suggesting that full disclosure is like “following a practice that's best described as information anarchy.” On the heels of eEye’s disclosure of a vulnerability that may have benefited Code Red and Nimda authors Community counters that eEye disclosed details at least one month before Code Red emerged
26. (Modern) History September 2003: Blackboard issues cease-and-desist to Interz0ne to stop Billy Hoffman and Virgil Griffith’s presentation on vulnerabilities July 2005: Michael Lynn plans to present on Cisco IOS vulnerabilities at BlackHat; threatened with lawsuit, investigated by the FBI August 2008: MIT students prepare to talk about MBTA vulnerabilities at DEFCON; gag order issued (later lifted)
27. (Modern) History September 7, 2009: Laurent Gaffié releases details regarding remotely exploitable vulnerability in the SRV2.SYS driver in Windows Vista, Windows Server 2008, and Windows 7 Vulnerability initially leads to Blue Screen of Death; as of September 17, remote code execution is possible Microsoft says Gaffié was irresponsible for not notifying them; Gaffié counters, saying MS was irresponsible for bad QA
28. Current Challenges BORROWED FROM...I DON’T EVEN REMEMBER WHERE. IMAGE BORROWED FROM TENABLE. I HOPE RANUM DOESN’T FIND ME, EITHER.
29. Current Challenges Black hats, white hats, gurus, and gawkers continue to say the same things: “Disclosure is evil!”
 “Disclosure is vital!”
 “Screw the vendor! Disclose all the way!”
 “Screw the industry! Keep vulnerabilities for yourself! This happens like clockwork, year in, year out.
30. Current Challenges We still can’t agree on disclosure timelines and details • 5 days? 30 days? 90 days? Partial? Full? Vulnerability details are worth money • ZDI, IDEFENSE VCP, black markets
31. Current Challenges Rapid emergence of and shift to web applications • What do you do when the vulnerability and exploit are one in the same? (Think SQLi and XSS.) Process control and SCADA vulnerabilities • These things often run critical infrastructure
32. Nirvana(-ish) PHOTO CC LICENSED FROM DUNECHASER
33. Nirvana(-ish) Let’s accept that vulnerabilities will get disclosed • Stop playing the “Bad researcher! Bad!” song Provide a facility for encouraging responsible disclosure Said facility would aim to give mutual benefit to research and vendor/provider
34. Nirvana(-ish) Key requirements: Facilitate (or mediate) interaction between researcher and vendor or service provider Acknowledges researcher's work Provide adequate (namely legal) protection for the security researcher
35. Nirvana(-ish) Give guidance for • crafting a sensible timeline and plan for a solution to the bug or flaw (and keep parties from stalling) • crafting a sensible timeline for public disclosure of the bug or flaw Document vendor-researcher interaction and disclosure process (for others to learn from)
36. References/Reading RFPolicy
 http://www.wiretrip.net/rfp/policy-simple.html Attrition.org Legal Threats page
 http://attrition.org/errata/legal_threats/ EFF “Gray Hat Guide”
 http://www.eff.org/issues/coders/grey-hat-guide EFF Coder’s Rights Project Vulnerability Reporting FAQ
 http://www.eff.org/issues/coders/vulnerability-reporting-faq Open Source Vulnerability Database
 http://osvdb.org/
37. Contact zach@n0where.org http://n0where.org/ http://boston.midnightresearch.com/ http://identi.ca/quine http://twitter.com/quine