Subject: Re: Status of draft-christey-wysopal-vuln-disclosure-00.txt

From: "Jason Coombs" <[email-masked]>
Date: Sun, 22 Dec 2002 13:28:15 -1000

Aloha,

Most vendors are still years away from being adequately prepared to receive
and respond effectively to security vulnerabilities, and many don't have a
clue how to react when somebody posts full disclosure to bugtraq.

And it's not just vendors who need help and guidance; CERT and other
security monitoring/advisory organizations have become at times a limiting
factor in effective incident response, especially when the issue is truly
critical calling into question the security integrity of billion-dollar
commercial infrastructure around PKI. Take the Microsoft Windows certificate
chain validation flaw for example. Basic constraints are ignored, enabling
anyone with a valid certificate signed by a trusted CA to forge certificates
that Windows automatically trusts. Millions of Windows computers are still
vulnerable to this flaw, making SSL untrustworthy when Internet Explorer is
used and making it possible to forge digital signatures on S/MIME e-mail
messages.

Instead of rallying behind awareness of the threat and its resolution, the
whole issue was virtually ignored by CERT and other organizations that media
rely on to separate hoaxes and fluff from really important security issues.
It's likely that the muted response from official security alert groups,
which in turn led to a muted response from the media, resulted from a desire
to avoid giving any publicity or attention to the person who discovered the
vulnerability and disclosed it on bugtraq without first notifying Microsoft
and working through any responsible disclosure process. There is no better
example of an incident that would have benefited from an accepted incident
response procedure when a vulnerability is reported without responsible
disclosure; or perhaps there is no better example of the uselessness of any
such procedure and the absolute value of a self-informing infosec community
that could care less whether the media and others who need guidance on
reporting vulnerabilities in fact receive that guidance.

Suppressing media attention that might gratify a malicious black-hat is the
de facto incident response standard when responsible disclosure is ignored?
Surely it's possible to separate the discovery from the discoverer -- if
there were a replacement for christey-wysopal-vuln-disclosure that the IETF
were ultimately to endorse that more completely spells out the roles and
responsibilities, and the incident response plan, of everyone involved
including the media it would be simple to communicate to reporters that
"this vulnerability was discovered and published by a malicious person for
the purpose of gang-style bragging rights, therefore we request that you
leave out any mention of where knowledge of this threat came from and
instead report the technical details that will help people protect
themselves and their computers."

Expiration of christey-wysopal-vuln-disclosure either leaves a void that
needs to be filled by something more comprehensive and workable that takes
into consideration the complexity of real-world incident response or it
shows us that the social complexity and cost of responding to information
security vulnerabilities exceeds by many factors the value it provides to
anybody who is at-risk and only a few elite security researchers need be
concerned with communicating about these matters while everyone else should
just auto-update their OS and application software daily.

Sincerely,

Jason Coombs
[email-masked]

--

Robert Elz <[email-masked]> writes:

> That wasn't done here, so the "officially withdrawn it" really can only be
> interpreted as "the authors are no longer pushing this doc".

The authors stopped pushing this document _only in the IETF context_.
However, the document is usually referenced by its
http://www.ietf.org/ URL. I think that's why the situation is so
confusing.

On Mon, 23 Sep 2002, Florian Weimer wrote:

> Date: Mon, 23 Sep 2002 20:01:11 +0200
> From: Florian Weimer <[email-masked]>
> To: [email-masked]
> Subject: Status of draft-christey-wysopal-vuln-disclosure-00.txt
>
> At some point, the authors of this IETF draft have officially
> withdrawn it, but this document is still being referenced a lot,
> sometimes in contexts which might lead inexperienced readers to
> believe that this draft is supported by the IETF.  It's even expired.
>
> What's the status of the document, as far as the IETF is concerned?
> Will it remain in the IETF archives forever?  Has the withdrawal been
> withdrawn?

---

From: "Jason Coombs" <[email-masked]>
Date: Thu, 26 Dec 2002 01:18:07 -1000

Thanks for the replies, those of you who have already provided feedback on
my inquiry into currently-accepted best practices for responsible disclosure
considering the disappearance of
draft-christey-wysopal-vuln-disclosure-00.txt ... Enclosed below is a
security alert issued today that includes a revised Responsible Disclosure
section that I think would make a good starting point for a new Internet
Draft.

