EFail mitigations for S/MIME

[martijn.list]

On 17-05-18 08:10, Andre Heinecke wrote:
> Hi,
> 
> On Wednesday, May 16, 2018 4:15:45 PM CEST martijn.list wrote:
>> On 15-05-18 14:31, Andre Heinecke wrote:
>>> - 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 don't propose to extend the standard. I would only reuse the the hash of a
> multipart/signed part in an S/MIME mail or from a signature in the case of
> files.
> 
>> 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?
> 
>  From your blog it sounds like this is only specified for multipart/signed
> inside the encrypted part. If it is signed can't you just check the signature
> and only show the signed parts?

No it works for general content types. The multipart/signed content type 
was only used for the example.

You can modify a block (16 bytes in case of AES128) without introducing 
a random block. Inserting a new block however will introduce a random 
block after the inserted block. For an attack you need at least two 
blocks (probably a lot more) so there is plenty of random data in the 
decrypted mime.

Because the attacker can modify the decrypted MIME, it is possible to 
remove the multipart/signed content type. For example by adding a number 
of newlines. The final decrypted message is therefore no longer a signed 
message so checking the signature will not work in the general case.

Kind regards,

Martijn Brinkers