Protect yourself against future threats.
-----BEGIN PGP SIGNED MESSAGE-----
===========================================================================
AUSCERT External Security Bulletin Redistribution
ESB-2001.146 -- SecuriTeam Windows NT Focus
Windows PGP (Pretty Good Privacy) ASCII Armor Parser Vulnerability
11 April 2001
===========================================================================
AusCERT Security Bulletin Summary
---------------------------------
Product: PGP 5.0 - 7.0.4
Vendor: PGP Security Inc.
Operating System: Windows
Impact: Execute Arbitrary Code/Commands
Access Required: Remote
- --------------------------BEGIN INCLUDED TEXT--------------------
Windows PGP (Pretty Good Privacy) ASCII Armor Parser Vulnerability
- ------------------------------------------------------------------------
SUMMARY
PGP (Pretty Good Privacy) is a suite of encryption tools originally
published in 1991 by Phil Zimmermann to enhance personal privacy. It has
become the de facto standard for email encryption, winning numerous
industry awards and spawning a variety of alternative versions.
PGP Security, Inc. currently maintains the commercial version of PGP also
providing a version that is freely downloadable.
The PGP ASCII Armor parser provided with most versions of PGP (see
'Vulnerable Versions' section below) contains a behavior that allows the
creation of an arbitrary file in the same directory as the armored file.
Since this file can contain arbitrary bytes, this can easily lead to the
execution of arbitrary code on the Windows platform.
DETAILS
Vulnerable Versions:
PGP for Personal Privacy/PGP Desktop Security/PGPfreeware 5.0 - 7.0.4 for
Windows only (PGP Security, Inc.)
As noted above, in UNIX the created file has the 'execute' bit turned off.
Furthermore, the file has the same name as the .sig file, which greatly
reduces the risk from this issue.
Not Vulnerable:
All Macintosh versions of PGP (PGP Security, Inc.)
All Unix versions of PGP (PGP Security, Inc.)
PGPwireless for Palm OS (PGP Security, Inc.)
GPG (GNU)
[Note that this is not an exhaustive list of non-vulnerable PGP programs
and that on non-Windows platforms the Trojan DLL attack described is not
possible.]
ASCII Armored files include PGP keys, detached signature files and PGP
encrypted files.
It is possible to wrap a specially formed ASCII Armored file around a file
with arbitrary name and contents. When the armored file is parsed by PGP,
the binary file will be 'extracted'.
Because of a potentially dangerous behavior inherent in the way that the
Windows operating systems load DLLs, if the 'extracted' file is a DLL, a
number of applications can be 'fooled' into loading the rogue DLL and
therefore executing malicious code.
It should be stressed that this DLL loading behavior is not due to any
error in PGP, but is rather a behavior inherent in the Windows operating
systems, affecting almost every major windows application.
Before explaining in further detail exactly how this can be achieved, the
role of ASCII armored files should be more fully explained.
PGP ASCII Armor Files:
Using PGP it is possible to digitally 'sign' a document with a private key
that only the person signing the document has access to. This process
produces a signature file (.sig) with a name corresponding to the document
signed.
This 'signature' can subsequently be verified by anyone who has:
1) The signed version of the document
2) The signature (.sig) file, and
3) The public key corresponding to the private key that was used to create
the 'sig file.
The strength of the mechanism lies in the fact that public keys can be
freely disclosed without disturbing the security of the process; the
private key is used to sign a document and the public key to verify the
signature. It is currently computationally infeasible to derive the
private key from the public key, so this signature/verification process
provides a digital mechanism by which it can be demonstrated with a
reasonable degree of certainty that a given individual signed a document.
Both public keys and detached signature files can be stored in a format
known as 'ASCII armored'. This is a text-based format that is generally
easy for editors on most operating systems to handle. A file encrypted in
PGP can also be stored in ASCII armored form, to better facilitate
transmission through email gateways.
When an ASCII armored file is parsed in the versions of PGP under
discussion, the ASCII armor parser processes the contents of the file. A
behavior of this parsing code causes an armored file constructed in a
deliberate, malicious manner to create an arbitrary file, normally in the
current working directory of the process. This can be a number of
different directories depending upon how the user has invoked the parser,
but is likely to be one of:
1) The 'system' temp directory (c: emp, /tmp or other directory depending
on OS)
2) The directory containing the armored file
3) The working directory of an email client
The created file can have an arbitrary name and arbitrary contents. It
could, for example, contain a Trojan horse program, a Perl script, a
forged version of a document or a program designed to attack the integrity
of PGP itself.
It should be borne in mind, however, that on UNIX platforms this file is
created with the 'execute' bit turned off; this greatly mitigates the risk
associated with this issue.
It should also be noted that immediately after the file is created, most
versions of PGP would alert the user with an error such as, "Found no PGP
information in these file(s)". This is a simple means by which the
behavior can be detected.
The behavior occurs because the ASCII armor parser (implemented in the
file "pgpPrsAsc.c") will extract a binary file that it encounters in a
normally ASCII - armored file type.
We illustrate the seriousness of the issue using the example of the
current commercial distribution of PGP, 7.0.3, maintained by PGP Security
Inc., running on the Windows platform.
Windows DLL Loading Mechanism:
Due to the manner in which the Windows operating systems load DLLs
(Dynamic link libraries) a malicious dll file created using the bug
described above to can be loaded the next time the user performs either of
the following actions:
1) Opens an application, such as a Microsoft Office application, Adobe
Acrobat or WinZip by opening a file in the directory containing the
malicious .dll
2) Verifies a pgp .sig file in the same directory as the .dll
This behavior can be achieved by creating a .dll with the appropriate
entry point functions and naming it 'clbcatq.dll' or 'ntshrui.dll' (in the
first case) or pgpsc.dll (in the second).
The applications load the malicious .dll because they require a .dll file
of the specified name and the .dll in question is not in the 'KnownDLLs'
registry key. Windows therefore searches the current working directory of
the process for a dll with the desired name; since the malicious .dll has
the correct name Windows loads it and the 'entry point' function in the
malicious dll is called.
When an application is started by clicking on a file type that it
'handles' in Windows Explorer, the current working directory of that
application is set to the directory containing the file.
An example .sig file is provided that, when 'verified', will create a file
called 'pgpsc.dll'. When loaded, this dll will pop up a message box
containing the text "The signature is valid". When the message box is
acknowledged, the .dll will terminate the process that loaded it. This
sig file can be renamed '.asc' (the standard extension of exported PGP
public keys), and will elicit the same behavior.
Thus, after the first time the example signature file is verified, the
message box will be popped up whenever any signature file is verified in
the directory containing the dll. This message box could of course be made
to look exactly like the message box popped up by PGP when a signature is
correctly verified.
Vendor Responses:
PGP Security takes all issues of this nature seriously. We appreciate
@stake's professional handling of this matter allowing us the time to
produce a patch for our users.
The existence of viruses and Trojan horses on the local machine is a
well-known way to damage the security provided by PGP, and we have
documented this in the "Vulnerabilities" section of our "Intro to Crypto"
guide distributed with every copy of PGP for many years now.
While protecting local machine security against such threats is the job of
virus scanners, PGP Security feels that there are some rare cases raised
by the advisory where this Windows problem causes particularly adverse
behavior in PGP.
To correct this behavior, PGP has issued a patch. Users may download the
patch at the following URLs:
Patch:
PGP Desktop Security 7.0.4 Hotfix 1:
<http://download.nai.com/products/licensed/pgp/desktop_security/windows/version_7.04/hotfix/PGPDS704Hotfix1.zip>
http://download.nai.com/products/licensed/pgp/desktop_security/windows/version_
7.04/hotfix/PGPDS704Hotfix1.zip
PGPfreeware 7.0.3 Hotfix 1:
<http://download.nai.com/products/freeware/pgp/windows/version_7.03/hotfix/PGPfreeware703Hotfix1.zip>
http://download.nai.com/products/freeware/pgp/windows/version_7.03/hotfix/PGPfr
eeware703Hotfix1.zip
This patch will add all PGP DLLs to the KnownDLLs list in the registry. In
addition, it will notify users with the Save As dialog if any DLL is saved
in the course of parsing a PGP file. The registry patch will make certain
that none of PGP's DLLs could ever be subverted with this method. The
notification will help to ensure that users are aware that a DLL that may
belong to a third party application was extracted. Note that while this
patch solves the problem for PGP, it does not solve the problem for
Windows in general, and it is very likely that other issues of this nature
may exist in other Windows software.
These patches will be a standard part of future versions of PGP for
Windows.
Recommendations:
If a vendor patch is available, the patch should be applied.
If you are forced to run an unpatched, vulnerable version of PGP, steps
can still be taken to greatly mitigate the risk presented by this
vulnerability. On most operating systems it is possible to permit files in
a directory to be read from and written to, while denying all users the
right to execute those files. Simply revoking execute permission to all
directories that should not contain executable binaries will generally
address the issue. Executable install programs may need execution
privileges in a temporary download directory to run. A separate execute
privilege directory created for that purpose can be used for installing
software.
For example, when deploying a secure Windows 2000 or NT build, consider
denying 'execute' permission to the 'everyone' group in all directories
that should not contain executables; specifically (in this case)
directories that normally contain documents and temporary files.
Do not open untrusted PGP files.
Attachments that come from unknown sources should never be opened no
matter how benign they may appear. Be wary of those that come from known
sources as they may have been sent without the sender's consent via a mail
worm program.
Users should run up-to-date antivirus software on their client systems.
You should consider the benefits and risks of each attachment file type
that you let into your organization. Attachment file types that have
little business value should be dropped at your perimeter mail gateway.
All content that you allow to be forwarded into your organization adds
risk.
For attachment types that do have value but have known vulnerabilities you
should consider blocking them at your perimeter until you have eliminated
all of the vulnerable systems in your organization.
Attachments that you choose to forward on into your organization should
always be scanned for known malicious code using an antivirus product.
The following filename extensions commonly represent ASCII armored files:
asc (generic ASCII armored files)
pgp (PGP encrypted files)
sig (PGP detached signature files)
Windows application developers can work around the windows DLL loading
behavior using in the following ways:
1) By ensuring that all non-system DLLs that the application requires are
present in the directory containing the application's executable.
2) If this is not possible, perhaps because the application makes use of
the windows Explorer Shell Extension mechanism (as is the case with PGP),
consider adding the application's DLLs to the 'KnownDLLs' list, which is
supported on the windows platforms in the following ways:
Windows 95 as documented by MSDN KB article
<http://www.microsoft.com/technet/support/kb.asp?ID=151646> Q151646
Windows 98 as referenced to by MSDN KB article
<http://www.microsoft.com/technet/support/kb.asp?ID=193067> Q193067
Windows NT and 2000 as documented by MSDN KB article
<http://www.microsoft.com/technet/support/kb.asp?ID=164501> Q164501
This will ensure that the disk-based image of the DLL is 'mapped' at boot
time and that all requests for the dll will be serviced by the mapped
image, rather than by a (potentially malicious) dll loaded at the time the
application runs.
Consider a checksum or other integrity mechanism to check for modified
DLLs loaded by your application.
Proof of concept file:
When viewed, this .sig file will create a file named pgpsc.dll in the
current directory. You will need to delete this file when you are done
testing for PGP to properly operate.
<http://www.atstake.com/research/advisories/2001/notes.doc.sig>
http://www.atstake.com/research/advisories/2001/notes.doc.sig
ADDITIONAL INFORMATION
The information has been provided by <mailto:advisories@ATSTAKE.COM>
@stake advisories.
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to:
list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to:
list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any
kind.
In no event shall we be liable for any damages whatsoever including direct,
indirect, incidental, consequential, loss of business profits or special
damages.
- --------------------------END INCLUDED TEXT--------------------
This security bulletin is provided as a service to AusCERT's members. As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to use any or all of this information is
the responsibility of each user or organisation, and should be done so in
accordance with site policies and procedures.
NOTE: This is only the original release of the security bulletin. It may
not be updated when updates to the original are made. If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the original authors to ensure that the information is still current.
Contact information for the authors of the original document is included
in the Security Bulletin above. If you have any questions or need further
information, please contact them directly.
Previous advisories and external security bulletins can be retrieved from:
http://www.auscert.org.au/Information/advisories.html
If you believe that your system has been compromised, contact AusCERT or
your representative in FIRST (Forum of Incident Response and Security
Teams).
Internet Email: auscert@auscert.org.au
Facsimile: (07) 3365 7031
Telephone: (07) 3365 4417 (International: +61 7 3365 4417)
AusCERT personnel answer during Queensland business hours
which are GMT+10:00 (AEST).
On call after hours for emergencies.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
Comment: ftp://ftp.auscert.org.au/pub/auscert/AUSCERT_PGP.key
iQCVAwUBOtQ4aih9+71yA2DNAQGbjwQAmPJhvVDuabRFfuI8jRqt7zQP6Hctk651
8SPaNBphF+mJiTY9QRf0ob6UMBfq8xFEjTx9MgcasC/+kNBvCFYIR1lO990sO2eT
eDWyiH+BtpO2bXe9LYfE85cOVPVaqrAoGWEhQVgBijwcGO9wtdkHzSpKHwQMiDTq
ImaXZUUd5U4=
=AtW8
-----END PGP SIGNATURE-----