Sincerely,

Jason Coombs
[email-masked]

-----Original Message-----
From: FORENSICS.ORG Security Coordinator [mailto:[email-masked]]
Sent: Thursday, December 26, 2002 12:55 AM
To: [email-masked]
Cc: [email-masked]
Subject: Full Disclosure: Windows File Protection Old Security Catalog
Vulnerability

============================================================================
==
____________________________________________________________________________
__
SECURITY ALERT

Windows File Protection Old Security Catalog Vulnerability

December 26, 2002 [Full Disclosure, [email-masked] and others]
August 26, 2002 [Private Disclosure, Microsoft Press and others]

Jason Coombs <[email-masked]>
http://www.science.org/jasonc

FORENSICS.ORG Security Coordinator <[email-masked]>
http://www.forensics.org/secalert
____________________________________________________________________________
__
Abstract

Old Security Catalogs (.CAT files) containing valid digital signatures are
left in place under %WinDir%\System32\CatRoot when new files and their
associated Security Catalogs aredeployed. Windows uses its
CryptCATAdminCalcHashFromFileHandle API function (found in mscat32.dll under
Windows 2000 and in wintrust.dll under Windows XP/.NET Server) to compute a
file's SIP hash code (see below) and then its
CryptCATAdminEnumCatalogFromHash API function to automatically locate the
digitally-signed .CAT files, if any, that contain the file's SIP hash code.
If a file's SIP hash code cannot be found inside any digitally-signed .CAT
file and the file itself contains no digital signature (see below) then the
file is considered to be "unsigned". Windows File Protection gives the same
priority and preference to authentic hash codes of old binaries (and other
protected files) as it does to authentic hash codes of newer, updated
binaries. An attacker can therefore place old authentic files containing
known security vulnerabilities in place of newer files from hotfixes and
service packs and WFP will automatically trust and certify the authenticity
of the older files. Only manual verification of full-file hashes against
known good hashes (i.e. authentic hashes) of newer OS files will properly
reveal the malicious replacement. A related SECURITY ALERT issued today
"Windows File Protection Arbitrary Certificate Chain Vulnerability" explains
that WFP is designed to trust any certificate chain rooted at any one of
Windows' Trusted Root Certification Authorities, making it easy for an
attacker to replace authentic OS binaries with digitally-signed malicious
code that WFP will, by design, automatically authenticate and trust.
____________________________________________________________________________
__
Discussion

Windows File Protection (a.k.a. Windows Driver Signing) [1] verifies digital
signatures applied to operating system binaries, device drivers, and other
OS files, as well as files published by third-parties [2] that are certified
by Windows Hardware Quality Labs (WHQL) (a.k.a. Microsoft Windows Hardware
Compatibility). To enable multiple trust authorities to certify the same
files independently without altering the hash code computed by WHQL for its
Windows Hardware Compatibility signature, WFP relies on a proprietary
Subject Interface Package (SIP) [3] object file hashing mechanism that
applies hash algorithms such as FEDERAL INFORMATION PROCESSING STANDARDS
PUBLICATION 180-1 (SHA-1) [4] to a subset of the bits contained in any
Portable Executable (PE) file rather than to the entire file (full-file
hashing). In particular the "Certificates Table" data directory entry [5] in
the executable’s IMAGE_DATA_DIRECTORY table located at the end of its PE
header IMAGE_OPTIONAL_HEADER structure is excluded from the hashed bits by
the SIP object file hash preprocessor module which is visible during
debugging sessions as "WINTRUST!SIPObjectPE_". Every PE file can thus have
digital signature(s) attached at-will in a production system without
invalidating the file's SIP hash code, which would impact the perception of
any code that computes a full-file hash for the purpose of identifying the
executable portion of the PE file as authentic, trustworthy, and/or trusted
code. WFP uses SIP hashes to avoid this impact, the variable full-file hash,
caused by the potential to apply digital signatures directly to PE files.

