The Definitive Guide For Securing Firefox

This is part 1 in a series where I’ll be detailing various settings for specific programs and operating systems. I’ll be writing a guide for Chrome, Firefox, Windows Vista/7/8, and Ubuntu 12.04 (maybe other things I can think of.) The guide will cover everything I can think of and will cover both system compromise, in-program compromise, and privacy concerns. I won’t cover all subjects today, probably just Firefox and Chrome.


Firefox is the free and open source browser developed by Mozilla. It focuses on user-oriented features like a customizable UI and ensuring user satisfaction through an interactive developer community.

By default without any plugins Firefox is fairly secure in that it makes use of modern mitigation techniques and is quick to patch. This guide will go over some Firefox extensions that you can install as well as  settings that you can change to improve security and privacy.

Privacy Settings

First up we’ll change our privacy settings to include the Do Not Track header, which I recently posted about. We’ll also be disabling third party cookies as these are typically only ever used for tracking users (though they can have legitimate uses, like logging into websites via third party logins).

Firefox -> Edit -> Preferences -> Privacy

It should look like this after you’ve changed the settings:


Security Settings

From the privacy tab you can click the next tab – Security.

Here we can set our master password. This password will encrypt all others so that if anyone gains unauthorized access to your system they will no be able to gain access to your information.

See this guide for creating a strong password.

Content Settings

Firefox lets you allow or deny Javascript throughout the browser in the content settings page. Disabling Javascript will break many sites but it will improve security – I recommend NoScript instead.


NoScript is an extension developed by Giorgio Maone. NoScript is a default-deny system that blocks a webpages ability to run scripts or plugins. It also makes use of a strict XSS filter and clickjacking prevention.

By default NoScript blocks the following:


This renders most attempts at exploiting the browser unsuccessful and will protect even whitelisted pages fairly well.

The problem with NoScript is that there is a ton of user interaction required. You have to whitelist every site you want to visit. It’s a pain. But if you’re after high level of security that’s what I recommend. If you globally disallow (default) you’ll benefit even when you whitelist a website.

Even if you hate the interaction I highly recommend you install NoScript and turn on the “Allow Scripts Globally” feature because it will still provide further improved security.

With NoScript ‘Allow Scripts Globally’ you miss out on the full extent of its protection but even then you’ll benefit from a few really great protections such as:

The XSS Filter – NoScript’s XSS is kinda the XSS Filter to compare all other XSS Filters to.

ClearClick – Clickjacking is a method used by attackers to trick a user into clicking a hidden or invisible ‘button’ that can lead to an exploit page or even a bank transaction. ClearClick is the only protection for this currently implemented.

CSRF Protection – CSRF is harder to explain. It attacks from the users end of the system so it can do things like get into your email account and bypass protections because it all originates from ‘you.’

MITM Protection – Man In The Middle attacks happen when, simply, the attacker is between you and the server. SSL is the typical solution but you can spoof certs and hijack even SSL communications or just attack mixed content transmissions. NoScript implements multiple protections here.

So, there you have it. Even with Scripts Globally Allowed NoScript is going to make your Firefox much more secure.


HTTPS-Everywhere is an extension developed by the EFF (Electronic Frontier Foundation) that aims to force HTTPS on all sites that make it available.

Many sites, like wordpress, offer HTTPS but don’t default to it. HTTPS-Everywhere will block and redirect requests so that you end up using the HTTPS version.

HTTPS means that the traffic between you and the server is encrypted. That means that no one besides you and the server gets to read or manipulate the data.

This prevents MITM attacks that can be used to sniff passwords or even compromise the machine by redirecting your request to an exploit page.


Convergence is an extension that aims to solve many of the issues we see today with SSL and MITM attacks.

Check out this explanation on it here.

It hasn’t been updated in ages, and I’m not even sure if it’s supported anymore, so take this tip with a grain of salt – results may vary.

AppArmor (Linux Only)

I’ve written a guide for AppArmor already but I’d like to highlight that Ubuntu comes with a Firefox profile by default. It probably needs a bit of tweaking but if you follow the guide it’s easy to set up.

