EFail mitigations for S/MIME

[martijn.list]

On 15-05-18 14:31, Andre Heinecke wrote:
> Hi,
> 
> It think Bernhards mail can be summed up further. To check that the encrypted
> data was not manipulated we only need:
> 
> - Any hash over the plaintext.
> 
> To get such a hash we can most easily use a signature, regardless of any trust
> in the signature. The hash does not need to be encrypted.
> 
> If we have no hash we won't offer to save a decrypted file from a GUI or show
> it in an HTML enabled mail client. This would disallow encrypt, then sign
> schemes but in practice everyone uses sign then encrypt anyway.

Adding a hash will not help in the general case because other S/MIME 
clients will not support it.

I have done some experiments with the "Generic exfiltration" attack and 
have been able to replicate the attack. Injecting new blocks is easy. 
However after every injected block, there is a block of random data. 
This block of random data can be used to detect whether the message was 
attacked with EFAIL in most cases. The S/MIME RFCs strongly suggest that 
every MIME part should be 7-bit. If a decrypted message therefore 
contains data > 127 or < 32 excluding CR/LF/TAB, the message might have 
been injected with additional blocks. For the "Generic exfiltration" 
EFAIL attack, you need at least 2 blocks of data so there will be at 
least 32 bytes of random data. The changes that all those bytes fall 
within the 7-bit range is slim so I think this check would work to 
detect most (if not all) EFAIL attacks. The only problem you might run 
into is if a sender encrypted a message containing 8-bit characters 
(i.e., the message was not canonicalized to 7-bit).

I have written a short blog item about this here

https://www.ciphermail.com/blog/efail-how-to-detect-you-are-being-attacked.html

Any comments on whether this will work?

As we speak I'm working on such a check.

Kind regards,

Martijn Brinkers