To simplify the process of code signing, so that every file need not be
signed individually and updated signatures can be deployed at run-time (e.g.
when certificates expire or private keys become compromised) without
replacing files that might be in use (and thus locked for writing) Windows
File Protection uses Security Catalogs (.CAT files) [6] that are
digitally-signed. Each .CAT file contains a list of authentic SIP hashes of
trusted files that Windows File Protection (via SFC.EXE and SIGVERIF.EXE as
well as automatic protection feature) considers to be valid SIP hashes.
Every file that, when hashed with the help of "WINTRUST!SIPObjectPE_",
results in a SIP hash code that is contained in any .CAT file is considered
trustworthy by Windows File Protection, even if updates to the file (based
on filename and version) have been deployed and the newest version of the
authentic code in fact contains a different SIP hash from the one that
Windows File Protection encounters.

Windows uses its CryptCATAdminCalcHashFromFileHandle API function [7] (found
in mscat32.dll under Windows 2000 and in wintrust.dll under Windows XP/.NET
Server) to compute a file's SIP hash code and then its
CryptCATAdminEnumCatalogFromHash API function to automatically locate the
digitally-signed .CAT files, if any, that contain the file's SIP hash. If a
file's SIP hash code cannot be found inside any digitally-signed .CAT file
and the file itself contains no digital signature then the file is
considered to be "unsigned". Windows File Protection gives the same priority
and preference to authentic hash codes of old binaries (and other protected
files) as it does to authentic hash codes of newer, updated binaries.

An attacker can therefore place old authentic files containing known
security vulnerabilities in place of newer files from hotfixes and service
packs and WFP will automatically trust and certify the authenticity of the
older files.

A related SECURITY ALERT issued today [8] "Windows File Protection Arbitrary
Certificate Chain Vulnerability" explains that WFP is designed to trust any
certificate chain rooted at any one of Windows' Trusted Root Certification
Authorities, making it easy for an attacker to replace authentic OS binaries
with digitally-signed malicious code that WFP will, by design, automatically
authenticate and trust.

Therefore, only manual forensic verification of full-file hashes with
comparison against a list of known good hashes (i.e. authentic hashes) will
properly reveal the malicious replacement when an attacker applies a
verifiable digital signature to an old Windows binary whose SIP hash can
still be found in an old Security Catalog file. The following "Action
Required" is thus inadequate to defend against misplaced trust when the
attack uses digitally-signed malicious code or digitally-signed old, but
authentic, vulnerable code published (and digitally-signed) in the past by a
legitimate software vendor.
____________________________________________________________________________
__
Action Required

(Current Best Practice)
Delete the Security Catalogs (.CAT files) provided by your vendors. Produce
your own instead, and sign them with a code signing certificate that you
issued to yourself from your own Trusted Root Certification Authority
certificate store. Details for producing your own Security Catalogs and
managing your own Public Key Infrastructure (PKI) for the purpose of
preventing unwanted code execution will be available at the following URL
which is controlled by this author:

http://www.countermand.org

Note the following instructions provided by Microsoft for producing Security
Catalogs using the MakeCat utility:

http://msdn.microsoft.com/library/en-us/security/Security/makecat.asp
http://msdn.microsoft.com/library/en-us/security/Security/using_makecat.asp

Note the following caveat that requires certain Root CA certificates to
remain trusted in order to avoid breaking WFP entirely.

Q293781 Trusted Root Certificates That Are Required By Windows 2000
http://support.microsoft.com/support/kb/articles/293/7/81.ASP

(Adequate Protection)
First, upgrade to Windows XP or Windows .NET Server 2003 from whatever
prehistoric version of Windows you're using now so that you can enable
Software Restriction Policies per the following instructions. Add a new hash
code rule for every system binary and other executable file you wish to
allow to run on your box; this establishes a fixed trust policy based on the
authentic hashes of code that you choose to trust rather than a variable
trust policy based on anything that Windows thinks is legitimate based on
the appearance that it has a valid digital signature. This fixed/static
trust policy is superior to the dynamic one provided through the use of
digital signatures, because whether or not something is digitally-signed or
meant to be trusted (today, as opposed to in the past) is determined
automatically by Windows, inclusive of its known flaws in analyzing
certificate chains, when signatures (and PKI) are used -- these fancy
cryptographic schemes are not necessary in order to countermand execution of
unwanted code, and they actually interfere with your ability to prevent
unwanted code when there are problems with the implementation or design of
these variable trust-based PKI systems:

