Re: Call to arms - INFORMATION ANARCHY

From: Arne Vidstrom (arne.vidstrom@NTSECURITY.NU)
Date: 11/03/01 

Message-ID:  <NLECJAEFKPPNCLPPMHLPOEFOCIAA.arne.vidstrom@ntsecurity.nu>
Date:         Sat, 3 Nov 2001 03:17:56 +0100
From: Arne Vidstrom <arne.vidstrom@NTSECURITY.NU>
Subject:      Re: Call to arms - INFORMATION ANARCHY
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM

The central question in all of this is: Where do we draw the line?

On the one hand we have some people who publish complete exploit details way
too soon after notifying the vendor. We also have those (for example a
particular "immature and childish company") who release exploits that are
designed to help malicious attackers break into systems when harmless
proof-of-concept exploits are enough. On the other hand we have some vendors
who would definately not fix their holes at all if they weren't forced to by
the bug finders. Most intelligent humans will understand that both sides are
equally wrong.

Since the first posting was about Scott Culp's paper I ask myself if he is
wrong too.

SC about "information anarchy": "This is the practice of deliberately
publishing explicit, step-by-step instructions for exploiting security
vulnerabilities, without regard for how the information may be used."

I think this definition is way to wide. If this isn't allowed there is no
way to for example learn penetration testing because you have nowhere to
learn from. Oh, of course you could find out everything for yourself which
will take some 100 years or so. Or you could just buy a security scanner and
not care about how it works. At least some of us know how well that works...
Of course those who code that scanner will have to learn some way - perhaps
buy the vulnerability details from Microsoft? :-)

SC: "The relationship between information anarchy and the recent spate of
worms is undeniable. Every one of these worms exploited vulnerabilities for
which step-by-step exploit instructions had been widely published. But the
evidence is more far conclusive than that. Not only do the worms exploit the
same vulnerabilities, they do so using the same techniques as were
published - in some cases even going so far as to use the same file names
and identical exploit code. This is not a coincidence. Clearly, the
publication of exploit details about the vulnerabilities contributed to
their use as weapons."

Of course the malicious people use published exploits - malicious people
tend to care more about the impact than about the challenge to create things
from scratch themselves. They take the easiest path. Let's say that you take
away the step-by-step exploit instructions. Then you have to assume that no
malicious person is capable of finding them out, and that no malicious
person get them from a non-malicious person who find them out. Let's also
say that you let some licensed security professionals have access to them -
this will be quite a large number of people worldwide. Do you really think
that things like these will not leak from that crowd? Perhaps the easiest
path is to buy the code from one of these professionals. Or that one of the
professionals wants his/her blackhat friends to think he/she is cool and
gives away the details. One leak is enough.

SC: "Ending information anarchy will not end the threat of worms. Ethics and
intelligence aren’t a package deal, and some of the malicious people who
write worms are quite smart. Even in the best of conditions, it will still
be possible to write worms. But the state of affairs today allows even
relative novices to build highly destructive malware. It’s simply
indefensible for the security community to continue arming cybercriminals.
We can at least raise the bar."

That line of reasoning seems familiar. Oh, now I remember - Steve Gibson and
raw sockets. It's interesting to see how opinions can change depending on
what side you are on for the moment. :-) (Please note that I don't agree
with *anything* that Gibson say, no matter which side I'm on.)

SC: "In other cases, the specifics of the vulnerability make it impossible
to limit how the tool could be used - but in cases like these, a decent
regard for the well-being of the user community suggests that it would
better to not build the tool than to release it and see it misused."

This is another thing I don't agree with. If it's impossible to publish
detailed information without giving away the complete instructions to
maliciously attack systems I would publish the information anyway. I think
this is a question about where you are, where you come from and where you're
going. Let me explain. Scott Culp and the other security people at Microsoft
will get the full details all the time (unless the bad guys don't give them
the stuff at all, which will probably happen more often without full
disclosure). Most likely the large security companies will get the full
details. If you have enough money you can most likely *buy* the details. But
what if you're not friends with the "big boys"? What if you don't have
enough money? For example, I have learned about security on my own hand. I
bought books, I read a lot of web pages, I subscribed to NTBugtraq and
Bugtraq. What if all the information available to the public had been
"install these 100 patches from MS and don't think more about it"? Maybe to
Scott Culp and many others this isn't a big issue, but to me it is. And I
know it is to a lot of other people too.

As for hellNbak's suggestion to release all those vulnerabilities we've been
sitting on, I think those who keep things like that to themselves are
definitely on the wrong side of the line. Period.

And as for where to draw the line. I don't think there is a fixed line
between right and wrong, but there are at least a few things to think about:

* If you do release vulnerability details / exploit code, don't release more
than is needed to test if the vulnerability is present, and what is needed
for people to learn not do similar mistakes in their own code, and learn
security in general. For example there is no need to release a buffer
overflow exploit that let's the attacker telnet into the target when you
could just send back "attack succeeded" instead.

* Don't release *anything* before there is a patch or workaround present.
(Unless there for some reason never will be one at all.)

* If you are a vendor, let all of your customers know immediately when you
have released a patch or a new release with security fixes in it. Don't
expect them to click 50 links down on your web site to find out themselves.

And last but not least. Remember that what is right and what is wrong
depends on which side you are on, and there are many sides when you consider
all dimensions of complex problems.

/Arne Vidstrom

Relevant Pages