Viewable With ANY Browser

Note: My Web pages are best viewed with style sheets enabled.


PGP: Holes, Weaknesses, and Flaws

Copyright © 1998-2004, 2006, 2010 by David E. Ross

The ADK Problem

Private Key Vulnerability

The ASCII Armored Parser Vulnerability

Key Validity Vulnerability

Buffer Overflow in Outlook Plug-In for PGP

Chosen-Ciphertext Vulnerability

Buffer Overflow in PGP

Self-Decrypting Archives Are Vulnerable

Unsigned Data-Injection Vulnerability

PGP is Broken!

PGP bugs, with permission from Jim WillinghamEvery so often, someone reports a weakness or failure in PGP. Sometimes, these reports are legitimate. When they are, you should expect to see some kind of announcement by CERT or US-CERT two agencies (one at a university, the other part of a U.S. government department) that issue warnings about Internet and computer security. Preliminary, unevaluated reports might also be found at the Mitre Corporation's Common Vulnerabilities and Exposures (CVE) project. The lack of any such announcement should cause skepticism.

Sometimes, the report of a flaw in PGP indicates that Philip Zimmermann (the creator of PGP) has verified the report. Never believe that assertion if his name is spelled Zimmerman, with only one n at the end. Actually, I do not believe statements attributed to Zimmermann unless I can see his original message. When Zimmermann does make public pronouncements, he uses PGP to sign them.

The problems described below do not form a comprehensive list. These are only the problems that I have evaluated because they might impact my own use of PGP. Since I support the goal of Mitre's CVE project — to standardize the identification of computer vulnerabilities — I list the CVE number (if known) for each problem. I indicate candidate when the CVE team is not yet convinced the asserted vulnerability is real.

Where a problem is indicated as being fixed in a certain version, assume that it remains fixed in later versions. However, where a problem is indicated as not affecting a certain version, no such assumption should be made.

The ADK Problem


The ADK problem discovered in mid-2000 is an example of a real flaw in PGP. Carnegie-Mellon's CERT issued warnings, and Zimmermann had a signed statement confirming the flaw.

This vulnerability was corrected in PGP 6.5.8 and never affected PGP 2.6.x.

Private Key Vulnerability

(CVE-2001-0381) (candidate)

The private key vulnerability asserted by Vlastimil Klima and Tomas Rosa in March 2001 is quite different from the ADK problem.

This is still only a candidate as of 11 Feb 2010, nine years after it was first reported. I too remain unconvinced that this is a problem.

This vulnerability does not compromise secure encryption by PGP.
It has no impact whatsoever if your computer's hard drive is secured from external access.

The ASCII Armored Parser Vulnerability


This is a real problem, but the fault lies within the design of Micro$oft's Windows. Windows 95, Windows 98, Windows Millennium, Windows NT, and Windows 2000 all have the same design flaw. Some reports, however, described this as a PGP flaw and not a Windows flaw.

The term ASCII armored describes a character-based file that can actually represent a binary file (e.g.: an executable). PGP can encrypt files as ASCII armored and generate ASCII armored signature files. On this Web site, my PGP keys are ASCII armored. The problem was described by Network Associates as follows:

PGP allows the user to verify signed files from the Explorer window by double-clicking on the .sig file that represents the signature on the original file. It is possible for an attacker to create a .sig file that contains an arbitrary binary file. When the user double-clicks on the .sig file, the binary file will be extracted and written to the current directory.

If the extracted file is a PGP component DLL, it is possible that a PGP program could load the new DLL instead of the installed DLL, replacing the normal functionality with the new DLL that the attacker created.

Icon for an ASCII armored fileThat is, a file masquerading as an ASCII armored detached signature file — "constructed in a deliberate, malicious manner" (quoting the @Stake advisory) — might cause a substitute .dll file (application extension) lurking in the ASCII armored file to be written when the user attempts to verify the signature. The next time PGP needs to use a .dll file with that name, the substitute .dll might be used in place of the correct .dll file (located in C:\Windows\System) because of the Windows design flaw. The substitute .dll file might function as a virus, might compromise the user's private key or passphrase, or might execute in some other hostile manner.

Apparently, all versions from PGP 5.0 through PGP 7.0.4 for Windows have this vulnerability. Network Associates has provided patches for PGP 7.0.3 and 7.0.4, also described in the @Stake advisory. As described by Tom McCune, a necessary correction involves changing the Windows registry to force PGP .dll files to be obtained only from C:\Windows\System. This indeed is what the Network Associates patches do; those patches also implement a requirement for user intervention whenever signature verification results in an attempt to save an executable file.

On my own PC, I manually updated the registry to resolve this problem. The affected keys are described in Micro$oft "knowledge base" articles, the links for which are given near the end of the @Stake advisory. Note that any modification of a Windows registry is risky, especially for a user with little prior experience with the registry. I can provide update files for PGP 5.0 and PGP 6.5.8 if requested, but first I would need assurance that the requestor accepts all risks.