Q324036 HOW TO: Use Software Restriction Policies in the Windows .NET Server
Family
http://support.microsoft.com/support/kb/articles/324/0/36.ASP

Q310791 Description of the Software Restriction Policies in Windows XP
http://support.microsoft.com/default.aspx?scid=KB;en-us;310791

And then... (it will take you a long time to explicitly authorize each
executable module and DLL, which is why deploying your own Security Catalogs
with your own PKI-based Root CA and code signing certificate is the Best
Practice today.)

Disable Windows File Protection completely by deleting all Root CA
certificates from every trusted certificate store per the following
instructions, which you must apply in reverse (that is, the following
Knowledge Base Article shows you how to recover from a failed Windows File
Protection condition due to missing Root Certificates -- if WFP is already
working, kill it by following these instructions in reverse):

Q296241 Windows File Protection May Not Start
http://support.microsoft.com/default.aspx?scid=kb;EN-US;296241

Note that you should NOT follow the instructions found in Q293819, as they
remove only the current user's Root CA certificates rather than every
certificate deployed to your box:

Q293819 How to Remove a Root Certificate from the Trusted Root Store
http://support.microsoft.com/default.aspx?scid=kb;EN-US;293819

(Common Sense)
Remember to make a record of the authentic hashes of the files you've chosen
to trust explicitly so that you can audit your system later and compare your
hashes against those of a peer or another Windows box that you also control.
Command-line utilities to compute full-file hashes are available on every OS
platform, and you can build your own easily with Microsoft .NET per the
following article written by this author and published in MSDN Magazine:

Tamper-Resistant Apps
Cryptographic Hash Algorithms Let You Detect Malicious Code in ASP.NET
by Jason Coombs
http://www.msdn.microsoft.com/msdnmag/issues/02/09/ASPNETHashAlgorithms/defa
ult.aspx
____________________________________________________________________________
__
Preventive per Contra Response to Vendor Response

The following Bellum Omnium Contra Omnes per Contra response is offered in
advance to the anticipated vendor response to this SECURITY ALERT as a
preventive measure in the interest of diminishing the Mean Time Before Fix
(MTBF). Yes, this behavior is by design; placing documentation to this
effect in the manual and crying RTFM is foul. There is no reason to let
mutually-exclusive Security Catalog files exist in production systems simply
because it works, somewhat, today, when nobody tampers with a Windows box on
purpose.

Shipping a hotfix or service pack with a new Security Catalog file without a
mechanism to remove the out-of-date .CAT file(s) when the new ones are
installed defeats a core purpose of Windows File Protection entirely:
simplifying the process of distributing authentic hashes. Even Windows File
Protection is unable to determine which of the SIP hashes is the
most-current "authentic hash" of a given file. A redesign of this whole
process is necessary, with enhancements to the Security Catalog file format.
This author recommends inclusion of full-file hashes and filenames, file
sizes, and file version numbers accompanying each and every authentic SIP
hash so that end-users can, if they wish, utilize standard full-file hashing
tools on a platform of their choice to verify the authenticity of the code
they plan to deploy (and trust) to a production Windows box.

This author will gladly code these revisions for vendor if vendor will
release the relevant source code under the terms of an open source license.
____________________________________________________________________________
__
Responsible Disclosure

The Internet Draft known as draft-christey-wysopal-vuln-disclosure-00.txt
formerly located at the following URL has expired and has been removed from
publication:

http://www.ietf.org/internet-drafts/draft-christey-wysopal-vuln-disclosure-0
0.txt

Neither its authors nor any other party chose to advance a responsible
disclosure standard through any IETF working group due to lack of interest.
Therefore the following observations take priority as de facto "best
practices" for information security and encryption research and responsible
communication of security- and cryptography-related vulnerability findings:

A. Full disclosure made directly to those who care enough about security to
read security alert and advisory documents like this one is an effective way
to communicate vulnerability details to those who most urgently need them
and who are most likely to act upon them.

