Notice: Undefined offset: 1 in /usr/local/src/wordpress/wp-content/themes/montezuma/includes/parse_php.php on line 79

HowTo: ID and Avoid a TBird Bug, and Rake Your Email Client for Other Vulns

~~   Forward   ~~

All of us use a desktop email client to fetch our email, to respond, and to screen out spam.   When you click a link in an email, it will normally come up in your main web browser and take you to that site.   But there’s a way of crafting a link such that when you’re using Mozilla Thunderbird and click on a link, it opens the website in a Thunderbird tab instead of your default web browser.

Why is this a problem?   Because if you have hardened your browser to any reasonable level of security, all those protections are bypassed when the link is opened in a tab of TBird.   I use Iceweasel/Firefox with modifications from the TorBrowser, which include various configuration changes and addons to enhance security and privacy.   For example, addons I use are TorButton, NoScript, RefControl, HTTPS-Everywhere, RequestPolicy, AdBlock Edge, and Element Hiding Helper.   And I browse almost exclusively through TOR.   None of these security mechanisms is emplaced when links are opened in a TBird tab.

And, when a website opens in a TBird tab, there is no chrome around the window that would identify a malicious site spoofing part of the TBird interface.

~~   The Mechanism   ~~

Here’s how the malicious link could be crafted.   The email has to contain a text/html section, and that section must have an anchor embedded in an inline SVG.   That anchor has to have either target=”_blank”, or xlink:show=”new”, either of which will cause a new tab to be spawned.

With normal anchor tags you can right-click on a link in the email and “Copy Link Location”, then paste it into your browser.   But that option is not available when right clicking SVG anchors.

This vuln was reported to Mozilla three years ago and they accepted it as a ‘moderate’ security problem, but it still has not been corrected.   It seems that TBird is no longer in heavy development, so it may be time to look for another email client.

Note that SVG is key to this problem.   SVG is actually kind of a nasty little creature, and is not the benign flexible graphics format that most understand it to be.   When a malicious SVG image is attached to an email and the user clicks “View”, it opens in a new browser tab/window.   No big deal, right?   Images can’t execute code, right?   Actually SVG can.   SVG’s content type is ‘image/svg+xml’, and all it is is a wad of XML which describes the picture, but being XML it can also have JavaScript and CSS.   JPEG or GIF can’t cause any damage, but if you open an SVG in a text editor, you will get something like:
That could just as easily be:

So the moral is that files with a content type of ‘image/*’ are not always safe — or at least those of image/svg+xml are not.

~~   Other Email Vulns   ~~

What about other bugs and vulns in our email client?   These could allow the email sender to track the recipient, including their location and time the email was read, or start a process which tries to get out to a command & control server (though an open outgoing port) to download a rootkit.   These are common bugs, and are in most email clients.   Problems have been found in Outlook 2007, Apple Mail, TBbird 3, Android Mail, iPhone mail, K-9, and a universal bug in webmail clients concerning DNS pre-fetching.

There is an online tool which tests whether your email client is subject to any of these attacks.   Just enter your email address, and it will send you a specially formatted email that attempts to call back to the source server, by various methods.   You will then see the results on the tool’s webpage as they come in.   These are the exploits that advertisers and criminals use to track and perhaps infect targets.

~~   Why This Matters   ~~

Just one more example.   Several months ago I noticed that I was getting Shorewall firewall alarms that it was blocking something trying to get out port 3333, to a certain IP address in New Jersey.   Just hammering away at port 3333, but Shorewall wasn’t letting it out.

I reverse-ARPed it and found that one of that IP’s domains is .   I had just been reading TheOnion at that time, but there should be absolutely nothing trying to get out of my machine to their site, so I ran a scan and directory characterization on that IP.   I found that on port 3333 was listening a command & control server for a backdoor trojan;   the website for TheOnion had been compromised, and the hackers put malicious Javascript in their website, which would run a process on the machine of any visitors to the site!   A drive-by.   This process then reaches out port 3333 to the c&c server to download the backdoor, and who-knows-what-else.

I notified TheOnion right away that they had been compromised and gave details, but got back just a rote denial that anything was amiss.   Sure enough, two weeks later the news came out (in legitimate news outlets) that TheOnion had been hacked.   As I run Linux on this machine, it’s unlikely that their trojan would have even run, but it’s an illustration of how drive-bys work.

The moral is that with your firewall you must close ports outgoing, as well as those incoming.   Close every port out and in that you do not use.   On my regular machine I only have open outgoing TCP: bootpc, bootps, domaincp1, domaincp2, domaincp3, ftp, ftps, git, hkp, http, https, ircd, ircmoz, ircssl, radio, submission, svn, ubnt, whois, and UDP: bootpc, ntp

,'after' => '

') )