Slammer: Why security benefits from proof of concept code

[InfoSec News <isn () c4i org>]

http://www.theregister.co.uk/content/55/29195.html

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
code.

Was this helpful to the unknown criminal or criminals who created
Slammer?

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
soul-searching.

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
swiftly.

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 majordomo () attrition org with 'unsubscribe isn'
in the BODY of the mail.