B. There are always mitigating factors; and there may be imperfections in
this author's forensic analysis of the information security vulnerability
described in this communication due to time constraints and the need to
disseminate the information that resulted from the author's information
security and encryption research in a timely manner so that it can be
peer-reviewed, confirmed widely through experiments conducted independently
by other researchers, and custom-tailored to the needs and circumstances of
those who are affected by the discovery. This author relies on the
information security community at large to identify and document every
permutation of legitimate mitigating factors.

C. THE MOST IMPORTANT MITIGATING FACTOR IS ALWAYS AN INFORMED POPULATION
THAT IS READY, WILLING, AND ABLE TO ACT WHEN ACTION IS REQUIRED TO ENSURE
THE SECURITY AND INTEGRITY OF INFORMATION SYSTEMS AND PROTECT STAKE-HOLDERS
WHO WOULD OTHERWISE BE BOTH AT-RISK AND UNINFORMED; IT IS IRRESPONSIBLE FOR
A SECURITY RESEARCHER TO TRUST SOMEBODY ELSE TO DISSEMINATE IMPORTANT
INFORMATION ABOUT NEW VULNERABILITIES AND IT IS FURTHER IRRESPONSIBLE FOR A
PERSON WHO KNOWS OF A SECURITY VULNERABILITY TO KEEP IT SECRET FOR A
PROLONGED PERIOD OF TIME IN THE IRRATIONAL AND NARCISSISTIC HOPE THAT NOBODY
ELSE IS SMART ENOUGH TO FIND THE SAME VULNERABILITY.

D. A small, highly-skilled and diligent distributed group of
self-coordinating, self-organizing infosec experts who know each other and
communicate freely is far more capable of responding to security incidents
and moving forward any and all preventative measures necessary to minimize
the security risk and imminent dangers of any infosec threat than are dozens
of people and organizations compromised by politics and fear. To ensure
continued high-quality, timely, and accurate vulnerability disclosure
requires peer-reviewed communication free from restrictive and oppressive
forces. Those who pose a threat to information security have this freedom to
communicate because they take it or they make it even though it requires
them to take personal risk. For information security professionals and the
United States Government to deny themselves, their employees, and citizens
this same freedom as a defense against attack is not only counter-productive
it is also insane.

E. The Digital Millennium Copyright Act (DMCA) makes it a crime in the
United States (including Hawaii, Alaska, the U.S. Virgin Islands, Guam, and
so forth) to circumvent computer security devices and algorithms that have
the effect of protecting copyrighted works from unauthorized access,
copying, modification, tampering, or reverse engineering unless there is a
legitimate information security research purpose and the researcher's
methodology meets certain requirements. If this author was, or henceforth
is, physically present in a jurisdiction regulated by the DMCA when any copy
of this communication was/is authored, or any portion of its communicated
information security and/or encryption research was/is physically conducted
by this author, this author hereby invokes the information security
exemptions contained in the DMCA section 1201 and other sections,
subsections, and paragraphs. The information security analysis performed by
the author of this communication was conducted on equipment owned by the
author or to which the author was granted authorized access. Each
copyrighted work relied upon by the author while performing information
security testing in connection with this communication was duly licensed to
the author, the author's employer, and/or the entity who authorized the
author to conduct information security and/or encryption research using
same, to the best of the author's knowledge. The author hereby disclaims any
and all liability, both civil and criminal, for benefits the author received
from copyright violations potentially committed by others and the author
further asserts freedom from criminal prosecution as an individual by virtue
of the fact that author may have been acting in the capacity of employee,
board member, or other representative of (an) employer(s) rather than acting
in the capacity of individual when the author prepared this communication
for distribution and conducted the aforementioned information security
analysis, penetration, circumvention, reverse engineering, and/or encryption
research.