NOTE: Modifying the registry — manually, through my update files, or by installing Network Associates' patches — protects only PGP against this vulnerability. This does not protect against a hostile non-PGP executable being introduced onto your PC. Additionally, Network Associates' patches provide further protection against the introduction of hostile .dll, .vxd (virtual device driver), and .sys (system) files but not against other hostile executables. The only real protection is to be alert to any new file if verifying a signature results in an error popup with the message: "Found no PGP information in these file(s)."

This vulnerability does not compromise secure encryption by PGP.

Key Validity Vulnerability


A PGP key may have more than one user ID and thus be used for more than one E-mail address (or other identifier). It is possible for an "attacker" to add a false user ID to a legitimate public key. If that user ID is not signed by the key's owner, the key itself will appear valid if the owner signed at least one user ID and another PGP user then adds the key to his public keyring and signs it (or updates it after signing the key before the attack). As a consequence, the unsuspecting user might encrypt a message and send it to the attacker (to the spurious user ID) when the intended recipient is the key's owner. Lacking the corresponding private key, the attacker cannot decrypt the message; however, the message does not reach the intended recipient. Thus, the attacker uses this vulnerability to disrupt secure communication between two PGP users.

Protection against this vulnerability is easily obtained by checking to ensure that each user ID on a public key is signed by that key. As Network Associates said:

Whenever PGP displays validity information on a per-user ID basis, the display is correct. Thus, attentive users who examine the user IDs of all public keys which they import to their keyrings will immediately notice this problem before it could have any impact."

To restate two warnings that would be important even if this vulnerability did not exist:

This warning vividly illustrates why self-signing is important, not merely for a key but for each user ID of that key. For more details, see Walter Soldierer's Why should I sign my own public key?. Note that newer versions of PGP automatically self-sign newly generated keys and any newly added user IDs. However, PGP 2.6.x remains quite popular; these versions require manual self-signing.

This vulnerability does not compromise secure encryption by PGP.

Buffer Overflow in Outlook Plug-In for PGP

(CVE-2002-0685 )

A plug-in is a piece of software used to extend or enhance the capabilities of a larger application. A buffer overflow is an error in software in which the programmer failed to include a check to make sure data did not exceed its allowed space. Lacking this check, the plug-in that allows Outlook to encrypt and decrypt E-mail messages can become a gateway for an outsider to gain control of a computer by sending an excessively large encrypted message. The malicious sender of such a message can introduce hostile code into the computer of the victim.

Actually, this problem does not affect me because I use Eudora and not Outlook. I present it here only to illustrate just another of a long series of security problems afflicting Micro$oft products. Buffer overflow errors are especially common in those products, opening all kinds of security holes not only in Outlook but also in Word, Internet Explorer, and others. Further, Outlook is a notorious vehicle for spreading computer viruses, which is the reason that I often suggest to my friends and family that they replace Outlook with something less vulnerable (e.g., Eudora, Netscape).

In particular, this problem apparently affected PGP 7.0.3 and 7.0.4. NAI (at that time the developer of PGP products) released an updated PGPexch.dll, which provided the PGP interface with Outlook.

This vulnerability does not compromise secure encryption by PGP unless hostile code compromises the victim's private PGP key or logs the keystrokes of the victim's passphrase. This vulnerability does not compromise any PGP user who does not use Outlook or any of its clones.

Chosen-Ciphertext Vulnerability

(CVE-2005-0366) (candidate)

This is a variant of the classic "man in the middle" attack. Generally, such attacks involve a third party (Diane) intercepting an encrypted message between two persons (George the sender and Heather the addressee). Either Diane merely blocks Heather from receiving the message at all, or else Diane substitutes a fake message that looks as if George originated it. The first form of this attack is a denial of service; the second form is fraud.

The usual form of a "man in the middle" attack has Diane placing her public key on a key server with Heather's name in the user ID in order to fool the sender. Although the user ID names Heather, it contains Diane's E-mail address. Thus, when George sends the message, it goes directly to Diane and not to Heather.

The Chosen-Ciphertext Vulnerability, however, involves a more subtle attack. Here, Diane intercepts a properly addressed, encrypted message. Wanting to know its contents, she corrupts the message using a carefully chosen mathematical manipulation but without attempting to decrypt it. This manipulation effectively inserts what appears to be garbage into the encrypted message. After inserting her own E-mail address as the sender, Diane then sends the message to Heather.

Heather cannot decrypt the message because it is corrupted. When she attempts to decrypt the message, the single-session key alters the "garbage" inserted by Diane. Trying to diagnose the problem, Heather sees the message came from Diane. When Heather contacts Diane about the problem, Diane requests the message be returned. Heather sends Diane the unreadable result of trying to decrypt the message. Having chosen her mathematical manipulation very well, Diane easily reverses it and exposes the single-session key in the inserted "garbage". Having kept the original message sent by George, Diane can apply that key to decrypt the message without having Heather's private key or passphrase.