To set your apparmor profile to enforce simply enter:

# aa-enforce /etc/apparmor.d/usr.bin.firefox

Afterwords your Firefox will be held in a tight sandbox, which will prevent and contain exploits.


Adobe Reader is one of the most commonly exploited applications and although it has improved you may want to check out PDF.JS.

You can use this simple extension to install it and Firefox will handle PDF through Javascript.

You can read more about PDF.js here.

PDF.js is arguably less secure than Adobe Reader as Reader will run within a sandbox. The goal of PDF.js is to reduce attack surface by having PDFs rendered by the Javascript engine already present in Firefox.


Always make sure to keep Firefox and all of its plugins up to date. This is critical on Windows where out of date plugins consistently lead to compromise.

And Please…

Firefox is not my default browser and hasn’t been for over a year now. If you know of any other methods for securing it please leave me a comment and I’ll try to fit it in. Thanks.

Compile And Patch Your Own Secure Linux Kernel With PaX and Grsecurity

The reason why Linux and open source will always be more secure than Windows is because you can build advanced security right in. This guide’s going to show you how to do that. I’ll be explaining how to compile your own kernel with PaX and Grsecurity patches. (I’m actually compiling 3.3.6 for myself but this guide covers 3.2.18.)

First let’s explain a few things…

What Is A Kernel?

Well, if you don’t know what a kernel is this guide is probably a bit too advanced but far be it from me to turn you away. The kernel is essentially the core of the operating system. It is the lowest level of software on the system running with the highest rights. Linux runs on “The Linux Kernel” and that kernel is common to all Linux distributions.

What Is PaX?

PaX is a series of patches that can be applied to the Linux kernel. These patches provide functionality and improvements to built in features such as ASLR (Address Space Layout Randomization), which help mitigate and deter exploits.

PaX features can be daunting so for a per-feature explanation see this link. I highly suggest you take a look at these features and research both PaX and Grsecurity so you can fully understand what they provide.

What Is Grsecurity?

Grsecurity is another series of patches that can be applied to the Linux kernel. These patches will allow changes to policy, provide a tool for RBAC, and add new policies. Grsecurity and PaX are built to work together and reinforce one another.

Why Are We Doing This?

Well, to get the most secure system that you can possibly get you’re going to want to start compiling your own kernel. The kernel is, for various reasons, where security belongs (more on this in future posts.) Now, on a default install of some distro like, say, Ubuntu you’re fairly secure and the tools already provided can be used to really lock the system down (think AppArmor) but if you’re looking to secure your system against sophisticated and targeted attacks PAX and Grsecurity are the way to go.

Keep in mind that the settings I use are for my own system. A server would be able to use more settings because it wouldn’t have to worry about, for example, the sound working.

You will also need to do this for new updates from in order to get the latest security patches, among other things. Not even Grsecurity will keep an unpatched system safe.

So, since we’re done with the intro…

Setting Up Our System

Before we even download source code we need to make sure we have everything necessary to actually compile and configure our kernel. Let’s start by installing some software: (I’ll assume sudo/root for this guide.)

# apt-get install patch bin86 kernel-package build-essential libncurses5-dev gcc-*-plugin-dev

That’s (hopefully) everything you need to compile, package, and configure the kernel. (You may need to install gcc and plugins.)

Now let’s set up a working folder and cd to it.

# mkdir /usr/src/linux/

# cd /usr/src/linux/

That’s it for now.

Downloading The Linux Kernel And Patches

In this example I’ll be using the Linux Kernel 3.2.18 (the same steps will work for any kernel, just change the patches) and the Grsecurity patch that goes along with it. I’m assuming you’re still in /usr/src/linux/.

# wget

# wget

Once the download has completed you can extract linux-3.2.18.tar.bz2 to ./linux-3.2.18.

Patching The Kernel

This part is fairly simple, move to your new linux-3.2.18 folder and patch.

# cd ./linux-3.2.18

# patch -p1 < /usr/src/linux/grsecurity-2.9-3.2.18-201205301835.patch

This should patch the kernel without any interaction necessary.

Configuring The Kernel

(note: I am taking screenshots of a 3.3.6 kernel with my own configuration, yours may vary. Once size does not fit all – do research!)

#make menuconfig

You’ll be brought to this screen:

Note: If you want to enable KERNEXEC you must go to Processor Features and disable Xen/Paravirtualization.

Navigate (arrow keys) to Security Options and hit ‘Enter’ and…:

Configuring Grsecurity:

As you can see there are many options here. You can use preconfigured options (Low, Medium, High) or, as I suggest, Custom.

The following settings are suggestions that work for me. They can make or break systems depending on usage. A server might need completely different settings, for example. You’ll probably be compiling a few kernels just to see what breaks when.

Memory Protections:

[*] Deny reading/writing to /dev/kmem, /dev/mem, and /dev/port
[  ] Disable privileged I/O
[*] Harden ASLR against information leaks and entropy reduction
[*] Deter exploit bruteforcing
[*] Harden module auto-loading
[*] Hide kernel symbols
[*] Active kernel exploit response

Role Based Access Control (RBAC): I’ll post later about configuring RBAC.

[  ] Disable RBAC system
[*] Hide kernel processes
(3) Maximum tries before password lockout
(30) Time to wait after max password tries, in seconds

Filesystem Protections:

[*] Proc restrictions
[*] Restrict /proc to user only
[*] Additional restrictions
[*] Linking restrictions
[*] FIFO restrictions
[  ] Sysfs/debugfs restriction     -Breaks Sound on Ubuntu
[  ] Runtime read-only mount protection   -For servers, not users.
[*] Chroot jail restrictions
[*] Deny mounts
[*] Deny double-chroots

[*] Deny pivot_root in chroot

[*] Enforce chdir(“/”) on all chroots
[*] Deny (f)chmod +s
[*] Deny fchdir out of chroot
[*] Deny mknod
[*] Deny shmat() out of chroot
[*] Deny access to abstract AF_UNIX sockets out of chroot
[*] Protect outside processes
[*] Restrict priority changes
[*] Deny sysctl writes

[*] Capability restrictions

Kernel Auditing:

Your choice, this is more useful for servers. As a user I don’t need any of this.

Executable Protections:

[*] Dmesg(8) restriction
[*] Deter ptrace-based process snooping
[*] Require read access to ptrace sensitive binaries
[*] Enforce consistent multithreaded privileges
[*] Trusted Path Execution (TPE)
[*] Partially restrict all non-root users -This is one option that I use. It may break things and it’s not a critical feature so you may consider removing it.

Network Protections:

[*] Larger entropy pools
[*] TCP/UDP blackhole and LAST_ACK DoS prevention
[  ] Socket restrictions

SysCtl Support:

[  ] Sysctl support
[  ] Turn on features by default

Configuring PAX:

As with Grsecurity we’re presented with quite a few options. PAX settings can very easily break things so my settings will likely vary from what your settings could be. I will note specific areas where there are known conflicts.

For details on PaX features see this link.

PaX Control:

[  ] Support soft mode By leaving this off we have PaX system wide.
[  ] Use legacy ELF header marking
[  ] Use ELF program header marking
[  ] Use filesystem extended attributes marking

Non-Executable Pages:

[*] Enforce non-executable pages
[*] Paging based non-executable pages
[*] Emulate trampolines
[*] Restrict mprotect() This will break X.
[  ] Use legacy/compat protection demoting (read help)
[  ] Allow ELF text relocations (read help)

[*] Enforce non-executable kernel pages (Requires  you disabled Xen)
Return Address Instrumentation Method (bts) —>

Address Space Layout Randomization:

[*] Address Space Layout Randomization
[*] Randomize kernel stack base
[*] Randomize user stack base
[*] Randomize mmap() base

Miscellaneous Hardening Features: (Note: Users of ATI SPUs must use my settings here. Users with other GPUs should enable all ** settings.)

[*] Sanitize all freed memory
[*] Sanitize kernel stack
[*] Prevent various kernel object reference counter overflows  **
[*] Harden heap object copies between kernel and userland  **
[*] Prevent various integer overflows in function size parameters

**As of version 12.8 the closed source ATI FGLRX drivers are compatible with the above. Earlier versions will NOT work.

Other Security Settings

Exit your PaX options and go back to the security settings.

Set ” Low address space for LSM to protect from user allocation” to 65536 or 32768:

This is the portion of low virtual memory which should be protected
from userspace allocation. Keeping a user from writing to low pages
can help reduce the impact of kernel NULL pointer bugs.

For most ia64, ppc64 and x86 users with lots of address space
a value of 65536 is reasonable and should cause no problems.
On arm and other archs it should not be higher than 32768.
Programs which use vm86 functionality or have some need to map
this low address space will need the permission specific to the
systems running LSM.

Time To Compile And Install

(Note: You may want to see the last section ‘Other Tips’ before you compile.)

# make-kpkg clean

# make-kpkg --initrd --append-to-version "grsec1.0" kernel_image

The above command might give you an error in which case you’ll need to type it out. It’s a wordpress issue where it combines the –‘s.

Compiling will take a while. Probably a half hour, potentially multiple hours depending on the hardware. When you’re done there will be a package in /usr/src/linux.

# cd /usr/src/linux

# dpkg -i ./<name.of.deb>

Reboot into the new kernel and that’s it.

It’s a lot of work to set it up but it should only take you a few minutes after the first time. Compiling is what takes the longest but it can be done in the background.

If something breaks just boot into the last kernel you used. Simple.

Other Tips

Since you’re taking the time to compile this thing you may as well get the most out of it. I suggest you go through the settings and disable any drivers not related/ enable or disable features.

You should also open /usr/src/linux/linux-3.2.18/makefile and find the line:

# Add user supplied CPPFLAGS, AFLAGS and CFLAGS as the last assignments

And have the following line as: (add the -march=native -pipe -mtune=native)

KBUILD_CPPFLAGS += $(KCPPFLAGS) -march=native -pipe -mtune=native

pipe will speed up compile time significantly for systems with lots of RAM. march=native will optimize the kernel for your specific CPU. Don’t use -march=native if you are compiling for another system with a different CPU (same for mtune).

Take the time to disable drivers that you won’t use. It’ll speed up compile time and produce a smaller kernel.


The highlights of this new kernel are:

1) Improved ASLR


3) Hardened Chroots (if you use Chromium or Google Chrome the sandbox makes use of Chroots so you’ve just made it more secure.)

4) Exploit bruteforcing is much harder

5) A generally more secure system with stricter policies and checks

6) Optimized kernel if you followed the “notes.”

This was a long post so if I’ve left anything out or misrepresented something leave a comment and let me know. RBAC is worth its own full post so I’ll get to that later (setting it up on any user-oriented OS is difficult.) For now you can see this wiki page to learn how to set RBAC up, but it’s not so simple.


How To Create A Strong And Memorable Password

Tips For Creating A Secure Password:

A secure password has a few features: it’s easy for you to remember, hard for a hacker to guess, and too complicated/ long to bruteforce.

A good password will have at least one of each of these: lower case letter, upper case letter, number, symbol. This guide will explain how to create a strong password that’s easy to remember and duplicate for various services.

Your password should be at least 12 characters long. Anything “mission critical” (as in the government is after the nuclear codes that you stole) should be at least 14 characters. Some people recommend 20 characters, this isn’t really necessary unless you can’t verify the crypto behind the password security.

A horrible password for anyone would be “password123” as it’s the first thing any attacker will try. It’s got a single word, which means it’s highly susceptible to a dictionary attack, and merely 3 numbers. It’s also only 11 characters, which isn’t awful but for protecting critical data it should be key.

A bad password for me would be “insanitybit12345!?” as an attacker might guess that I’d use my username as a password. At that point they only need to bruteforce 12345!? and they’ll likely do the ‘12345’ anyways.