F. The DMCA section 1201 "Circumvention of copyright protection systems"
also includes provisions for "PERMISSIBLE ACTS OF ENCRYPTION RESEARCH".
There should be no concern on the part of any security researcher or
cryptographer that communicating the results of an ethical information
security analysis might result in arrest and prosecution for violation of
the DMCA or other laws. THE DMCA DOES NOT TRUMP THE FIRST AMENDMENT. The
author of this document hereby declares this communication to be protected
speech as defined by prevailing Constitutional law interpretation of
Amendment I of the United States Constitution; this speech is protected
because of its political nature, because the author was/is forced by the
existence of laws and the existence of irrational legal- and/or
peer-pressure to fear prosecution or hardship resulting from this
communication, because it represents the author's exercise of a freedom to
assemble insofar as this communication is a call for an assembly of the
author's peers for the purpose of analysis of the aforementioned security
vulnerability, an assembly that may in fact occur in meatspace as well as
cyberspace, and because it petitions the U.S. Government to relieve the
present atmosphere of uncertainty it has created and/or allowed to be
created with respect to the freedom of information security researchers to
carry out unauthorized penetrations and circumventions of information
security, copyright, and/or digital access control systems whenever the
circumventions or access control penetrations occur without explicit
permission from every copyright-holder, patent-holder, or other interested
party whose rights and reasonable expectations of law enforcement protection
might have been violated or infringed. The U.S. Government portends in the
language of its legislation that a person must not be criminally liable for
penetration testing her own door lock, but fails to distinguish between the
act as a protected exemption that violates no law and subjects the owner of
the door (and of the lock) to no possible civil or criminal liability, and
the subsequent detailed communication of the act inclusive of instructions
that are executable by a digital machine that enable other owners of doors
(and locks) of a similar design to benefit from this security and/or
cryptography research. Therefore, while this author is certain of impunity
in all U.S. civil and criminal courts for information security research and
encryption research actions taken by this author prior to this
communication, this author has reason to fear that the content of this
communication, should it be deemed to be sufficiently-detailed so as to be
usable as a tool of digital system penetration and/or circumvention, could
create devastating legal problems for this author sufficient to destroy the
rest of this author's life and significantly damage the lives of this
author's dependents. This author participates in the action of authorship
and takes credit for this communication openly in spite of the extreme risk
it may represent, confident that unjust abusive prosecution, violations of
this author's various Constitutional rights, and abusive civil lawsuits that
are criminal acts on behalf of the plaintiff in many jurisdictions, and
which may in fact be criminal acts in the jurisdiction local to this author,
will not be tolerated by a just society.

G. With respect to registered Trademarks and copyrighted materials
referenced or contained wholly in this communication the author claims fair
use under Title 17 of United States Code with respect to alleged copyright
infringement; and the author claims the privilege of media communication
made in the public interest (freedom of the press) with respect to alleged
violations of United States Federal law, State and municipal laws, and/or
international Treaties that seek to regulate this communication or control
subsequent access to it.

H. Like an IETF Working Group or an open source or free software/GNU
development effort, anyone who wishes to do so and who has something of
value to contribute can contact infosec peers and solicit the forensic
analysis help of any other security coordinator, infosec, or forensics
expert without fear of prosecution for criminal conspiracy. In practice,
contacting a vendor expecting forensic analysis assistance is futile;
vendors will take a new vulnerability report and conduct their own forensic
analysis but won't reveal additional aspects of a vulnerability to you
because you are untrustworthy. The vendor has no incentive to spread
vulnerability information and you have no "need to know" more than the
vendor chooses to tell you about the scope of the vulnerability you
discovered. Entrusting vendors with exclusive possession of vulnerability
details is counterproductive to the desired end-result of secure information
systems and properly hardened security policies; the analysis capabilities
of security researchers who are not restricted by employment contracts,
confidentiality agreements, and other impairments are superior in every
respect and in every instance thus far examined by this author.

I. This entire communication is Copyright (C) 2002-9999 by its author and/or
the author's employer(s), renewed annually through the creation of derived
works and potential copyright registration with the Library of Congress, and
all rights are reserved. You are hereby granted a limited right to access
this communication and distribute copies of this communication for the
limited purposes of information security, encryption research, or fair use
reproduction/citation. All other reproduction and access rights are reserved
by the Copyright holder.

