Note: My Web pages are best viewed with style sheets enabled.
|
Note: My Web pages are best viewed with style sheets enabled. |
Unrated |
The ASCII Armored Parser Vulnerability
Buffer Overflow in Outlook Plug-In for PGP
Chosen-Ciphertext Vulnerability
Self-Decrypting Archives Are Vulnerable
Every 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 CISA 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 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.
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.
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.
That 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 (Web site no longer available), 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.
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:
To restate two warnings that would be important even if this vulnerability did not exist:
This vulnerability does not compromise secure encryption by PGP.
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 Thunderbird 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.
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.
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.
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.
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
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.
It is difficult to address such a statement. The following claims remain unsubstantiated:
Sometimes the someone is The Government (presumably the U.S. government). However, every success by any agency of the U.S. government to decrypt an encrypted file either involved non-PGP encryption or else required access to the private PGP key and passphase (e.g., through physical access to the computer on which and while encryption occurred).
Sometimes the someone is not the government. However, challenges — in the form of asking that someone to decrypt sample encrypted files — remain unanswered.
The PGP Corporation makes its source code available for public inspection to prove that no backdoor exists. Anyone can take that source code, compile it, and compare the resulting version of PGP with the latest downloaded version of PGP. The PGP Corporation (and NAI before it) would have no market for its product if a backdoor existed.
The above statement is true only through PGP version 10.1.2 (build 9). Later versions were not made available for independent inspections.
The speed of a computer is limited by the speed of light; it takes a finite amount of time for a signal to travel the subatomic distance from the nucleus of a hydrogen atom (the smallest) to its electron. Further, the size of a computer is limited by the number of atoms in the universe. Even the recent development of quantum computing yields finite computational power. It is believed that future computers will still be insufficient to apply "brute force" methods to break PGP encryption. As computers become faster and larger, it is merely necessary to create PGP keys that are larger.
Last updated 29 January 2022
 Main PGP page |
 David Ross home |
 My PGP keys |
