700979 - Can force webpage links to open in Thunderbird Tabs

Status: NEW

(Thunderbird :: Message Reader UI, defect, P1)

Description

[Mike Cardwell]

Attachment: svg_test_email.txt

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0
Build ID: 20111104165243

Steps to reproduce:

Normally, when you click a link in an HTML email, Thunderbird will tell your default browser to visit that page. It is possible however to get Thunderbird to open the page in a Thunderbird tab instead though, if you use an inline SVG image. Here is an example SVG with two such links:

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1">

  <a xlink:href="https://www.mozilla.org/" xlink:show="new">
     <text x="0" y="12" font-family="Verdana" font-size="12" fill="black">link 1</text>
  </a>

  <a xlink:href="https://www.mozilla.org/" target="_blank">
     <text x="50" y="12" font-family="Verdana" font-size="12" fill="black">link 2</text>
  </a>

</svg>

I have attached a full example of an email which does this.

I will mark this ticket as "hidden" initially, in case there are any security implications of being able to open remote pages within the context of Thunderbird.

There is definitely the problem that using this method an attacker could get you to open a page without any security defences that your default browser might have, such as NoScript, proxy configuration, Tor usage etc.

Comment 1

[Daniel Veditz [:dveditz]]

Since there's no protocol on an in-line message to know how to load it remotely this is probably by design, but we need to make sure we have a safe principal for this content. If the SVG image had <script> tags would the scripts run (they wouldn't as an image, but might as a document)? If they ran would they have a safe principal?

Comment 2

[Mike Cardwell]

I already tested sticking script tags within an inline SVG. I also tested using a multipart/related SVG attachment which contains script, and embedding that in the HTML part of the email using Content-Id/CID:. In neither case was the script executed, thankfully. I also tried using CSS to pull in remote content for both of these SVG tests, to try and bypass the default remote content block, and again, that didn't work.

A URL that is opened within Thunderbird in a new tab, using this SVG link method, happily executes script, but I don't think that is a problem? I looked at the attributes on the "window" object and I didn't see anything there unusual.

As an end user, when I click a link in an email in Thunderbird, I expect it to open in my browser, not in Thunderbird. My browser has numerous security extensions installed and runs under a different UID to Thunderbird. This "flaw" allows an attacker to bypass those defences.

I wonder if you could abuse this technique as part of a wider phishing attack also? You have complete control over the content of the new tab that is opened, so it should be possible to create a second fake email display tab, or calendar tab.

Comment 3

[Daniel Veditz [:dveditz]]

I completely misunderstood and thought the SVG "image" itself was what was being opened in a tab, like other inline images. You mean the mail contains links to random urls and those urls open in Thunderbird, as opposed to what happens with the same <a href=""> in an HTML mail.

This is a bug. Lacking a URL bar of any kind this is also way too prone to spoofing, whether as some other site or even part of the Thunderbird UI itself (which is using tabs a lot these days).

Comment 4

[Mike Cardwell]

That is what I meant yes. The SVG displays inside the normal email display, just like a normal image, but the SVG contains anchor tags. Clicking one of those links does actually open the URL in your default browser *unless* you add one of these two attributes to it:

xlink:show="new"
target="_blank"

Then, the URL opens in a Thunderbird tab instead. I tested the target="_blank" attribute with a normal non-svg anchor tag, and it processed that one correctly, opening it in my default browsers window. It's only when it's used inside an SVG anchor tag that it does this. The example email I attached to this bug demonstrates the problem.

Like you said, this could be potentially abused to spoof parts of the Thunderbird UI. It can also be used to bypass your default browsers security mechanisms.

Comment 5

[Mike Cardwell]

This is just a heads up. I write a technical/security blog and intend to write this up at some point next week. I think 26 months is a long enough period for responsible disclosure ;)

Comment 6

[Al Billings [:abillings - ex-MoCo]]

You actually discussed it publicly on the Tor developer email list today.

Comment 7

[Al Billings [:abillings - ex-MoCo]]

Blog post is at https://grepular.com/Security_Bug_Thunderbird_Websites_Tabs.

Commenter there notes: 'It applies only to the "View Message Body As Original HTML".'

Comment 8

[Mike Cardwell]

Yes. I did. Shortly after I wrote the blog post I stated I would.

Comment 9

[Al Billings [:abillings - ex-MoCo]]

A Tor thunderbird user (Torbirdy) commented on their discussion list:

"When I opened that email and set View/Message Body As/Original HTML, 
Torbirdy did not prevent the tab to load nor refuse to display the HTML."

So, HTML is displayed but not without user interaction to view the original HTML.

Comment 10

[Jim Porter (:squib)]

Attachment: Fix it

It turns out this is pretty easy to fix, actually. Here's a patch that works, but probably needs more tuning, e.g. catching similar cases for MathML. Also tests would be good. I'm not sure if I'll be able to do any more with this before next week though, so other enterprising folks are welcome to take over.

Also, I fixed the indentation and brace style in the file because it was gross.

Comment 11

[Mike Cardwell]

I think a couple of comments by "Al Billings" above just confuse matters a little. So to clear things up: All that needs to happen in order for this bug to be triggered is:

1.) User installs Thunderbird
2.) User receives email
3.) User clicks link

"View Message Body As Original HTML" is *the default* in Thunderbird. "TorBirdy" is an addon that a tiny minority of Thunderbird users use, and which changes that default to viewing messages as plain text. When messages are viewed in this non-default configuration, the bug apparently isn't triggered.

Comment 12

[Ben Bucksch (:BenB)]

News article: http://www.networkworld.com/community/node/84683

EDIT: new URL for this article:
* https://www.csoonline.com/article/546436/microsoft-subnet-flaw-in-thunderbird-bypasses-firefox-torified-security-and-privacy-defenses.html
* https://web.archive.org/web/20191002014337/https://www.csoonline.com/article/2226217/flaw-in-thunderbird-bypasses-firefox--torified--security-and-privacy-defenses.html

Comment 13

[Ben Bucksch (:BenB)]

As the patch: If we're serious about fixing this, we need to catch all cases, present and future, without exception. I don't think we can achieve this by listing all ways that a link can be expressed, because we're sure to miss one sooner or later.
Rather, we should catch all link clicks, e.g. on a DocShell level or similar container level, independent from content, and then treat all links as external, unless they meet certain criteria for internal links. I.e. whitelist instead of blacklist.

Comment 14

[Wayne Mery (:wsmwk)]

Despite this having been disclosed, it seems like we should have a plan to act on this?

Comment 15

[Kai Engert [:KaiE:]]

(In reply to Ben Bucksch (:BenB) from comment #12)

News article: http://www.networkworld.com/community/node/84683

http://web.archive.org/web/20140723054655/http://www.networkworld.com/article/2226217/microsoft-subnet/flaw-in-thunderbird-bypasses-firefox--torified--security-and-privacy-defenses.html

"Flaw in Thunderbird bypasses Firefox 'Torified' security and privacy defenses"

So instead of opening a link in the default web browser, which might have been carefully configured with privacy/tracking protections, the link is instead opened in Thunderbird, which might not have those browsing protections.

BenB said, it's tricky to catch all scenarios. However, some of those pages are supposed to be opened with the TB internal browser (in a tab).

Maybe we need a shielding, and prior to opening such a link in a tab, inform the user and ask them to confirm?