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

Disclosure Samsara

Zach Lanier
October 21, 2009

Disclosure Samsara

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

Zach Lanier

October 21, 2009
Tweet

More Decks by Zach Lanier

Other Decks in Research

Transcript

  1. Disclosure Samsara
    or “The Endless Responsible Vulnerability
    Disclosure Debate”

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  5. Agenda
    Foundations

    WWYD?

    A dose of truth

    “Ancient” and Modern History

    Current challenges

    Nirvana(-ish)

    View full-size slide

  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!

    View full-size slide

  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

    View full-size slide

  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”

    View full-size slide

  9. What Would
    You Do?
    PHOTO CC LICENSED FROM LEO REYNOLDS

    View full-size slide

  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?

    View full-size slide

  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?

    View full-size slide

  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?

    View full-size slide

  13. A Dose of
    Truth
    PHOTO CC LICENSED FROM ANDRES RUEDA

    View full-size slide

  14. Truth
    Vulnerability disclosure is...
    Sexy
    Helpful
    Ugly
    Loathed
    Destructive
    Appreciated
    Stupid
    Awesome
    Heroic
    Criminal
    Painful
    Pleasant
    Rewarded
    Penalized

    View full-size slide

  15. Truth
    Vulnerability disclosure is...
    Sexy
    Helpful
    Ugly
    Loathed
    Destructive
    Appreciated
    Stupid
    Awesome
    Heroic
    Criminal
    Painful
    Pleasant
    Rewarded
    Penalized

    View full-size slide

  16. Truth
    Vulnerability disclosure is...
    probably going to happen
    whether you like it or not,
    so let’s be smarter about
    handling it.

    View full-size slide

  17. Truth
    Attacking researchers with gag orders, lawsuits,
    and other threats doesn’t stop research and it
    doesn’t stop vulnerability disclosure

    View full-size slide

  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

    View full-size slide

  19. (Ancient) History
    Recognize this?
    PHOTO CC LICENSED FROM EASTBAYANT

    View full-size slide

  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.

    View full-size slide

  21. (Modern) History
    Recognize these?
    PHOTO BORROWED FROM WIRED PHOTO CC LICENSED FROM VFLOCK.COM

    View full-size slide

  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

    View full-size slide

  23. (Modern) History
    IMAGE BORROWED FROM ATTRITION.ORG -- I HOPE JERICHO DOESN’T FIND ME.

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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)

    View full-size slide

  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

    View full-size slide

  28. Current
    Challenges
    BORROWED FROM...I DON’T EVEN REMEMBER WHERE.
    IMAGE BORROWED FROM TENABLE. I HOPE RANUM DOESN’T FIND ME, EITHER.

    View full-size slide

  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.

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  32. Nirvana(-ish)
    PHOTO CC LICENSED FROM DUNECHASER

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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)

    View full-size slide

  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/

    View full-size slide

  37. Contact
    [email protected]

    http://n0where.org/

    http://boston.midnightresearch.com/

    http://identi.ca/quine

    http://twitter.com/quine

    View full-size slide