RE: Open Response To Microsoft Security - RE: It's Time to End Information Anarchy

From: Don Weber (
Date: 10/18/01

From: "Don Weber" <>
To: "Steve" <>, <>
Subject: RE: Open Response To Microsoft Security - RE: It's Time to End Information Anarchy
Date: Thu, 18 Oct 2001 10:46:01 -0700
Message-ID: <>

after reading the "0-day i hear $1000?", I would tend to think
it would be reasonable for at least the major vendors to give rewards for
people finding vulnerabilities in a product, considering, those same vendors
have spent lots of money alpha/bet testing the product, still not finding
the same vuln's, when a vuln is found by person x, company ABC should put
say 25000$ in a trust fund which has a panel of lets say 20 judges from the
security industry, then after money is confirmed deposited to fund, hacker
tells company what the problem is, company writes/releases patch, panel of
Judges then read the reports on do whatever testing they themselves think
necessary, and as a result vote on how much of the 25k is awarded to the
person that found the hole, based on what they think the repurcussions could
have been if company had NOT been advised, this would possibly force the
companies to either work harder on the product instead of release and hope
for the best, and could even give those less than desirable hackers (for
lack of a better term) an incentive to do a "good" thing with what they have
found rather than use the Xploit for mischevious purposes, alot of them,
white/black/green hats alike would much rather turn over what they have
found if they blv they have a chance at 25k as opposed to responses along
the lines of yeah right, that's dangerous we'll look into it, or oh, great
thanks, and of course the cases where hacker x notifies company a company a
entirely disregards the notification, and finally hacker x releases teh vuln
to bugtraq or the like then vendor a flames hacker x for doijng so, claiming
they either wasn't notified or given enough time. of course the reward
program wouldn't have to be limited to only large companies, and the amount
of any reward should have some impact on the finances of the company, and
possibly some relationship to the total revenue which that product brought
to the company over some period of time, there are a number of possibilities
that could be used in determining the amount of the reward fund.

just my 0.02
hope this got into the right thread


-----Original Message-----
From: Steve []
Sent: Wednesday, October 17, 2001 7:56 PM
Subject: Open Response To Microsoft Security - RE: It's Time to End
Information Anarchy

Hash: SHA1

Moderators -- I know the open/full disclosure debate has been kicked
numerous times, but I think this one is worth putting through. It is in
response to the following:

>It's Time to End Information Anarchy

It's time to end insecure coding practices and insecure systems

>Code Red. Lion. Sadmind. Ramen. Nimda. In the past year, computer worms
>with these names have attacked computer networks around the world,
>causing billions of dollars of damage. They paralyzed computer
>networks, destroyed data, and in some cases left infected computers
>vulnerable to future attacks. The people who wrote them have been
>rightly condemned as criminals. But they needed help to devastate our
>networks. And we in the security community gave it to

Worms and virus' have been created long before "security research" was
fashionable. Code Red, Nimda and a few of the more recent worms were
made possible not by the research that discovered the vulnerability they
exploited but by the lack of awareness and training by system
administrators who did not patch their systems.

>It's high time the security community stopped providing blueprints for
>building these weapons. And it's high time computer users insisted
>that the security community live up to its obligation to protect them.
>We can and should discuss security vulnerabilities, but we should be
>smart, prudent, and responsible in the way we do

Working with vendors to release a patch/fix is the responsible thing to
do. That being said, in the past vendors have had to be literally
forced to release a patch with the threat of proof of concept code.
If a proper security aware culture is promoted within the certification
processes and by all vendors, the release of exploit code along with a
patch would be trivial as system administrators would patch critical
systems. This is of course assuming that the patch is properly tested
and actually works. Without the existence of exploit code, how do we
ensure that the patches actually work?
Trust our vendor? I don't think so, vendors have proven that they bow
to stock price and the so called market pressure and will continue to do
this over and above security needs. Multiple vendors, not just
Microsoft, have also proved that they will not completely research the
issue themselves and release insufficient patches.

>First, let's state the obvious. All of these worms made use of security
>flaws in the systems they attacked, and if there hadn't been security
>vulnerabilities in WindowsR, Linux, and SolarisR, none of them could
>have been written. This is a true statement, but it doesn't bring us
>any closer to a solution. While the industry can and should deliver
>more secure products, it's unrealistic to expect that we will ever
>achieve perfection. All non-trivial software contains bugs, and modern

>software systems are anything but trivial. Indeed, they are among the
>most complex things humanity has ever developed. Security
>vulnerabilities are here to stay.

Correct, if there were no flaws in the operating systems the worms would
not exist. But, on the other hand, if system administrators are
properly trained and security aware the worms may have existed but they
would have failed. If a security issue is discussed in the public,
someone somewhere will be able to extrapolate enough information to
generate exploit code. Consulting organizations create exploit code,
scary underground hacking groups do it -- so why not as a security
researcher do it? Regardless, if a vulnerability is discussed in an
open format, the exploit code will be created.

Not discussing vulnerability information is not an option either.
The best option is to have secure software, in absence of secure
software, we need proper patch management and proper training. If you
look at the MCSE training programs of the past (NT 3.51, early 4.0 days)
you can literally count the number of times the work security is
mentioned on one hand. To me this is what makes worms like Code Red

>If we can't eliminate all security vulnerabilities, then it becomes all
>the more critical that we handle them carefully and responsibly when
>they're found. Yet much of the security community handles them in a way

>that fairly guarantees their use, by following a practice that's best
>described as 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 hate to repeat myself, but it is impossible to discuss a vulnerability
without giving enough information that would allow someone else to
re-discover the problem and use it. How useful are advisories or
vulnerability discussions that say: "There is an issue in Win2K that
will allow me to execute commands in system context remotely. We
recommend that you disable the spooler service or install this patch"
there is no valuable information for someone who wants to understand a
problem in these types of discussions. Those who do not wish to
understand the problems are, in my opinion naive and should not be
giving their vendor complete trust and control over their systems.

Look at the flack Novell recently received over their release of the
Padlock patch. They released a patch, with no information just an
urgent message to install it at once. Who in their right mind would
install this without asking questions?

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

Yes, but not only was step by step vulnerability information published,
but step by step patch information was published to even more sources
than the vulnerability information was.

>Providing a recipe for exploiting a vulnerability doesn't aid
>administrators in protecting their networks. In the vast majority of
>cases, the only way to protect against a security vulnerability is to
>apply a fix that changes the system behavior and eliminates the
>vulnerability; in other cases, systems can be protected through
>administrative procedures. But regardless of whether the remediation
>takes the form of a patch or a workaround, an administrator doesn't
>need to know how a vulnerability works in order to understand how to
>protect against it, any more than a
>person needs to know how to cause headache in order to take an

But what about the patches that don't work? Or the ones that cause
additional problems? Without the ability to test a system after it has
been patched system administrators are defenseless. It isn't
Information Anarchy, it is common sense that you test a system to be
110% sure that it is patched. You are right, I don't need to know what
causes a headache to take an aspirin, but I do need to know that the
aspirin will work.

>Likewise, if information anarchy is intended to spur users into
>defending their systems, the worms themselves conclusively show that
>it fails to do this. Long before the worms were built, vendors had
>delivered security patches that eliminated the vulnerabilities. In
>some cases, the fixes were available in multiple forms - singleton
>patches, cumulative patches, service packs, and so forth - as much as
>a year in advance. Yet when these worms tore through the user
>community, it was clear that few people had applied these fixes.

Who is to blame for this? Patches are not installed because system
administrators are not taught the importance of it. Instead they are
told that the patch is not regression tested and that they should wait
for a proper service pack.

>Finally, information anarchy threatens to undo much of the progress
>made in recent years with regard to encouraging vendors to openly
>address security vulnerabilities. At the end of the day, a vendor's
>paramount responsibility is to its customers, not to a self-described
>security community. If openly addressing vulnerabilities inevitably
>leads to those vulnerabilities being exploited, vendors will have no
>choice but to find other ways to
>protect their customers.

It is "Information Anarchy" as you put it that has forced vendors to
begin addressing security issues. I have said many times that Microsoft
as an organization has done a lot to address security issues compared to
that past, but there is still a way to go and Microsoft is not the only
vendor out there generating insecure software. There are still multiple
vendors in this day and age that would rather ignore security issues
than spend the money to fix them.

>This is not a call to stop discussing vulnerabilities. Instead, it is a
>call for security professionals to draw a line beyond which we
>recognize that we are simply putting other people at risk. By analogy,
>this isn't a call for people for give up freedom of speech; only that
>they stop yelling "fire" in a crowded movie house.

Repeating myself once again, there is no way that a vulnerability can be
discussed properly without letting enough information out that would
allow someone else to discover the issue. Merely saying that there is
an issue with a specific service will cause multiple people and groups
to begin looking at that service to find the issue.
"Fire" needs to be yelled when there is a fire.

>Some security professionals go the extra mile and develop tools that
>assist users in diagnosing their systems and determining whether they
>are affected by a particular vulnerability. This too can be done
>responsibly. In many cases, it's possible to build a tool that
>performs non-destructive testing and can only be used by a legitimate
>system administrator. 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.

A tool that "non-destructively" tests for a vulnerability can be easily
re-engineered to exploit the vulnerability. Not building the tools
means that everyone should trust that the patch does what it is supposed
to do. Lets look at the extreme of this, a malicious user manages to
find his way into a patch repository of a vendor. This user replaces
working patches with ones that do nothing. The system administrator
does his duty and installs the patches. This admin has no way of
knowing that the patch actually does nothing or worse -- backdoors his
system further. You cannot tell me that there have been no incidents
were a software vendor has been compromised and you cannot guarantee
that there never will be again.

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

I agree with this comment. Right now we have nothing but a bunch of
low-skilled script kiddies using tools that are pre-made for them.
Hell, some of them even use the commercial vulnerability scanners as
their tool.

But, not releasing complete vulnerability information will not stop the
more skilled people. It is unfortunate, but there is a large group of
very skilled people who would love to do nothing more than code their
own exploits and release them to the lower skilled population. There is
nothing we can do to stop this, so why not try and capitalize off of it
by learning from the code and even creating our own that we can easily
footprint. By forcing this information into closed room discussions, we
are blinding security managers who, because of the open discussion and
tool repositories, know exactly what footprints the various exploits
leave and know exactly what to tune their log watching or IDS' for.

>This issue is larger than just the security community. All computer
>users have a stake in this issue, and all of us can help ensure that
>vulnerabilities are handled responsibly. Companies can adopt corporate
>policies regarding how their IT departments will handle any security
>vulnerabilities they find. Customers who are considering hiring
>security consultants can ask them what their policies are regarding
>information anarchy, and make an informed buying decision based on the

>answer. And security professionals
>only need to exercise some self-restraint.

I agree with working with the vendor. There only valid reason for
releasing proof of concept code is a vendor that does not cooperate.
But, without the threat of this, many vendors can simply ignore
important issues.

>For its part, Microsoft will be working with other industry leaders
>over the course of the coming months, to build an industry-wide
>consensus on this issue. We'll provide additional information as this
>effort moves forward, and will ask for our customers' support in
>encouraging its adoption. It's time for the security community to get
>on the right side of this issue.

I look forward to this process and hope that I am involved in some way.


Steve Manzuik
Moderator - VulnWatch

Version: PGPfreeware 7.0.3 for non-commercial use <>


Relevant Pages

  • Re: [Full-Disclosure] RE: Disclosure policy in Re: RealPlayer vulnerabilities
    ... you wrote that I do not really believe in "full disclosure" ... Vulnerability is discovered and the vendor is notified. ... I am not talking about the absolute security. ... you say that vendors must work much harder at reducing patch ...
  • Re: [Full-Disclosure] Microsoft Cries Wolf ( again )
    ... response to your posting here, seem to be a point of taking potshots at ... the vendors products. ... > administrators of security issues. ... > security vulnerabilities, most of it is not valid. ...
  • SecurityFocus Microsoft Newsletter #165
    ... Tenable Security ... distribute, manage, and communicate vulnerability and intrusion detection ... Microsoft Internet Explorer MHTML Forced File Execution Vuln... ...
  • SecurityFocus Microsoft Newsletter #174
    ... This issue sponsored by: Tenable Network Security ... the worlds only 100% passive vulnerability ... MICROSOFT VULNERABILITY SUMMARY ... Novell Netware Enterprise Web Server Multiple Vulnerabilitie... ...
  • [EXPL] Exploit Code Released for MFC ISAPI Framework Buffer Overflow (BadBlue PWS)
    ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: ... The vulnerability itself lies in the way MFC's ISAPI ... Resources' BadBlue PWS. ... Response Center within minutes of this e-mail from the ...