Closed koto closed 9 years ago
From coruus@gmail.com on August 04, 2014 08:03:13
And a partial patch.
Disable Tag 9 packets for modern ciphers; disable OCFB without resync except as part of an MDC-protected packet; start to add some tests.
javascript/crypto/e2e/openpgp/ocfb.js: Disabled decrypting OpenPGP-CFB with resync disabled here; it should only be decrypted in conjunction with an MDC.
javascript/crypto/e2e/openpgp/ocfb_test.html: Changed test for no-resync case to an assertThrows.
javascript/crypto/e2e/openpgp/openpgp.js: Add list of insecure ciphers for which Tag 9 packets are supported.
javascript/crypto/e2e/openpgp/packet/symmetricallyencrypteddata.js: Check e2e.openpgp.InsecureSymmetricAlgorithms in SymmetricallyEncrypted.decrypt(). Split up SymmetricallyEncryptedIntegrity.construct() in preparation for adding encryption KATs.
javascript/crypto/e2e/openpgp/packet/symmetricallyencrypteddata_test.html: Add a KAT to make sure that prefixes are random. Initial work on KATs for decryption.
Attachment: tag9.patch
From evn@google.com on August 05, 2014 12:51:54
thanks coruus
Cc: adhintz@google.com koto@google.com
Labels: Component-Logic
From evn@google.com on August 05, 2014 13:13:35
lack of a warning kindof makes issue 110 a bit more interesting
From evn@google.com on August 05, 2014 13:18:44
Cc: r...@google.com
From coruus@gmail.com on August 05, 2014 13:46:20
Sent to GnuPG-devel, but either not broadcast yet, or not in archives yet: https://gist.github.com/coruus/be3c7e2c4e4dc155d2a2
From coruus@gmail.com on August 05, 2014 13:49:14
And: Here's the problem: https://gist.github.com/coruus/85dea6eb82897044f65d (It's possible to use an integrity-protected message to gain an advantage forging a Tag 9 message.)
From evn@google.com on August 05, 2014 14:57:15
Hi coruus
We decided that this issue (accepting non-integrity protected messages encrypted with some ciphers) was particularly sensitive (or at least, something that we think we should have provided within the library since day one) and is being considered in scope of the Vulnerability Reward Program.
As a small token of appreciation we decided to issue a small $100 USD reward (and if you decide to donate it, we'll double it). We would also be happy to list you on our Security Research Page to publicly recognize your help.
Thanks again!
Status: Accepted
From coruus@gmail.com on August 05, 2014 21:29:56
David here, by the way. You're welcome. :)
It's really been a pleasure contributing to this project; you guys have been terrific to work with. The biggest reward for me is making users safer (even with p ~ 2^-15).
Happy to be on the list. (I'll reply to the email I received in a bit.)
From evn@google.com on December 16, 2014 02:37:31
unrestricting access to this bug (impact was based on the consequences of this bug + Issue 110 ).
Labels: -Restrict-View-CoreTeam
That was fixed in bd14d9607e742cd94b1a5af39e0f9e8c454b4a32
From coruus@gmail.com on August 02, 2014 20:09:48
Is this report about the crypto library or the extension? Both.
What is the security bug? No warning on decrypting a message that uses a Tag 9 packet. (Even GnuPG warns.)
How would someone exploit it? Unclear.
(Two messages are attached to illustrate the behavior. The passphrase for both is "test".)
Fix:
UI side: Always warn (with, preferably, a difficult to click through warning, see Felt 2014), before showing decrypted plaintext that wasn't integrity protected.
Library side: Treat packets as invalid that use Tag 9 packets that cannot have been plausibly emitted by a legitimate user.
In particular, GnuPG will, so long as you choose AES (and a few other modern ciphers), always emit a Tag 18 packet and MDC unless you pass it the "--disable-mdc" switch (and, in addition, "force-mdc" is not set in your preferences). A Tag 9 packet encrypted using AES should not be treated as valid under any circumstances.
Reject all tag 9 packets. Tag 9 packets are only(?) needed because GnuPG's defaults result in it encrypting packets with CAST5 and no MDC in (unpatched) builds. Since you aren't yet in public release, GnuPG will have plenty of time to push a release with changed defaults.
(I'm not familiar enough with the UI code to implement the minimal fix fully, but I'm happy to provide a patch to the library side either way you decide to proceed.)
[Felt 2014] http://research.google.com/pubs/archive/41927.pdf
Attachment: tag9.asc tag18.asc
Original issue: http://code.google.com/p/end-to-end/issues/detail?id=124