[ISN] Slammer: Why security benefits from proof of concept code

From: InfoSec News (isnat_private)
Date: Wed Feb 05 2003 - 22:22:31 PST

  • Next message: InfoSec News: "[ISN] REVIEW: "Advanced CISSP Prep Guide: Exam Q & A", Ronald L. Krutz/Russell Dean Vines"

    By John Leyden
    Posted: 05/02/2003
    The UK security expert who discovered the flaw which was exploited by
    the Slammer worm has concluded it does more good than harm to publish
    proof of concept code.
    In a posting to BugTraq, David Litchfield of NGSSoftware expressed
    concerns that his proof of concept code was used as a template by
    unknown vandals in creating the destructive Slammer worm.
    The Slammer Worm uses SQL Server Resolution service buffer overflow
    flaw, discovered by NGSSoftware, and patched by MS last July.
    In August last year, Litchfield made a presentation on the issue at
    the Black Hat conference in Las Vegas that featured a demonstration of
    proof of concept code. At the time, Litchfield warned of the DDoS
    potential of the flaw and urged admins to patch their systems.
    The following month, NGSSoftware published a white paper on auditing
    SQL Server which contained an explanation of its proof of concept
    Was this helpful to the unknown criminal or criminals who created
    Litchfield thinks the information only helped save time in writing the
    code. The virus authors were skilled and were quite capable of writing
    Slammer even without NGSSoftware's work to build on, he reckons.
    "Whoever authored the worm knew how to write buffer overflow exploits
    and would have been capable of doing this without using my shellcode
    as a template," Litchfield writes. "Having access to my code probably
    saved them around 20 or so minutes - but they still would have been
    able to do it without mine".
    Access all areas
    The chaos which unfolded last weekend after the release of the Slammer
    worm has re-ignited the debate on full disclosure of security
    vulnerabilities. It has also prompted Litchfield into a bout of
    But he still concludes that the publication of proof of concept code
    has a beneficial role to play in Internet security.
    So NGSSoftware will continue to provide full disclosure on the
    security issues it unearths, he told us.
    Here is Litchfield's explanation for this decision:
    After careful consideration I've decided that the publication of proof
    of concept code does have an important and beneficial role to play in
    Internet security.
    This decision was not made lightly and has been influenced by
    conversations with my colleagues at NGSSoftware, friends and peers in
    the industry and the many mails I received in response to my original
    mail to the Securityfocus Bugtraq list.
    As far as those responses go not a single one suggested that I, or
    NGSSoftware, cease to provide proof of concept code for the
    vulnerabilities we find and most gave salient reasons as to why we
    should continue to do so.
    This message is to explain why NGSSoftware will continue with full
    disclosure of issues.
    The threats and risks Internet connected systems are exposed to are
    well known. Connect an unpatched system to the Internet and it will be
    compromised by a worm or hacker within minutes.
    There are people out there with high levels of intelligence
    developing, sharing and actively using exploits against such systems.  
    Some do it for the fun of it, others as they see it as a challenge and
    still others who try to gain from it - whether financially or through
    peer recognition.
    Regardless of motive, there is much to be learnt from these people and
    their exploits. But if this was the only source of information for
    those working in the security industry then the "bad guys" would
    always be one step ahead of the "good guys"; and if they're one step
    ahead we lose and so do the organizations we're trying to protect.
    It is imperative, therefore, that we derive and make available to
    everyone our own source of information. If we can find the bugs still
    waiting to be discovered before the "bad guys" we can then alert the
    vendor to the problem and get a fix out, hopefully giving people a
    chance to get there systems patched.
    Here in lies one of the greatest ironies of such research.
    Imagine NGSSoftware discover a bug and choose not to alert the vendor
    but keep the bug secret.
    Who is to say whether those in the underground would ever find the
    bug? The vulnerability could lie undetected for the whole shelf life
    of the vulnerable product.
    No-one would know a thing save for NGSSoftware. But then what happens
    if someone else did discover the problem and happily went around
    popping boxes on the Internet, or worse, wrote and released damaging
    worm. In the absence of a patch there would be mayhem.
    So as an industry we must err on the side of caution and alert the
    vendor and get them to produce a patch. But in doing this the world at
    large is alerted to a new bug in the product.
    Had NGSSoftware kept the hole to itself though it could have been that
    noone would have ever known.
    We end up in a Catch-22 situation.
    This has still not justified the publication of a full disclosure
    advisory, though, with in-depth details and a proper dissection of the
    vulnerability in question.
    When a patch has been made available to the public someone who knows
    their way around computers will be able to compare the patched program
    and the vulnerable program and spot the differences within minutes -
    isolating the vulnerable bit of code. A couple of minutes later, and
    with the use of tools such as debuggers, they'll be able to work out
    exactly how the program is vulnerable and code up an exploit to take
    advantage of it. This can all be done without any information other
    than 1)There is a bug and 2) a copy of the new program and a copy of
    the old program.
    Such people, and there are thousands of them, do not need proof of
    concept code or advisories so even in their absence exploits, worms
    and virii will still be written and used.
    So in the interests of "levelling the playing field" it is necessary
    to publish full details. With these details companies that produce
    Intrusion Detection/Prevention Devices can update their products more
    Administrators can take steps to modify their firewalls' rule bases to
    protect their network. Developers of security assessment scanners can
    add new checks to their products so their users can scan their
    networks to see if they are vulnerable.
    Finally there is the educational value in publishing full details with
    proof of concept source code.
    If I say to a software developer, "Don't code that way. It's
    dangerous." they'll probably shrug it off. If I say to a developer,
    "Don't code that way. It's dangerous and here's why" and then proceed
    to demonstrate exactly why it's dangerous (their eyes often widen) and
    they take it on board. They immediately see the threat it poses. So
    through education developers can learn from others' mistakes.
    Often CXOs are blind to security issues and it is only when their
    network administrator proves to them the severity, with the use of
    proof of concept code, that they understand the impact a vulnerability
    can have to the business and organizations. [7 of the responses I
    received to my original posting stated that at some point in the past
    they've use proof of concept code to get better budgets to enable them
    to do their job more effectively.]
    Lastly there is education of the new comers to the security industry.
    Clients expect the very best from their security professionals - and
    to give their best security pros need to know the current state of
    security affairs. Only through education and diligent learning can
    this be achieved. Without the publication of proof of concept code and
    vulnerability details this educational gain would be lost - and this
    in the long run would have a negative impact upon the state of
    computer and Internet security.
    External Links:
    1. http://www.robertgraham.com/journal/030126-sqlslammer.html
    2. http://www.cert.org/advisories/CA-2003-04.html
    3. http://www.sqlsecurity.com/DesktopDefault.aspx?tabindex=10&tabid=13
    4. http://www.silicondefense.com/research/sapphire/
    5. http://www.nextgenss.com/advisories/mssql-udp.txt
    ISN is currently hosted by Attrition.org
    To unsubscribe email majordomoat_private with 'unsubscribe isn'
    in the BODY of the mail.

    This archive was generated by hypermail 2b30 : Thu Feb 06 2003 - 01:33:42 PST