291 lines
13 KiB
Plaintext
291 lines
13 KiB
Plaintext
From fork-admin@xent.com Mon Aug 26 22:18:18 2002
|
|
Return-Path: <fork-admin@xent.com>
|
|
Delivered-To: yyyy@localhost.netnoteinc.com
|
|
Received: from localhost (localhost [127.0.0.1])
|
|
by phobos.labs.netnoteinc.com (Postfix) with ESMTP id 0D76343F99
|
|
for <jm@localhost>; Mon, 26 Aug 2002 17:18:17 -0400 (EDT)
|
|
Received: from phobos [127.0.0.1]
|
|
by localhost with IMAP (fetchmail-5.9.0)
|
|
for jm@localhost (single-drop); Mon, 26 Aug 2002 22:18:17 +0100 (IST)
|
|
Received: from xent.com ([64.161.22.236]) by dogma.slashnull.org
|
|
(8.11.6/8.11.6) with ESMTP id g7QLDMZ09780 for <jm@jmason.org>;
|
|
Mon, 26 Aug 2002 22:13:22 +0100
|
|
Received: from lair.xent.com (localhost [127.0.0.1]) by xent.com (Postfix)
|
|
with ESMTP id E08232941D6; Mon, 26 Aug 2002 13:39:05 -0700 (PDT)
|
|
Delivered-To: fork@example.com
|
|
Received: from seawall.homeport.org (Seawall.Homeport.org [66.152.246.82])
|
|
by xent.com (Postfix) with ESMTP id 503A5294099 for <fork@xent.com>;
|
|
Thu, 22 Aug 2002 07:06:28 -0700 (PDT)
|
|
Received: from lightship.internal.homeport.org
|
|
(lightship.internal.homeport.org [10.0.0.11]) by seawall.homeport.org
|
|
(Postfix) with ESMTP id 2FCE9568; Thu, 22 Aug 2002 11:07:55 -0400 (EDT)
|
|
Received: by lightship.internal.homeport.org (Postfix, from userid 125) id
|
|
372302C92B; Thu, 22 Aug 2002 10:08:09 -0400 (EDT)
|
|
From: Adam Shostack <adam@homeport.org>
|
|
To: Kragen Sitaker <kragen@pobox.com>
|
|
Cc: fork@example.com
|
|
Subject: Re: the underground software vulnerability marketplace and its
|
|
hazards (fwd)
|
|
Message-Id: <20020822100808.A72593@lightship.internal.homeport.org>
|
|
References: <Pine.LNX.4.33.0208220842040.8506-100000@hydrogen.leitl.org>
|
|
MIME-Version: 1.0
|
|
Content-Type: text/plain; charset=us-ascii
|
|
Content-Disposition: inline
|
|
User-Agent: Mutt/1.2.5.1i
|
|
In-Reply-To: <Pine.LNX.4.33.0208220842040.8506-100000@hydrogen.leitl.org>;
|
|
from eugen@leitl.org on Thu, Aug 22, 2002 at 08:42:12AM +0200
|
|
Sender: fork-admin@xent.com
|
|
Errors-To: fork-admin@xent.com
|
|
X-Beenthere: fork@example.com
|
|
X-Mailman-Version: 2.0.11
|
|
Precedence: bulk
|
|
List-Help: <mailto:fork-request@xent.com?subject=help>
|
|
List-Post: <mailto:fork@example.com>
|
|
List-Subscribe: <http://xent.com/mailman/listinfo/fork>, <mailto:fork-request@xent.com?subject=subscribe>
|
|
List-Id: Friends of Rohit Khare <fork.xent.com>
|
|
List-Unsubscribe: <http://xent.com/mailman/listinfo/fork>,
|
|
<mailto:fork-request@xent.com?subject=unsubscribe>
|
|
List-Archive: <http://xent.com/pipermail/fork/>
|
|
Date: Thu, 22 Aug 2002 10:08:09 -0400
|
|
X-Pyzor: Reported 0 times.
|
|
X-Spam-Status: No, hits=-9.4 required=7.0
|
|
tests=IN_REP_TO,KNOWN_MAILING_LIST,REFERENCES,
|
|
SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_03_05,USER_AGENT,
|
|
USER_AGENT_MUTT
|
|
version=2.40-cvs
|
|
X-Spam-Level:
|
|
|
|
Hi Kragen,
|
|
|
|
This is an interesting analysis. I think that there are a couple
|
|
of nits I might pick (for example, I don't expect that the market will
|
|
be well developed with highest bidders for while), I think that the
|
|
most important issue, which is that end users won't be able to fix
|
|
their systems, is almost passed over. I know that you know this, and
|
|
you allude to it, but your essay is getting passed around, so you
|
|
might want to add to it bits about the sysadmin and others.
|
|
|
|
There's one other point which you don't make, which I think is very
|
|
important, which is that research into defining and addressing classes
|
|
of vulnerabilities can't happen without libraries of available
|
|
vulnerability code. I can think of three researchers into automated
|
|
methods for addressing vulnerabilities who griped, uninvited, about
|
|
the quality of the existing vulnerability sites. Doing research into
|
|
a set requires that you have enough examples, in the open, that you
|
|
can define a set, and that the set is added to from time to time so
|
|
you can make and test predictions.
|
|
|
|
I feel fairly confident in saying that without full disclosure, we
|
|
wouldn't have Stackguard, ITS4, Nissus, or snort. And the security
|
|
admin's job would be a lot harder.
|
|
|
|
Adam
|
|
|
|
|
|
On Thu, Aug 22, 2002 at 08:42:12AM +0200, Eugen Leitl wrote:
|
|
| --
|
|
| -- Eugen* Leitl <a href="http://leitl.org">leitl</a>
|
|
| ______________________________________________________________
|
|
| ICBMTO: N48 04'14.8'' E11 36'41.2'' http://eugen.leitl.org
|
|
| 83E5CA02: EDE4 7193 0833 A96B 07A7 1A88 AA58 0E89 83E5 CA02
|
|
|
|
|
|
|
|
| ---------- Forwarded message ----------
|
|
| Date: Thu, 22 Aug 2002 00:24:54 -0400 (EDT)
|
|
| From: Kragen Sitaker <kragen@pobox.com>
|
|
| To: fork@example.com
|
|
| Subject: the underground software vulnerability marketplace and its hazards
|
|
|
|
|
| On August 7th, an entity known as "iDEFENSE" sent out an announcement,
|
|
| which is appended to this email. Briefly, "iDEFENSE", which bills
|
|
| itself as "a global security intelligence company", is offering cash
|
|
| for information about security vulnerabilities in computer software
|
|
| that are not publicly known, especially if you promise not to tell
|
|
| anyone else.
|
|
|
|
|
| If this kind of secret traffic is allowed to continue, it will pose a
|
|
| very serious threat to our computer communications infrastructure.
|
|
|
|
|
| At the moment, the dominant paradigm for computer security research
|
|
| known as "full disclosure"; people who discover security
|
|
| vulnerabilities in software tell the vendor about them, and a short
|
|
| while later --- after the vendor has had a chance to fix the problem
|
|
| --- they publish the information, including code to exploit the
|
|
| vulnerability, if possible.
|
|
|
|
|
| This method has proven far superior to the old paradigm established by
|
|
| CERT in the late 1980s, which its proponents might call "responsible
|
|
| disclosure" --- never release working exploit code, and never release
|
|
| any information on the vulnerability before all vendors have released
|
|
| a patch. This procedure often left hundreds of thousands of computers
|
|
| vulnerable to known bugs for months or years while the vendors worked
|
|
| on features, and often, even after the patches were released, people
|
|
| wouldn't apply them because they didn't know how serious the problem
|
|
| was.
|
|
|
|
|
| The underground computer criminal community would often discover and
|
|
| exploit these same holes for months or years while the "responsible
|
|
| disclosure" process kept their victims, who had no connections in the
|
|
| underground, vulnerable.
|
|
|
|
|
| The problem with this is that vulnerabilities that are widely known
|
|
| are much less dangerous, because their victims can take steps to
|
|
| reduce their potential impact --- including disabling software,
|
|
| turning off vulnerable features, filtering traffic in transit, and
|
|
| detecting and responding to intrusions. They are therefore much less
|
|
| useful to would-be intruders. Also, software companies usually see
|
|
| security vulnerabilities in their software as PR problems, and so
|
|
| prefer to delay publication (and the expense of fixing the bugs) as
|
|
| long as possible.
|
|
|
|
|
| iDEFENSE is offering a new alternative that appears far more dangerous
|
|
| than either of the two previous paradigms. They want to be a buyer in
|
|
| a marketplace for secret software vulnerability information, rewarding
|
|
| discoverers of vulnerabilities with cash.
|
|
|
|
|
| Not long before, Snosoft, a group of security researchers evidently
|
|
| including some criminal elements, apparently made an offer to sell the
|
|
| secrecy of some software vulnerability information to the software
|
|
| vendor; specifically, they apparently made a private offer to
|
|
| Hewlett-Packard to keep a vulnerability in HP's Tru64 Unix secret if
|
|
| HP retained Snosoft's "consulting services". HP considered this
|
|
| extortion and responded with legal threats, and Snosoft published the
|
|
| information.
|
|
|
|
|
| If this is allowed to happen, it will cause two problems which,
|
|
| together, add up to a catastrophe.
|
|
|
|
|
| First, secret software vulnerability information will be available to
|
|
| the highest bidder, and to nobody else. For reasons explained later,
|
|
| I think the highest bidders will generally be organized crime
|
|
| syndicates, although that will not be obvious to the sellers.
|
|
|
|
|
| Second, finding software vulnerabilities and keeping them secret will
|
|
| become lucrative for many more talented people. The result will be
|
|
| --- just as in the "responsible disclosure" days --- that the good
|
|
| guys will remain vulnerable for months and years, while the majority
|
|
| of current vulnerabilities are kept secret.
|
|
|
|
|
| I've heard it argued that the highest bidders will generally be the
|
|
| vendors of the vulnerable software, but I don't think that's
|
|
| plausible. If someone can steal $20 000 because a software bug lets
|
|
| them, the software vendor is never held liable; often, in fact, the
|
|
| people who administer the software aren't liable, either --- when
|
|
| credit card data are stolen from an e-commerce site, for example.
|
|
| Knowing about a vulnerability before anyone else might save a web-site
|
|
| administrator some time, and it might save the software vendor some
|
|
| negative PR, but it can net the thief thousands of dollars.
|
|
|
|
|
| I think the highest bidders will be those for whom early vulnerability
|
|
| information is most lucrative --- the thieves who can use it to
|
|
| execute the largest heists without getting caught. Inevitably, that
|
|
| means organized crime syndicates, although the particular gangs who
|
|
| are good at networked theft may not yet exist.
|
|
|
|
|
| There might be the occasional case where a market leader, such as
|
|
| Microsoft, could make more money by giving their competitors bad PR
|
|
| than a gang could make by theft. Think of a remote-root hole in
|
|
| Samba, for example.
|
|
|
|
|
| Right now, people who know how to find security exploits are either
|
|
| motivated by personal interest in the subject, motivated by the public
|
|
| interest, motivated by a desire for individual recognition, or
|
|
| personally know criminals that benefit from their exploits. Creating
|
|
| a marketplace in secret vulnerability information would vastly
|
|
| increase the availability of that information to the people who can
|
|
| afford to pay the most for it: spies, terrorists, and organized crime.
|
|
|
|
|
| Let's not let that happen.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| This is the original iDEFENSE announcement:
|
|
|
|
|
| From: Sunil James [mailto:SJames@iDefense.com]
|
|
| Sent: Wednesday, August 07, 2002 12:32 PM
|
|
| Subject: Introducing iDEFENSE's Vulnerability Contributor Program
|
|
|
|
|
|
|
|
| Greetings,
|
|
|
|
|
| iDEFENSE is pleased to announce the official launch of its Vulnerability
|
|
| Contributor Program (VCP). The VCP pays contributors for the advance
|
|
| notification of vulnerabilities, exploit code and malicious code.
|
|
|
|
|
| iDEFENSE hopes you might consider contributing to the VCP. The following
|
|
| provides answers to some basic questions about the program:
|
|
|
|
|
| Q. How will it work?
|
|
| A. iDEFENSE understands the majority of security researchers do not publish
|
|
| security research for compensation; rather, it could be for any of a number
|
|
| of motivations, including the following:
|
|
|
|
|
| * Pure love of security research
|
|
| * The desire to protect against harm to targeted networks
|
|
| * The desire to urge vendors to fix their products
|
|
| * The publicity that often accompanies disclosure
|
|
|
|
|
| The VCP is for those who want to have their research made public to the
|
|
| Internet community, but who would also like to be paid for doing the
|
|
| work.The compensation will depend, among other things, on the following
|
|
| items:
|
|
|
|
|
| * The kind of information being shared (i.e. vulnerability or exploit)
|
|
| * The amount of detail and analysis provided
|
|
| * The potential severity level for the information shared
|
|
| * The types of applications, operating systems, and other
|
|
| software and hardware potentially affected
|
|
| * Verification by iDEFENSE Labs
|
|
| * The level of exclusivity, if any, for data granted to iDEFENSE
|
|
|
|
|
| Q. Who should contribute to the VCP?
|
|
| A. The VCP is open to any individual, security research group or other
|
|
| entity.
|
|
|
|
|
| Q. Why are you launching this program?
|
|
| A. Timeliness remains a key aspect in security intelligence. Contributions
|
|
| to some lists take time before publication to the public at large. More
|
|
| often, many of these services charge clients for access without paying the
|
|
| original contributor. Under the iDEFENSE program, the contributor is
|
|
| compensated, iDEFENSE Labs verifies the issue, and iDEFENSE clients and the
|
|
| public at large are warned in a timely manner.
|
|
|
|
|
| Q. Who gets the credit?
|
|
| A. The contributor is always credited for discovering the vulnerability or
|
|
| exploit information.
|
|
|
|
|
| Q. When can I contribute?
|
|
| The VCP is active. You are welcome to begin contributing today.
|
|
|
|
|
| To learn more, go to http://www.idefense.com/contributor.html. If you have
|
|
| questions or would like to sign up as a contributor to the VCP, please
|
|
| contact us at contributor@idefense.com.
|
|
|
|
|
| Regards,
|
|
|
|
|
| Sunil James
|
|
| Technical Analyst
|
|
| iDEFENSE
|
|
|
|
|
| "iDEFENSE is a global security intelligence company that proactively
|
|
| monitors sources throughout the world -- from technical vulnerabilities and
|
|
| hacker profiling to the global spread of viruses and other malicious code.
|
|
| The iALERT security intelligence service provides decision-makers, frontline
|
|
| security professionals and network administrators with timely access to
|
|
| actionable intelligence and decision support on cyber-related threats.
|
|
| iDEFENSE Labs is the research wing that verifies vulnerabilities, examines
|
|
| the behavior of exploits and other malicious code and discovers new
|
|
| software/hardware weaknesses in a controlled lab environment."
|
|
|
|
|
| http://xent.com/mailman/listinfo/fork
|
|
|
|
|
|
|
--
|
|
"It is seldom that liberty of any kind is lost all at once."
|
|
-Hume
|
|
|
|
|
|
http://xent.com/mailman/listinfo/fork
|
|
|