J. Notice is hereby served that patent rights may exist benefiting the
author and/or the author's employer(s) in any or all work, methods, and
discoveries communicated herein. Should such patent rights ever be claimed
by a third-party in any jurisdiction covered by U.S. Federal law or
international treaty to which the United States is a party, author and/or
author's employer hereby claim right of priority. Failure to file an
application for patent within the statutory window of opportunity for
exercising a right of priority shall in no way diminish the author's right
to file, or cause to be filed, a Statutory Invention Registration (SIR)
patent with the United States Patent and Trademark Office (USPTO); the
potential prosecution of which can be inferred by public distribution of
this communication and this notice. Any patentable matter, method, process,
algorithm, or other intellectual property deserving of patent protection
expressed in this communication is now prior art, subject to the
aforementioned right of priority and right to prosecute application for SIR.
____________________________________________________________________________
__
References

[1] Driver Signing for Windows
    http://www.microsoft.com/hwdev/driver/digitsign.asp

[2] Driver Signing / File Protection
    http://www.microsoft.com/hwdev/driver/drvsign.asp

[3] Subject Interface Package (SIP) Functions and documentation
    CryptSIPAddProvider, CryptSIPRemoveProvider, SIP_ADD_NEWPROVIDER

http://msdn.microsoft.com/library/en-us/security/security/cryptography_funct
ions.asp

[4] Secure Hash Standard (SHA-1)
    http://csrc.nist.gov/publications/fips/fips180-1/fip180-1.txt

[5] Microsoft Portable Executable and Common Object File Format
Specification v6.0
    Appendix: Calculating Image Message Digests
    Fields Not To Include In Digests
    http://www.microsoft.com/hwdev/hardware/PECOFF.asp

[6] Security Catalog (.CAT File) MakeCat Utility
    http://msdn.microsoft.com/library/en-us/security/Security/makecat.asp

http://msdn.microsoft.com/library/en-us/security/Security/using_makecat.asp

[7] CryptCATAdminCalcHashFromFileHandle API Function

http://msdn.microsoft.com/library/en-us/security/Security/cryptcatadmincalch
ashfromfilehandle.asp

[8] Windows File Protection Arbitrary Certificate Chain Vulnerability

http://www.forensics.org/secalert/WFP_Arbitrary_Certificate_Chain_Vulnerabil
ity.txt
____________________________________________________________________________
__

============================================================================
==

-----Original Message-----
From: Jason Coombs [mailto:[email-masked]]
Sent: Sunday, December 22, 2002 1:28 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; Bruce Schneier
Subject: Re: Status of draft-christey-wysopal-vuln-disclosure-00.txt

Aloha,

Sincerely,

Jason Coombs
[email-masked]

--

---

From: [email-masked]
Date: Thu, 26 Dec 2002 13:33:12 -0500

> section that I think would make a good starting point for a new Internet

Jason - I think you misunderstood something in a very major way...

> communication of security- and cryptography-related vulnerability findings:

The general consensus as I read it was that the christey-wysopal draft was
generally considered a very good and reasonable document.

The only reason it did not get progressed through the IETF process was that
there was a general belief that the *subject matter* was not an IETF issue.
It's important, but it's not a topic we write RFC's about.

This is something that probably some other group should be running with.
I've taken the liberty of cc:ing some of the people at SANS and the
Center for Internet Security in hopes that they'll either pick it up or
know who should be doing it.
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

---

From: Florian Weimer <[email-masked]>
Date: Thu, 26 Dec 2002 20:35:34 +0100

> generally considered a very good and reasonable document.

There was quite a bit rejection, and some very profound criticism (the
killer argument, IMHO, is that a large part of the industry does not
accept _any_ disclosure at all).

However, this is now a strawman.  The document has clearly been
overtaken by events (if it has ever been up-to-date).  For example, it
ignores that currently, those people who are expected to play the role
of Coordinators usually provide paid prepublication access to
vulnerability information.  The draft does not require Coordinators to
keep the information they receive strictly confidental, but I'm not
sure if this was the intent of the authors or just an oversight.

(I'm sorry for the long Cc: list; I'm not sure if it is appropriate.
Please complain if you don't want to receive further messages.)

---

From: [email-masked]
Date: Thu, 26 Dec 2002 14:44:30 -0500

> accept _any_ disclosure at all).