Intercepting messages is easy. Ask the FBI. But the rest of this vulnerability is also easy to avoid. Just don't be gullible. If you receive an encrypted message that is corrupted and cannot be decrypted, first erase the results of the failed decryption and then inform the sender and request that the message be sent again. If the sender requests that you return the corrupted message for examination, return the original as encrypted by the sender and not your failed attempt to decrypt it. (If the sender is an attacker, encrypting the latter with the sender's public key and returning it is the same as not encrypting it at all.) If the situation is innocent, the sender should have encrypted it to both your public key and his own public key. Let him try to decrypt it. If an attempted attack is underway, do not give the attacker any help.

This vulnerability does not compromise secure encryption by PGP.
At the worst, only the contents of a single message is revealed, not your private key or passphrase.
This is a vulnerability caused by weak human procedures and not by PGP.

Buffer Overflow in PGP


The attempt to decrypt an encrypted file with a very large file name can cause a buffer overflow in PGP itself. An intentional use of this error can result in the execution of hostile code. Preliminary information indicates this error exists only in PGP Corporate Edition 7.1.0 and 7.1.1 but apparently not in earlier commercial versions or in any freeware versions.

PGP provides secure transmission and storage of data. One basic security principle is: Know your associates! If someone is sending you a file so important that it must be encrypted, the sender must know you at least well enough to trust your public PGP key. But do you know him well enough to trust that he won't attempt a hostile action against you? You cannot rely entirely on software tools for security.

This vulnerability does not compromise secure encryption by PGP.
It is beleived corrected in PGP 8.x and later versions.

Self-Decrypting Archive Vulnerability

A self-decrypting archilve (SDA) is an executable file created by the PGP product. The executable is mostly an encrypted file — using a single-key encryption — plus code to decrypt it. The key is a passphrase entered when the SDA is generated and the input file is encrypted; it is entered again when the SDA is executed to decrypt the file.

An assertion was made in 2006 (and possibly before then) that a SDA can be decrypted without the passphrase. No vulnerability report can be found for this problem at CERT, US-CERT, or CVE.

A reasonable refutation appeared also in 2006. It appears that this might be a problem only with SDA executables received from hostile or malicious sources. Instead of being a true SDA, the executable is capturing the passphrase and sending it to a hacker.

I would not deal with SDAs that I have not generated myself. There is no real secure method of conveying the single-key passphrase except via the use of PGP's public-key/private-key capabilities. If both parties have that capability, they should instead use it to encrypt the subject file.

This vulnerability does not compromise secure encryption by PGP.
It is easily avoided by refusing to trust SDAs that you have not generated yourself and by using only public-key/private-key encryption when communicating with others.

The vulnerabilities listed above reflect a search of the CVE Project database using the term "PGP". The latest vulnerability listed in that database was assigned for evaluation on 22 February 2009. I also searched the US-CERT database in an attempt to find PGP vulnerabilities for which "PGP" does not appear as a searchable keyword in the CVE Project database.

11 February 2010

Unsigned Data-Injection Vulnerability

(CVE-2010-3618) (candidate)

The PGP Desktop user interface incorrectly displays messages or files with unsigned data as signed. This includes unsigned data (possibly malicious) inserted into previously signed messages and files. A user will not be able to distinguish the legitimate signed part from the malicious unsigned parts. On a PC with Windows, this also affects messages and files that are both encrypted and signed. On a Mac with OS X, this affects only messages and files that are both encrypted and signed but not those that are only signed.

This vulnerability affects PGP 10.x versions and may also affect some PGP 9.x versions. The Symantec Corporation (which now owns PGP) has patches available for paid versions of PGP Desktop 10.0.3 and 10.1 but has no plans to make those patches available for trial (freeware) versions of PGP 10.0.3 or 10.1. Users of freeware versions of PGP Desktop may want to revert back to an 8.x version even though Symantec now characterizes such versions as "End of Life".

Symantec recommends the following workaround for PGP used with Windows on a PC:

If you use PGP Desktop for Windows, do not use the Decrypt & Verify shortcut menu available when you right-click an OpenPGP message file. Instead, launch PGP Desktop, select File->Open, browse to the file name, and open the file. Alternately, double-click the file icon to have it opened in PGP Desktop automatically.
Although this vulnerability also affects PGP Desktop used with OS X on a Mac, a workaround for Macs has not been suggested. None of the vulnerability alerts mention whether this problem applies to PGP Desktop used with UNIX or Linux; thus, no workaround has been suggested for those systems. (I do not know if there are PGP Desktop 10.x versions for UNIX or Linux.)

This vulnerability does not compromise secure encryption by PGP.
It compromises the ability to use digital signatures to verify the integrity of files and E-mail.

The problem can be avoided by Windows users by following the suggested workaround.
However, the best solution is to obtain and install the patch from Symantec, available only for paid installations.

PGP is Broken!

It is difficult to address such a statement. The following claims remain unsubstantiated:

Last updated 30 November 2010

Valid HTML 4.01