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: firstname.lastname@example.org In order to subscribe to the mailing list, simply forward this email to: email@example.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: firstname.lastname@example.org 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-----