27th Dec 2002 [SBWID-5898]
COMMAND
Unreliable windows signed catalogs (.cat) and certificate chain (WFP)
compromised
SYSTEMS AFFECTED
Windows NT, 2000, XP, .NET
PROBLEM
Thanks to Jason Coombs [jasonc@science.org] white paper research
[http://www.science.org/jasonc] as published by FORENSICS.ORG Security
Coordinator [secalert@forensics.org]
[http://www.forensics.org/secalert] :
Problem 1
=========
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.
Problem 2
=========
Windows File Protection will trust any digital signature whose
certificate chain is rooted at any one of the Trusted Root
Certification Authorities. Versions of Windows (and Internet Explorer)
ship with various preconfigured Trusted Root Certification Authorities
that are automatically trusted not just as potential Root CA's for SSL
certificate chains but also as valid Root CA's for code signing
certificates. Many Root CA's issue SSL certificates that have improper
Key Usage and Enhanced Key Usage Object Identifiers (OIDs), and missing
or invalid Basic Constraints, making many SSL certificates identical in
function to more privileged certificates. In the case of missing Basic
Constraints, Windows is known to trust a certificate as though it were
a legitimate Intermediate Certification Authority even with recent
patch (Q329115) applied to resolve MS02-050 "Certificate Validation
Flaw Could Enable Identity Spoofing" where the Basic Constraints field,
if present, was ignored completely. A related SECURITY ALERT issued
today "Windows File Protection Old Security Catalog Vulnerability"
explains that WFP is designed to trust equally every version of
published code that it has ever trusted by way of its installed
Security Catalogs (.CAT files), making it easy for an attacker to
replace new code that contains bug fixes and patches for security
vulnerabilities with old code that is known to be vulnerable to various
exploits.
______________________________________________________________________________
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). The
vulnerability disclosed in this communication is simply that any
digitally-signed replacement file of malicious origin will take
priority over any authentic WFP/WHQL-signed file.
Anyone can now obtain anonymous code signing and SSL certificates
automatically and free of charge from the following CA:
GeoTrust Inc.
http://www.freessl.com
whose Root Certificate is:
CN = UTN-USERFirst-Network Applications
OU = http://www.usertrust.com
O = The USERTRUST Network
L = Salt Lake City
S = UT
C = US
And use this anonymous freessl.com/usertrust.com/geotrust.com
certificate to digitally sign malicious code (e.g. using SIGNCODE.EXE)
that Windows File Protection (WFP) will automatically trust by virtue
of the fact that the certificate's Root CA (usertrust.com) is one of
the Root Certificates trusted by default in standard Windows/IE
installations. It should be noted, however, that every Root CA that
issues certificates that can be used for code signing (all CA's of
which this author is aware do sell code signing certificates in
addition to SSL certificates) enables any attacker in possession of a
valid code signing certificate signed by any Root CA to apply a digital
signature to malicious code and deploy it without detection to any
Windows box that relies on WFP for malicious code/Trojan detection.
A related SECURITY ALERT issued today [3] "Windows File Protection Old
Security Catalog Vulnerability" explains that WFP is designed to trust
equally every version of published code that it has ever trusted by way
of its installed Security Catalogs (.CAT files), making it easy for an
attacker to replace new code that contains bug fixes and patches for
security vulnerabilities with old code that is known to be vulnerable
to various exploits.
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 hash code
can still be found in an old Security Catalog file, or when an attacker
is able to place malicious code that contains a digital signature
embedded in the PE file format "Certificates Table" data directory
entry [4]. 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.
References (Problem 1)
======================
[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
References (Problem 2)
======================
[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] Windows File Protection Old Security Catalog Vulnerability
http://www.forensics.org/secalert/WFP_Old_Security_Catalog_Vulnerability.txt
[4] Microsoft Portable Executable and Common Object File Format Specification v6.0
Appendix: Calculating Image Message Digests
http://www.microsoft.com/hwdev/hardware/PECOFF.asp
SOLUTION
Solutions to Problem 1
======================
(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/default.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.
Solutions to Problem 2
======================
(Current Best Practice) Delete your default Root CA Certificates. All
of them.
Ignore Windows File Protection. If you must use it, run SIGVERIF.EXE
and manually examine the log file (Click the Advanced button to
configure scan parameters and logging) to determine who the publisher
is of each trusted file that appears to have a valid digital signature.
Be aware that it's possible for an attacker to acquire a certificate
from a trusted Root CA or Intermediate CA that has the same common name
(CN) as an authentic Microsoft certificate, such as "Microsoft Windows
2000 Publisher" in which case your analysis of the log file created by
SIGVERIF.EXE will be useless unless you also know the filename of the
Security Catalog file inside which each file's hash code should be
found. The only way to get this information easily is to compare
SIGVERIF.EXE log files between Windows boxes, because the Security
Catalog files themselves do not contain filenames of the files they are
meant to authenticate, .CAT files contain only hashes.
Script the verification of trust for your executable code files using
CHKTRUST.EXE instead of WFP, since CHKTRUST.EXE relies on the WinTrust
API instead of WFP. WinTrust will only trust software publisher
certificates (SPCs) that are selected explicitly and configured for
automatic trust by way of the following Registry keys:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust
Providers\Software Publishing\Trust Database
HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust
Providers\Software Publishing\Trust Database
Produce your own digital signatures instead using 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
(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/default.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 automatically trust any Root CA when it comes to
code signing. Windows File Protection should never have been designed
to trust digital signatures on software based on certificate chains,
WFP should trust only specific certificates the way that WinTrust
operates.
When the vendor redesigns this feature, it would be sensible to also
deploy a better system for managing certificates and trust
relationships with End Entities, Root CA's, and any site that needs SSL
for the purpose of encryption but doesn't care about the authentication
features that it never provided properly in the first place for users
of Windows. There is a large demand, and a legitimate demand, for
anonymous SSL certificates like those distributed by
freessl.com/geotrust.com/usertrust.com -- however, bad code deployed in
the wild today like Windows File Protection, and flawed security
policies that rely on such bad code, make the availability of free,
anonymous SSL certificates/code signing certificates an urgent and
immediate information security threat. Rather than shut down
Certification Authorities with bad security practices, this author
suggests that vendors who produce bad code should issue patches
immediately to remediate the vulnerability from the source rather than
attempt to prune competition for security-related products and services
from the digital marketplace.
Certificates should be managed by each node/end-user in a manner
similar to the way that cookies are now managed in Internet Explorer.
Each end-user/administrator of each node on the network should be able
to easily define a security policy and the default setting should be to
block and deny all. Each capability possible with respect to each
certificate (SSL/code signing/e-mail signatures, etc.) should be a
separate security policy setting that the end-user or an authorized
administrator must explicitly allow on a per-certificate basis.
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.
______________________________________________________________________________
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH
