You are here
Securing Firefox, Chrome and Thunderbird against client-side attacks
Imagine someone half-competent wants to hack into your computer. They want to read your e-mail, steal your bitcoins, transfer funds via your PayPal account, etc.
You're behind a firewall (or more commonly a NAT router) and you don't have any open ports / servers running. So you're safe right?
Unfortunately, probably not. Because you're probably running a browser, or a native mail client and those tend to expose a huge volume of complex software to your evil adversary. Software has bugs. Some bugs are security vulnerabilities. Vulnerabilities can be exploited to subvert your computer into giving the bad guys access.
For example, to exploit your browser an attacker might social engineer you into clicking a link (e.g., in a forum post, or from an e-mail). This would expose your browser to a web application which abuses the wealth of information your browser broadcasts about itself to the world to identify the exact browser / operating system combo you are running and serve a targeted exploit which lets the attacker perform any operation at the operating system level that your browser process has permissions for (e.g., usually anything your user can do). Once the attacker has user level access, privilege escalation techniques (e.g., a kernel exploit) may be used to get full root access.
So let's say you're paranoid and you trust yourself never to click on a bad link (Ha!). Plus you run a native mail client because you don't trust cloud webmail providers such as Gmail with all of your e-mail.
Little do you realize that you are only one e-mail away from a security compromise. To exploit your native mail client the attacker will send you a specially formatted e-mail that targets an unpatched security vulnerability.
Obviously, these attack scenarios are much easier to carry out if you don't regularly install security updates or if a bad guy knows any non-public (AKA 0-day) security vulnerabilities such as the kind exploited in the Pwn2Own contest:
http://en.wikipedia.org/wiki/Pwn2Own
When confronted with this possibility, a common reaction is to dismiss it as impractical. I mean come on, how many people who have the capability to put together a "sophisticated" computer attack would waste their time on poor little me?
Unfortunately, there are ample ready-to-use security exploitation frameworks (e.g., metasploit) that it doesn't take much of a genius to learn to operate. To lower the bar further there are even Linux distributions dedicated to compiling all the popular attack tools into a nice little ready to use bundles.
It's very difficult to prevent attacks from competent experts, but with a little effort you can block most attacks from the vast leagues of amateur penetration testing hobbyists (AKA script kiddies).
Securing Thunderbird
Thunderbird is the most popular open source mail client. Few people realize it but Thunderbird has a less than stellar track record with regards to security. Since 2007 it has received 28 Ubuntu security updates, most including patches for multiple vulnerabilities. The good news is that this indicates an active effort to find and plug security issues. The bad news is that it also proves lax security standards to begin with and hints at an internal implementation complexity / attack surface that promises that many additional as-yet undetected security vulnerabilities are lurking in the code.
Countermeasures:
-
At minimum you'll want to keep Thunderbird up to date with the latest security updates.
-
Disable Javascript if you've enabled it (Javascript is disabled by default)
-
Stop broadcasting to the world exactly which version of Thunderbird you are running as that is going to make attacks easier to target.
Edit -> Preferences -> Advanced -> Config Editor
Right click, select "New -> String"
Enter "general.useragent.override", and leave the string blank.
Set extensions.enigmail.addHeaders to false.
Filtering identifying headers at the mail server level
With Postfix it's pretty easy to configure the server to filter out version leaking headers, like this:
$ grep header_checks /etc/postfix/main.cf header_checks = regexp:/etc/postfix/header_checks $ cat /etc/postfix/header_checks /^User-Agent:/ IGNORE /^X-Enigmail-Version:/ IGNORE $ postmap /etc/postfix/header_checks
Securing Firefox
The bad news is there have been many public remote exploitation vulnerabilities against FireFox. The good news is that FireFox's extendibility has allowed the community to develop a rich variety of countermeasures.
Countermeasures:
-
Keep up to date with latest security updates
-
FlashBlock module: Flash has an insane attack surface and historically more remotely exploitable holes than swiss cheese. This module replaces flash with a little icon you have to click on in order for the Flash code to run. Of course, this doesn't prevent attacks, but it does make unsophisticated attacks less likely to succeed.
-
User agent switcher module:
I recommend selecting Internet Explorer 8. It's a very common, highly exploitable browser that will tie up attackers with a nice big juicy diversion.
To prevent the User Agent from reseting when you close the browser you'll need to create a useragentswitcher.reset.onclose property and set its value to false:
-
In the address bar go to "about:config"
-
Right click -> New -> Boolean
Preference name: useragentswitcher.reset.onclose
Value: False
To install extended list of User Agents:
http://techpatterns.com/forums/about304.html
- save the XML file
- edit user agents -> import -> select XML file
-
-
no script module (run Javascript only on trusted sites)
Implementing these countermeasures also has a nice privacy boosting effect. It reduced my Panopticlick score from 1 in 1.6M (20 bits of unique information) to 1 in 1500 (just 10 bits of unique information).
Securing Google Chrome
The good news is that Google Chrome has a pretty good security record. It's the only browser that hasn't been exploited in the Pwn2Own contests.
The bad news is that there are probably many unknown security vulnerabilities lurking inside Chrome which due to its complexity has a significant attack surface. In fact, there have already been reports of successful 0-day attacks against Chrome that bypass all security mechanisms including the Sandbox.
Also note that in Linux the sandbox relies on operating system level mechanisms such as AppArmor which may not be setup on your system (as they are in Chromium).
Countermeasures:
-
keep up to date with latest security updates.
-
User-Agent Switcher extension: equivalent to the FireFox module, but doesn't seem to work, at least on newer Chrome versions (I tested on 12).
The alternative is to run google-chrome with the user-agent option:
cat > /usr/local/bin/google-chrome << 'EOF' #!/bin/sh /usr/bin/google-chrome --user-agent="Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1)" EOF chmod +x /usr/local/bin/google-chrome
-
NotScript extension: Chrome's NoScript equivalent with a somewhat better UI.
-
FlashBlock extension: Chrome equivalent of FireFox's FlashBlock.
Unfortunately, implementing all of these security measures still doesn't reduce my Panopticlick score, thanks in part to a particularly unique HTTP_ACCEPT headers (one in 63,781).
GOTCHA: Incognito mode doesn't make your browser any more difficult to identify or exploit.
Don't get smug: you're not invulnerable
Implementing these security countermeasures raises the cost of attack, making successful attacks less probable. But harder or less probable isn't impossible, or even very difficult.
In particular you shouldn't depend on anti-fingerprinting techniques to obfuscate browser vulnerabilities, though NoScript and equivalents can actually reduce the attack surface of your browser when you don't disable them to get extra functionality.
Sophisticated attackers may anticipate anti-fingerprinting countermeasures and either try to bruteforce around them (e.g., try non-Javascript exploits for all browsers), or develop improved fingerprinting techniques (e.g., identify browser by order of headers, etc.)
Sophisticated attackers may also be capable of running man in the middle attacks to exploit your browser's trusted relationship with existing sites (e.g., Google, YouTube).
For extra security, it would be best to implement additional countermeasures (e.g., run lower level security systems inside a VM, run public facing processes as a separate user in a jail, ASLR, etc.)
Add new comment