Check alot for new crypto attacks

1. CMS attacks

Cryptographic Message Syntax (CMS) is a versatile standard for signed and encrypted messages within the X.509 public-key infrastructure. We found flaws in the handling of emails with contradicting or unusual data structures.

There is no support for X.509 in alot afaik, so not affected.

2. GPG API attacks

GnuPG is the most widely used OpenPGP implementation, but it only offers a very restricted command line interface for validating signatures. This interface was vulnerable to injection attacks.

The Python gpg module relies on the GPGME API and not the command line interface for this. Not affected.

3. MIME attacks

The body of an email is conceptually a MIME tree, but typically the tree has only one leaf which is signed. We construct non-standard MIME trees that trick clients into showing an unsigned text while verifying an unrelated signature in another part.

Not vulnerable (yet?)

A MIME tree like the following:

multipart/mixed
├── multipart/signed (with a valid signature)
└── anything not signed or with an invalid signature

Makes alot display the verification status of the first multipart/signed chunk. The other chunk isn't displayed at all as of today, but this might be in future versions as MIME tree rendering may be added. This will require changing the way the signature validity is displayed, to make it clear that only some parts are signed with valid signatures.

4. ID attacks

The goal of this attack class is to display a valid signature from the identity (ID) of a trusted communication partner located in the mail header, although the crafted email is actually signed by the attacker.

Not tested yet.

5. UI attacks

Email clients indicate a valid signature by showing some security indicators in the user interface (UI), for example, a letter with a seal. However, several clients allow the mimicking of important UI elements by using HTML, CSS, and other embedded content.

The signature verification status appears similarly to a PGP-Signature header in the thread view.

Adding a PGP-Signature: Valid: Someone <some@address> doesn't cause it to be visible by default. However, when displaying all headers with :toggleheaders, this extra header is indistinguishable from a genuine indicator inserted by alot.

The UI should perhaps make a clear distinction between envelope headers and indicators computed and added by alot, perhaps by introducing a separator or by using some different colours.

pazz / alot