Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Disclosure Samsara

C65347082fd2c5ec7c783f214e2d49e0?s=47 Zach Lanier
October 21, 2009

Disclosure Samsara

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

C65347082fd2c5ec7c783f214e2d49e0?s=128

Zach Lanier

October 21, 2009
Tweet

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