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