A good password for me would be “CatBike92391(!” as it has 14 characters, two words, a friends birthday (not my own, just some random friend from years ago) and two random symbols.

A great password for me would be “AwfulCatBike92391(@#(!(!” as it has 24 characters, three unrelated words, an old friends birthday, their birthday typed while holding shift, and two random symbols. This password is beyond overkill, I suggest you stick to a password closer to 12-14 characters unless you can’t confirm that the crypto behind what your entering the password into is secure (like an online service.)

A bad, but ‘strong’ password would be “a%f!1234BZV245NDF!#$?;;z<qortQERG” as it has over 30 characters, all ‘random’, but there’s no way in hell I’ll remember it and I’ll be pissed off every time I spend the time typing it out just to retype it because I forgot a letter. If I were an inexperienced user I’d end up writing it on paper, which is horrible.

Remembering even my incredibly long AwfulCatBike92391(@#(!(! is simple. You just need to remember 3 words, 1 birthday, and two random symbols. That’s 5 things to remember, it’s nothing. It’s like remembering “party” is your password or any other 5 letter word.

Keep in mind that the equation for password combinations is (character set! ^ length!) so simply by adding one of each character set (a, B, 3, $) you improve the security of your password by a massive amount.

I’m also using “AwfulCat” and not “Gorillas” – even though they are both the same length “Gorillas”  is actually much less secure because it is one word. The difference is very large when you consider dictionary attacks and how they work. Stringing two unrelated words will be much more secure than one long word.

TIP: You can create multiple strong passwords very easily.

Let’s take our AwfulCatBike92391(@#(!(! example.

Maybe that’s my email password for GMail and now I want a strong Hotmail password. I’ll simply change AwfulCatBike92391(@#(!(! to:

SuperDogCar71488&!$**%$. I’ve changed “Awful” to “Super”, “Cat” to “Dog”, and “Bike” to “Car.” Anyone who got a 200 or above on their SATs should be able to understand the relations here. I also picked another friends birthday and another two random symbols. So now we have a very different password that’s just as secure as the last and it won’t be difficult to remember both because they’re similar in terms of semantics..

Other examples might be:

GreatEmuTruck52090%&()$# or EvilRabbitJeep41794$!&(%*%

Its simple. Though, again, I think that these passwords are overkill and something more like the 14 character example is ample.

AppArmor How-To

A short guide to get you started on AppArmor

AppArmor is a linux security module that allows for path based mandatory access control. It’s easy to learn and very effective at both preventing and containing exploits. I suggest you make use of it.

This post is just a short crash course to get you set up and using apparmor.

Step 1:
We first need to install the apparmor-utils package.
sudo apt-get install apparmor-utils
Once it’s done installing you should be able to access these commands:
# aa-logprof
# aa-status
# aa-autodep
# aa-enforce
# aa-complain
Step 2:
Let’s create our first profile. I’ll use pidgin.
# aa-autodep pidgin
This will create the pidign profile in complain mode. Complain mode will audit violations but not stop them.

Step 3:
Close (if open) pidgin and then open it up again. And then close it. Then run the command:
# aa-logprof

At this point you’ll be greeted with some of the “complaints” that were logged. Review and allow what’s needed.

r: r is read access
w: w is write access
a: a is limited write access (append)*
k: k allows the ability to lock a file
m: m lets a file be loaded into memory
x: allows execution
ix: executes the file under the constraints of the profile (inherit)
ux**: executes the file outside of the profile (unconfined)

Cx: executes the file in its own profile, which is specific to the parent process
Px**: executes the file in its own profile, which you will have to define (profile)

*not to be confused with allow. a is the rule, allow is a command that applies it via logprof.

**Capital C, P or U means that the environment is sanitized before executing the code. You want to sanitize whenever possible.

Step 4:

To test the profile out run:

# aa-enforce /etc/apparmor.d/usr.bin.pidgin

if it isn’t working still set it back to complain:

# aa-complain /etc/apparmor.d/usr.bin.pidgin

The first few times I set up a profile I ended up with a super convoluted mess. It was terrible. I wiped it, started over and actually *thought* before I hit “allow” or “inherit” and in very little time I was able to create many profiles for my programs.
Profiles are stored in /etc/apparmor.d/<path.path.path> so for pidgin it’s /etc/apparmor.d/usr.bin.pidgin. You can manually edit the profiles with a text editor. This is really simple and I suggest you have a look at a few profiles before you start.


1) Instead of aa-autodep you can try aa-genprof, which will try to build a partial profile for you.

2) Development profiles can be a great place to start. You can get them here:

3) Apparmor profiles can get complicated. Don’t bother trying to profile something like compiz, there’s no real point. A program like Pidgin or xchat is perfect though.

Creating Strong Profiles 

There are a few things to make note of when aiming to create very strong AppArmor profiles. Get used to everything above here so you’ve got your bearing before looking below.

1) Abstractions

Abstractions are generic templates that can be imported into AppArmor profiles. Most profiles come with at least a few abstractions. Abstractions are dangerous – they can pull in other abstractions within them, and lead to far more rights than your program may need. Creating with abstractions is easy but your profiles will be stronger without them. If you’re going to use abstractions always review what you’re pulling in.

2) Owner Tag

