danger of decrypted files without integrity protection

[Holger Smolinski]

Am 17.05.2018 um 10:26 schrieb Bernhard Reiter:
> Pondering how dangerous manipulated decrypted files are
> I've done the following experiment on a GNU system:
>
> echo "File loading external references? Yes, if you can see the following image: <img src=https://gnupg.org/share/logo-gnupg-light-purple-bg.png />" >test.html
> firefox test.html 
> chromium test.html 
>
> both times the image was shown.
>
> [...]
>
> Seems decrypted files that had no integrity protection are
> dangerous because they could be manipulated to send decrypted
> plaintext anyware once the users opens them.
>
> Best Regards,
> Bernhard
As far as I understand efail, there are two variants.

1st variant is attacking plain or multipart encrypted messages
by wrapping them into a multipart message, which afterwards
causes the mai client to leak the decrypted content.
- For this variant there is not much GnuPG can do, as long as
its scope remains confined to encrypted message bodies and
mail parts. The 'proper' way to fix this would be fixing the mail
clients to strictly respect boundaries between parts of multipart
messages.

2nd variant is attacking CFB mode by injecting CFB gadgets that
decrypt to some markup, which cause the mail client to leak
decrypted content. This should be easily prevented by proper
signature verification as the gadget injection leads to modified
plaintext.
- email clients should guide users to use encryption only with
signed contents AND verify the signatures before parsing the mail.
- GnuPG could refuse (or: require --force) to encrypt without signing,
but this might also break other existing legitimate use cases.
- CFB/CBC could be replaced in the standard by operation modes that
are not vulnerable to gadget injection. But we still would need to
support legacy modes for old encrypted mail decryption for a while...

I'd object GnuPG to generally interpret email message formats, also
because we cannot gracefully handle suspicious results.

Beyond that, I could imagine a more secure email transport protocol,
which generally prohibits any modification of documents by attackers.
This can be achieved by true and mandatory end-to-end encryption
and content signing.

Regards
    Holger


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180517/8de5425d/attachment.sig>