Wander over to NANOG - a large(*) part of the ISP industry doesn't seem to think
that filtering RFC1918-space packets found on the public internet should
be filtered either.  Doesn't make it "right" in any sense of the term....

(*) large enough that some 30% of the traffic at the root nameservers is
from 1918 source addresses - and these packets never got filtered.

/Valdis

---

From: Florian Weimer <[email-masked]>
Date: Fri, 27 Dec 2002 00:25:52 +0100

Chris Wysopal <[email-masked]> writes:

> I was not aware of the paid prepublication access that some
> coordinators provide at the time the draft was written.  I don't know
> if Steve knew this.  This was an new concept at the time. I have heard
> that CERT is willing to keep researcher submissions confidential if
> requested. But this is second hand knowledge.

Only one (!) FIRST member has responded to an informal request to
clarify these issues and assured me that they won't share information
before publication.  However, they do receive about one request per
month for such information (not too surprising considering their
position).

BTW, have a look at <http://www.itworld.com/Sec/2210/IDG01419cert/>
(and look at the publication date).  This press article suggests that
members of the Internet Security Alliance receive plenty of
information.  I wonder how many researches who contact CERT/CC have
this crucial background information.  Unfortunately, the CERT/CC FAQ
is open to interpretation -- whether sharing with ISA members is
implicit or explicit, mandatory or optional.

Half a year ago I was being laughed at when I remarked that a trusted
coordinator with a viable business model that does not include paid
early access is big problem. *sigh*

> There are some organizations that prepublish minimal information
> such as the software and version affected by a vulnerability and
> perhaps workaround information.  This is what ISS does.

Their clients are granted access to the full advisory, according to
their published policy.  But thanks for clarifying that this is just
an error in the documentation. :-)

> I have heard secondhand that CERT prepublication information is much
> more detailed. I could see a market for prepublication exploit code.

There is already such a market.  Several organizations are buying, and
researches are selling.  The most visible but still regularly
overlooked example is iDEFENSE.  (In the past, some vendors even
thanked iDEFENSE for responsibly disclosing a vulnerability, even
though they didn't receive a single day of advance notice!)

There is even a market for post-publication exploit code: Creating IDS
signatures and test cases for scanning tools is quite a bit easier if
you've got working exploit code.  Most of the time, you are lost if
you haven't got the source code of the vulnerable software, and even
if there is source code, it often contradicts what the vendors tell
you, or you have to wade through thousands of lines of patches.
Furthermore, considerable expertise in the protocols involved in the
issue might be needed.

If I were an IDS/network scanner vendor, I'd really try to play the
Coordinator role for this reason.  Nowadays, you won't get the exploit
code from public archives most of time (although you can always ask,
but with varying degree of success...).

---

From: Chris Wysopal <[email-masked]>
Date: Thu, 26 Dec 2002 17:47:47 -0500

>sure if this was the intent of the authors or just an oversight.
I was not aware of the paid prepublication access that some coordinators 
provide at the time the draft was written.  I don't know if Steve knew 
this.  This was an new concept at the time. I have heard that CERT is 
willing to keep researcher submissions confidential if requested. But 
this is second hand knowledge.

To clarify the draft, it was not our intention to delve too deeply into 
standardizing coordinator behavior since the issues are many. We also 
scoped the document to not touch the issue of disclosure content.  

My thoughts on coordinator behavior would be to keep the information 
confidential amongst researcher, coordinator, and potentially affected 
vendors. Every party that receives prepublication information increases 
the the risk to the Internet as a whole while decreasing it for the 
party. Information is bound to leak as more parties are added to the 
prepublication list.  

Prepublication is not a black or white issue.  There are some 
organizations that prepublish minimal information such as the software 
and version affected by a vulnerability and perhaps workaround 
information.  This is what ISS does.  I have heard secondhand that CERT 
prepublication information is much more detailed. I could see a market 
for prepublication exploit code. There is also the issue of what kind of 
organizations are allowed to join a prepublication group and what are 
the contractual limits of what they can do with the information they 
receive. For instance, can a security consulting company subscribe to 
the prepublication group and then use the information to protect their 
customers?  There are many nuances once you allow prepublication.

Cheers,

Chris