The “owner” tag is your friend. Sometimes you have to give a program really unruly access to your file system (/home/** rw). Using the “owner” tag means that (in the case of /home/** rw) the profiled program can only read/write to files that it has ownership of. This is a really useful tag and I suggest you make use of it wherever possible. Programs mostly just need access to their own files and folders, especially for write access, and owner is great for enforcing this.

3) Know Which Execution Rules To Use

There are four execution rules: ix, Cx, Px, and Ux. Knowing when to use them is important, but not difficult.

First of all, never use UX. Let’s remove it as an option right now.

Often times it’s easiest to just inherit the process, but oftentimes this is not the best action. Inherited processes should be the ones that will only act on files already defined.

For example, Chrome might call /bin/which to interact with its files. There’s no need to run which in a child process,  it needs access to all of Chrome’s files and nothing else.

You most certainly wouldn’t want to run Native Client as an inherited process. Native Client will require its own separate resources and rules, so it makes much more sense to run it as Px.

You may also consider running Native Client as a child process from Chrome, though in my opinion this isn’t as powerful as Px as you can not have child processes within a child process.

A child process is very good for situations where you don’t want the process to always be confined. For example Chrome needs to run xdg-settings. You don’t want xdg-settings to always be profiled, and even if you did you wouldn’t need all of those capabilities just for what chrome will use it for. So running it as a child makes the most sense.

As you create more profiles this all becomes much easier and intuitive.

4) Avoid UX, Be Wary Of PX/CX

There are three execution rules that can let an attacker gain privileges, CX, PX, and UX.

Never use UX – if you use UX you make your profile far far weaker, essentially allowing an attacker to execute any file they can write on the system. Really, if you feel the need to UX then your profile is in trouble, go for CX instead.

Attackers can potentially escalate privileges by moving to a new process under a new profile. They do this through CX/PX. If I’m an attacker in someone’s Pidgin profile but I can’t access the files I need I might hop over to the browser process through a “/usr/bin/firefox Px” rule, which would then let me access anything the Firefox profile has access to.

Always use a capital P/C. This ‘sanitizes’ the environment, which removes specific variables that could be passed along to the new process. You very rarely can’t sanitize the environment and it’s far more secure to do so.

5) Don’t Allow Writing To Areas You Can Map

Mapping a file to memory can potentially allow an attacker to move forward in an exploit, either by then marking it as executable or using ROP. If an attacker can write to an area it’s best not to allow it to be mapped. If it’s absolutely necessary make sure to restrict it with an ‘owner’ tag, at the very least. This is usually the case for cache files and sometimes /tmp. Avoiding the combination is a good idea

This isn’t all you can do. Very specific rules with file extensions are one more way to be secure. Use your imagination.