Bug: Thunderbird allows sender-provided CSS to style the reply and forwarded message
Status: NEW
Priority: --
Created: 2021-01-25 15:44:44+00:00
Resolved: 2022-11-06 12:51:27+00:00

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:84.0) Gecko/20100101 Firefox/84.0

Steps to reproduce:

1. Send/import the following HTML email to Thunderbird:

```
MIME-Version: 1.0
Content-Type: text/html; charset=us-ascii

<html>
  <head>
    <style type="text/css">
      p { font-size: 0; }
      p::before { content: 'Yes, I do.'; font-size: initial; }
      p + p { display: none; }
      p[_moz_dirty] { display: block; font-size: initial; }
      p[_moz_dirty]::before { display: none; }
    </style>
  </head>
  <body>
    <div>Hello, do you like my proposal?</div>
  </body>
</html>
```

2. Reply to or forward this message with HTML: Click on "Reply" or "Forward" with Shift pressed if you compose messages as plaintext by default. Type something like "No, I don't." into the compose window with the Paragraph style, then click "Send".


Actual results:

The recipient sees "Yes, I do." instead of the "No, I don't.", which the sender wrote. The reason for this is that Thunderbird doesn't restrict the CSS of the quoted message to the quoted message. Instead, the response looks as follows:

```
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>No, I don't.</p>
    <p>I think it's bad.<br>
    </p>
    <div class="moz-cite-prefix">On 25.01.21 15:53, <a class="moz-txt-link-abbreviated" href="mailto:test@ef1p.com">test@ef1p.com</a> wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:7qazbuqvovy6tw5wwoe9dg@ef1p.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <style type="text/css">p { font-size: 0; }p::before { content: 'Yes, I do.'; font-size: initial; }p + p { display: none; }p[_moz_dirty] { display: block; font-size: initial; }p[_moz_dirty]::before { display: none; }</style>
      <div>Hello, do you like my proposal?</div>
    </blockquote>
  </body>
</html>
```


Expected results:

The recipient should see what the sender wrote. If Alice sends a message to Bob and Bob forwards or replies the message to Carol, then Carol should see what Bob wrote and Alice shouldn't be able to change that. The current situation allows Alice to engineer fake approval/authorization from Bob or to simply insult Carol as Bob, which might cause problems for Bob. The attack isn't perfect: The message preview, which doesn't render CSS, shows Bob response. And of course, Bob and Carol can figure out what is going on by inspecting the raw message.

If you're not convinced that this is a security issue, removing the lines with `p[_moz_dirty]` make this at the very least a usability issue as Bob can no longer compose his message. Please note that I tailored this attack for the "Paragraph" style. If the reply is composed in the "Body Text" style, then the above CSS won't work. I didn't invest the time but I'm confident we could make the attack work no matter the chosen style.

Solution: The easiest fix would be to use `<style scoped>` in the quoted message – if only this was kept in the standard and got implemented by everyone. Without this, I think the best fix is to prefix all CSS rules in the quoted message with an ID that is generated for the `<blockquote>` element. Apple Mail inlines the CSS rules with the `style` attribute and Gmail doesn't copy the `<style>` element from the `<head>` into the reply at all.

Note that another vendor is affected by a similar issue, which I've already reported. Even if you don't think this is a security issue, please don't declassify this issue without my explicit consent. Depending on how things develop, I'm aiming for a coordinated disclosure and I will inform you about the timeline of the other vendor.

PS: I saw that someone else reported presumably the same underlying problem but without the security implications in bug 1668774. In order to keep these implications confidential for now, I've decided to open a new bug report rather than to comment there.