6 ms·
So what would you expect GPG to do when invoked to operate on a pipe (rather than a file¹)? Buffer (possibly) gigabytes of decrypted data in memory, just to be
by aepiepaey 8y ago
So what would you expect GPG to do when invoked to operate on a pipe (rather than a file¹)? Buffer (possibly) gigabytes of decrypted data in memory, just to be able to discard it once DECRYPTION_FAILED is detected?
¹: where GPG does the right thing
- tptacek 8y agoYes. It has one job!
- Xylakant 8y agoAren’t modern ciphers checksummed and authenticated blockwise? If so, you could just abort the moment you see a broken block. Anything before that block would not be under the attackers control and harmless.
- tptacek 8y agoModern AE schemes are designed to make it easy to quickly abort the whole decryption operation as soon as an error is detected. But the PGP protocol is from the 1990s, and uses vanilla CBC or CFB and then tacks the SHA-1 hash of the plaintext to the end of the message in a separate record.
- Xylakant 8y agoSo the reasonable answer for me would be “go forth and use a modern scheme by default.”
- rocqua 8y agoThe issue there is that if you call something PGP, people expect backwards compatibility, but if you switch to a different mode of encryption that becomes a massive pain.
- Xylakant 8y agoGood old SSH managed to update ciphers. This is certainly easier if Server and client can negotiate, but it’s not impossible for GPG. You could start by adding better modes as an option, later make them default and ask for confirmation when decrypting an old message format. If I read the vulnerability description correctly, it allows stripping the message authentication signature and then trick the client into decoding it. So any message sent with a modern cipher or just requiring message authentication by default would have substantially mitigated the attack.
- rocqua 8y agoIt is possible, but note that SSH is interactive and always had multiple ciphers. On PGP, as far as I can tell, there is no field for the cipher used. So you somehow need to introduce that field somewhere, but be able to deal with files that do not have that field. Possible but very tedious. The non-interactivity seems like it makes it harder to 'negotiate' a version. As there is no way to get clarification. At the same time, you need to be careful against downgrade attacks.
- Xylakant 8y agoSure, as I mentioned, it’s easier if you can negotiate ciphers. But on the upside, there’s no downgrade attack. If the sender uses a modern cipher, the receiver either supports it or can’t decode the message. Still, that’s not a hard reason to not introduce protocol changes like new ciphers and a new field. Funny that you mention that since currently GPG on my Ubuntu spits out warnings about some feature it does not understand in files encrypted with a newer GPG on my fedora. This actually trips up some of my tooling.
- sp332 8y agoRelevant comment from Werner Koch: https://twitter.com/FiloSottile/status/996011473112576000 https://twitter.com/FiloSottile/status/996011473112576000 Either GPG buffers the data and checks for DECRYPTION_FAILED, or the application depending on GPG does. Of the two options, it makes much more sense for GPG to handle this.
- tptacek 8y agoThis is shades of the curl maintainer rationalizing CURL_SSL_VERIFYHOST=1 not doing any checking, because CURL_SSL_VERIFYHOST=2 does.
- jwildeboer 8y agoDECRYPTION_FAILED should always result with an empty return. Not with the decrypted content.
- slrz 8y agoThe application is likely better equipped to do something reasonable if temporarily storing lots of data is in order. Still, GnuPG could do the buffering automatically for small messages and force explicit configuration otherwise. The latter might not be realistically enforcable given the compatibility constraints.
- eigengrau 8y agoIt might be prudent to have GnuPG return an error exit code instead of just printing a warning on stderr. Currently, it seems that clients (at least when using the shell interface) are supposed to parse the error stream. And even when they do (which many probably don’t), it’s not necessarily obvious that the presence of warnings indicates to the client that the data should not be used.
- shinigami 8y agoIt should split it in chunks and authenticate each one of them. Then the worst attack would be the ability to truncate the file, and it could be at least detected. Unfortunately this is not supported by the PGP spec, or any other well established spec.
- tptacek 8y agoWhat's happened here is that GPG has used the OpenPGP spec as excuse to support extremely insecure default behavior. In reality, GPG can simply buffer and check before writing to stdout, and, in the rare cases where messages are too large to buffer, a flag can be used to override the secure default.
- rocqua 8y agoIf the message is too large to buffer, one might also first just decrypt and stream the plaintext into sha-1. Once the MDC clears, you can just decrypt again, this time writing to stdout.
- tedunangst 8y agoThis is difficult if the input is a nonseekable stream, but that doesn't excuse producing bad output.
- tptacek 8y agoThat's why I didn't suggest it, but to be fair, you could tee the stream into an intermediate file for a two-pass scheme.
- shinigami 8y agoI agree they should have done that as a stopgap measure, but we should push for security in all cases (e.g. streaming AEAD with STREAM or CHAIN https://github.com/miscreant/miscreant/wiki/STREAM https://github.com/miscreant/miscreant/wiki/STREAM )
- julian37 8y agoIt could also buffer the ciphertext, doubling CPU time but meaning that message size is constrained by disk space rather than available RAM.
- deleted 8y ago[deleted]
- Natanael_L 8y agoYes. Show me the right message or nothing at all.