                             @stake, Inc.
                            www.atstake.com 

                           Security Advisory

Advisory Name: Windows PGP (Pretty Good Privacy) ASCII Armor Parser 
	       Vulnerability
 Release Date: 04/09/2001
  Application: PGP (Pretty good privacy) Version 5 to 7.0.3 (latest)
     Platform: Windows 95, 98, Millennium, NT, Windows 2000, but see
               'Vulnerable Versions' section below.
     Severity: Opening an ASCII armored file such as a public key or a
               detached signature can cause the creation of an arbitrary
               file on the target machine. On the Windows platform
               this can lead to the execution of arbitrary code on the
               target machine.
       Author: Chris Anley [ dec0de@atstake.com ]
Vendor Status: Vendor has issued patches
          CVE: CAN-2001-0265
    Reference: www.atstake.com/research/advisories/2001/a040901-1.txt 


Overview:

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 behaviour 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:

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 behaviour 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 behaviour is not due to any
error in PGP, but is rather a behaviour 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
behaviour 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:\temp, /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 will alert the user with an error such as, "Found no
PGP information in these file(s)". This is a simple means by which the
behaviour can be detected. 

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

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.

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

Vendor Responses:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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:

PGP Desktop Security 7.0.4 Hotfix 1:
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/hot
fix/PGPfreeware703Hotfix1.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 which 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.

PGP Security, Inc.
April 8, 2001

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.4

iQA/AwUBOtFGMBxfqn6wxlmOEQJalwCfce+XBqxEjHFPVd9SR5FcnbhkDp8AniPR
ncl9VTZuxKekIhFf+6RmKFMs
=1Fks
-----END PGP SIGNATURE-----


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 seperate 
execute privilge 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
remediated 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
behaviour 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 Q151646
(http://support.microsoft.com/support/kb/articles/Q151/6/46.ASP)

Windows 98 as referenced to by MSDN KB article Q193067
(http://support.microsoft.com/support/kb/articles/Q193/0/67.ASP)

Windows NT and 2000 as documented by MSDN KB article Q164501
(http://support.microsoft.com/support/kb/articles/q164/5/01.asp)

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   

Common Vulnerabilities and Exposures (CVE) Information:

The Common Vulnerabilities and Exposures (CVE) project has assigned
the following name to this issue.  This is a candidate for
inclusion in the CVE list (http://cve.mitre.org), which standardizes
names for security problems.

     CAN-2001-0265


Advisory Release policy: http://www.atstake.com/research/policy/ 
For more advisories: http://www.atstake.com/research/advisories/ 
PGP Key: http://www.atstake.com/research/pgp_key.asc 

Copyright 2001 @stake, Inc. All rights reserved























