Sandboxing: Conclusion

In total I’ve written five methods for sandboxing code. These are certainly not the only methods but they’re mostly simple to use, and they’re what I’ve personally used.

A large part of this sandboxing was only possible because I built the code to work this way. I split everything into privileged and unprivileged groups, and I determined my attack surface. By moving the sandboxing after the privileged code and before the attack surface I minimized risk of exploitation. Considering security before you write any code will make a very big difference.

One caveat here is that SyslogParse can no longer write files. What if, after creating rules for iptables and apparmor, I want to write them to files? It seems like I have to undo all of my sandboxing. But I don’t – there is a simple way to do this. All I need is to have SyslogParse spawned by another privileged process, and have that process get the output from SyslogParse, validate it, and then write that to a file.

One benefit of this “broker” process architecture is that you can actually move all of the privileged code out of SyslogParse. You can launch it in another user, in a chroot environment, and pass it a file descriptor or buffer from the privileged parent.

The downside is that the parent must remain root the entire time, and flaws in the parent could lead to it being exploited – attacks like this should be difficult as the broker could would be very small.

Hopefully others can read these articles and apply it to their own programs. If you build a program with what I’ve written in mind it’s very easy to write sandboxed software, especially with a broker architecture. You’ll make an attacker miserable if you can make use of all of this – their only real course of action is to attack the kernel, and thanks to seccomp you’ve made that a pain too.

Before you write your next project, think about how you can lock it down before you start writing code.

If you have anything to add to what I’ve written – suggestions, corrections, random thoughts – I’d be happy to read comments about it and update the articles.

Here’s a link to all of the articles:

Seccomp Filters:

Linux Capabilities:

Chroot Sandbox:


And here’s a link to the GitHub for SyslogParse:

Writing Sandboxed Software

I wrote a program recently, SyslogParse, to display apparmor and iptables rules based on violations found in my system log. I did this because my apparmor-utils packages always break / were quite slow when going through my profiles, and going through iptables rules in syslog was a big of a pain too.

I decided this would be a fun project to sort of “lock down” against theoretical attacks, and I’d like to blog that experience to demonstrate how to use these different sandboxing mechanisms, as well as how they make the program more secure.

What takes place below is after the process of designing the application from a functional point of view – “what do I need this thing to do?”.

Step One: Threat Modeling

This step was a little less important for SyslogParse, as I was going to secure it regardless of real-world threats, but I’ll explain how I went about threat modeling.

The first thing I did is figure out what permissions this SyslogParse needs. I know the application, by design, must read from /var/log/syslog – a file that you need root permissions to read from. So I’ll be running this as root in order to do work.

To make things easier for users who don’t log to syslog, I’ll take in a path parameter, which means someone running this program can specify an arbitrary input file. That is the attack surface – one file being taken in.

An attacker who can control content in that file can potentially escalate to root privileges.

Step Two: Seccomp Mode 2 Filters

I’ve discussed seccomp filters on my blog beforehand, but to give a short recap, seccomp filters are developer-defined rules that will dictate which system calls can be made, and do light validation on the parameters.

Seccomp filters are very simple to use, and they’re the first thing I implemented.

Here I declare the seccomp filter.

scmp_filter_ctx ctx;

Here I initialize it to kill the process when rules are violated.

ctx = seccomp_init(SCMP_ACT_KILL);

And here is an example of a seccomp rule being created.

seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(futex), 0);

In the above rule I’ve said to allow the futex system call, a call used when a program uses threads and has to set mutexes. The “0” means I have no additional verification of the system calls arguments. In an ideal world I’d validate arguments to all of these calls, but it’s not always possible.

In the end I had about 22 calls, 3 of which I validate parameters on.

The thing about seccomp is that there’s no point doing sandboxing before I set this up, because without it the kernel will always be an easy target, and as many sandboxes as I layer on, I can’t change that from within my SyslogParse code – until I use Seccomp.

23 calls is quite a lot (though considerably less than it could be), and I chose futex as an example to show that despite limiting the calls, the recent futex requeue exploit would bypass this seccomp sandboxing and all other sandboxing this program uses. There’s only so much we can do from within the context of this program.

What is nice, however, is that I now know my kernel’s attack surface. Barring flaws in the seccomp enforcement, I know how my attacker can interact with the kernel, and that in itself is quite valuable.

Step Two: Chroot

By design SyslogParse must be root, in order to read root files, so that means I’ve got the chroot capability. May as well make use of it.

There’s a misconception that chroots are really poor security boundaries. This isn’t entirely false, but it’s not the whole story.

With one call I can set up a chroot environment that’s not so easy to break out of, at least it won’t be by the end of this article.

mkdir("/tmp/syslogparse/", 400);

That creates a folder /tmp/syslogparse/ with the permissions that only root can read from it. Right now we’re root, so we can read from it, but that won’t last too much longer (about two more steps).


The file system as SyslogParse now knows it is an empty wasteland that only root can read and no one else can write to. A regular user would have no ability to read or write to it, which is nice because Inter-Process Communication (IPC) would require at least write access, and ideally read and write access.

Step Three: RLimit

For SyslogParse this is a bit unnecessary, but I went with it anyways.

rlrmit() is a system call you can make that will irreversibly limit that process in some way. In this case, because I want to limit IPC, and because SyslogParse only ever writes to stdout, which is already open, I’m going to tell it that it can not write to any new files.

struct rlimit rlp;
rlp.rlim_cur = 0;

setrlimit(RLIMIT_FSIZE, &rlp);

In a more literal way, I’ve told the system that my process can not write to a file that is larger than 0 bytes.

Step Four: Dropping Privileges

The last significant step in this sandbox is to lose root. In this case, dropping to user 65534, which, at least on my system, is the ‘nobody’ user. A more ideal situation would have SyslogParse drop to a completely nonexistent user (to avoid sharing a user with another process) but I’m going with this for now.



That’s all it takes – SyslogParse is now running as the nobody user/group. No more root, and the process is within a chroot environment that it has no permissions to read or write to.

Step Five: Apparmor

I’m on elementary OS, which has apparmor. So, in my makefile I’ve put an ‘mv’ command that puts my profile into the users apparmor directory.

For a small program like this the apparmor profile is very simple.

# Last Modified: Wed Aug 13 18:57:15 2014
#include <tunables/global>

/usr/bin/syslogparse flags=(complain){

/usr/bin/syslogparse mr,
/var/log/* mr,

/etc/ mr,

/sys/devices/system/cpu/online r,
/lib/@{multiarch}/* mr,
/lib/@{multiarch}/libc-*.so mr,
/lib/@{multiarch}/libm-*.so mr,
/lib/@{multiarch}/libpthread*.so mr,

/usr/lib/@{multiarch}/* mr,
/usr/lib/@{multiarch}/libstdc*.so* mr,



A few library files, read access to /var/log/ (for arbitrary log files), and, because I threaded the process, it needs to read


The real benefit of this apparmor profile is that it takes effect before any code runs – the rest of the sandboxing all happens right after I open /var/log/syslog – there is very little code before it, but some, and a compromise at that point will lead to full root control of the process. With the apparmor profile the worst case scenario is that they have access to only what is listed there.


Overall, I think that’s a fairly robust sandbox. It was mostly for fun, but it was all fairly simple to implement.

If an attacker did break into this system, the above would make things a bit annoying, though the obvious path is to simply attack one of the allowed system calls, as I only validate parameters on 3 and there is clearly attack surface still left.

This isn’t bullet proof, and it’s not an excuse to not test your code. I fed SyslogParse garbage files/ unexpected input to make sure it failed gracefully/ err’d out immediately when it came across something it didn’t know how to deal with.

Lots of fun to write, and hopefully others can make use of this to make their programs a little bit stronger.


Windows XP Support Has Ended

A long time ago I posted an article entitled Windows XP – Abandon Ship. That was nearly one year ago today. And just a few days ago XP officially stopped getting support and patches from Microsoft.

I’d like to clear up some misconceptions that people still seem to have.

You can not be secure on Windows XP. In truth, it’s been a lost cause for quite some time, but Microsoft has been pretty good at dealing with threats through an active approach. Shatter attacks devastate XP machines due to poor privilege separation, but Microsoft addressed this issue decently with a few patches and by lowering service permissions.

Patches are not coming anymore. Support is gone. Do not expect the next big attack to be swiftly put down.

But what does that mean for you, XP user?

It could mean nothing – attackers may not care. We’ve never had such a widely used piece of software go out of support, so many people are still on XP. As far as I know this is unprecedented. Predictions are meaningless – I can not tell you what attackers will do, only what they can do.

So, as always, if you’re using XP or any unsecured system you will be playing a game of chance and not skill. It becomes ‘any attacker who wants to’ as opposed to ‘any attacker who can’ when it comes to getting into your system.

Is that a system you want to rely on?

I’ll also take this time to say that no one should be extending support for XP. Notably, Google Chrome will be continuing to patch XP. To me this is nothing but a false sense of security. Google Chrome relies heavily on its sandbox to protect its users, but any sandbox on Windows is going to rely entirely on a secure operating system. So the sandbox is very clearly not a huge barrier because the unpatched XP kernel and services will be easily leveraged for a full sandbox escape.

No one should be encouraged to use XP now. Take no pride in it- you’re gambling, that’s it.

“But I run EMET! You said EMET is great!”

EMET is awesome. And largely useless to an attacker on XP – while it’s a cute way to push back patch time on systems by a little bit it is by no means a significant barrier when basic memory corruption mitigations are not even supported on the operating system.

“But I run NoScript”

I love NoScript – great piece of software. But what will you do when a kernel vulnerability in text parsing is being used in the wild? You’ll get infected.

I really have very little to say here. XP is not securable. It wasn’t a year ago but it really more than ever is not.

I’m not saying you’ll get infected. I’m not saying that every XP machine will be linked to a botnet in a year. I’m saying that you are not secure, and anyone who wants to take advantage of that will not have a hard time.

Why I Preordered An Acer C720 Chromebook

A lot of people aren’t super into Chrome OS, but I personally think it’s a great operating system for netbooks. They’re light as hell on your resources and Chrome OS is arguably the most secure consumer operating system around.

So, why did I buy the Chromebook?

The Hardware


The Chromebook has somedecent specs for the price (270 dollars after everything),

  • CPU: Haswell Celeron 2995U. 1.4GHz, dual-core, 2MB Cache
  • RAM: 4GB DDR3 (Soldered down…sorry kids. 4GB RAM should be enough for anybody)
  • Display: 11.6″ 1366×768 (16:9)
  • Disk: 16GB SSD (NGFF connector)

Now, this is not the most powerful device in the world. Intel really screwed up in my opinion when they left AVX and AES-IN instructions out of this CPU, but it’s still not weak at all. 4GB of RAM is definitely adequate for browsing and using many apps. A decent screen, and a SSD.

The hardware is really quite decent for a netbook, certainly for the price (comparable ACER notebooks are the same price). There’s also a really great battery life – 8.5 hours, and in my experience Chromebooks typically get as good or better battery life than advertised.

This is perfect for travel or going to my classes, which is 99% of the workload it’ll get.

The Software

Chrome OS is a really cool operating system. In my opinion, it’s the ideal operating system for a netbook. Whereas other operating systems will boot up taking 1GB of RAM, or more, just for the OS itself, ChromeOS (last I checked) boots with under 100MB usage. It’s a very stripped down and optimized Linux system, booting in just a few seconds. The hardware is completely dedicated to the operating system, so even though the specs aren’t very powerful, they’re not going to waste time on anything.

Chrome OS is easily the most secure operating system in terms of protecting the user from infection or exploitation. The Chrome sandbox on Linux is something I’ve written about in the past and I feel very confident in its security. As I’ve recently written about, Native Client apps, which allow for very low level and powerful programs to run on your Chromebook, are also placed into a sandbox.

On the topic of Native Client, I think it could be huge for Chromebooks. Right now many apps are glorified bookmarks – you click them, they take you to a site, and that’s it. Once Portable Native Client is released in Chrome 31 developers will have the tools to port projects that already exist over to ChromeOS with ease. LastPass has already started work on a Native Client binary plugin, and other projects can potentially be ported.

I’ll also be able to use my Chromebook to control other computers I own that run Chrome via the Chrome Remote Desktop plugin. That means that, should anything arise that my Chromebook can’t handle, I can simply control a system that I own that can handle the task.

The majority of the Chromebook usage is going to be Netflix, Google Docs, and Cloud 9 IDE, but I think I’ll have a lot of fun with it. I may at some point turn on Dev mode and start hacking at the low level stuff, but for the most part I just want a low maintenance system that I can take around with me.


Ubuntu 13.10 And mprotect() Restrictions

For a while I’ve had to keep the Restrict mprotect() option in PaX disabled because it wasn’t compatible with certain programs. It was kind of a huge pain to deal with for that reason. But I’ve finally taken the 30 seconds to just deal with it and I’ll post how.

The program that has the biggest issue with the restrictions is Unity, the program that handles your user interface on Ubuntu. So, we need to kill Unity so that we can use the paxctl program to disable mprotect restrictions.

Keep in mind that you need to enable CONFIG_PAX_PT_PAX_FLAGS in your kernel config for this.

1) Download paxctl

A simple ‘apt-get install paxctl’ is enough here.

2) Kill Unity and Xorg

This is the annoying part. Xorg just restarts every time it’s killed. So you have to run the following command:

service lightdm stop

And then hit ctrl + alt + F4.

You should now have a terminal.

3) Apply flags

paxctl -c /usr/bin/unity
paxctl -m /usr/bin/unity

Now you can reboot and your UI should work. You’ll have to do this for a few programs (like Chrome) as well.
From the Grsecurity wiki on mprotect() restrictions:

Enabling this option will prevent programs from
– changing the executable status of memory pages that were
not originally created as executable,
– making read-only executable pages writable again,
– creating executable pages from anonymous memory,
– making read-only-after-relocations (RELRO) data pages writable again.

You should say Y here to complete the protection provided by
the enforcement of non-executable pages.

Using CloudNS For DNS Resolution – Integrity, Authenticity, Confidentiality

CloudNS is a DNS host that supports a few cool security features. I’ve set it up, and it’s working for me on Linux Ubuntu 13.04. I think its security features give it the potential to be the preferred choice for those looking for that higher level of security and privacy.

* DNSCrypt Support
We only allow connections to our service using DNSCrypt, this 
provides confidentially and message integrity to our DNS 
resolver, and makes it harder for an adversery watching the 
traffic of our resolver to identify the origin of a DNS query as
all the traffic is mixed together.

* DNSSEC Validation
Our server does complete trust validation of DNSSEC enabled 
names, protecting you from upstream dns poisoning attacks or 
other DNS tampering.

* Namecoin resolution
Namecoin is an alternative, decentralized DNS system, that is 
able to prevent domain name censorship. Our DNS server does local
namecoin resolution of .bit domain names making it an easy way to
start exploring namecoin websites.

* Hosted in Australia
Our DNS Server is hosted in Australia, making it a faster 
alternative to other open public DNS resolvers for Australian 

* No domain manipulation or logging
We will not tamper with any domain queries, unlike some 
public providers who hijack domain resolution for domains that
fail to resolve. Our servers do not log any data from connecting 
users including DNS queries and IP addresses that make 

I think those are some really interesting features. For one thing, it forces DNSCrypt and validates with DNSSEC, and it appears to be the only resolver to do both of these things. And it’s also hosted outside of the US, which has its own implications for security.

So I went ahead and set up CloudNS using the following command (and setting this in rc.local) after configuring DNSCrypt from this guide. You can check for the updated information, but as of today (Aug 8th, 2013) this command works for me.

dnscrypt-proxy --user=dnscrypt
--daemonize --resolver-address= --provider-key=1971:7C1A:C550:6C09:F09B:ACB1:1AF7:C349:6425:2676:247F:B738:1C5A:243A:C1CC:89F4

To use the secondary server as well the command is:

dnscrypt-proxy --user=dnscrypt --daemonize --resolver-address= --provider-key=67A4:323E:581F:79B9:BC54:825F:54FE:1025:8B4F:37EB:0D07:0BCE:4010:6195:D94F:E330

So the three big improvements for me are DNSSEC, DNSCrypt, and Australia hosting.


DNSSEC is an extension of DNS that aims to provide authentication and integrity of DNS results; it ensures that you know who the result is from and that no one else has tampered with it. DNS responses are authenticated but they are not encrypted, so DNSSEC does not prevent someone between you and the resolver from viewing the request.


DNSCrypt provides encryption of DNS requests, which provides confidentiality of the requests, meaning that an attacker between you and the resolver can not view the traffic between you and your DNS resolver.

Stacking DNSSEC and DNSCrypt works out very well, as you end up covering your bases and achieving confidentiality, integrity, and authentication.

Hosting In Australia

While I’m not particularly familiar with Australia’s laws, hosting outside of the US definitely provides a bit more peace of mind. Just yesterday we learned that Lavabit (the email provider chosen by Edward Snowden) has shut down due to the US government trying to compromise their ability to protect their users. The truth is that hosting in the US just makes a service less trustworthy at this point, and hosting outside is a big plus. This, combined with Namecoin and their pledge to not log, is really somewhat comforting.

So, while I can’t absolutely recommend it at this point (I haven’t been using it long enough) I think there’s a lot of potential here.

Hardening DNSCrypt

DNSCrypt is a DNS Resolver that encrypts the DNS requests between you and the first level DNS resolver. I have a guide for setting it up here. This guide will be about restricting the process and user account, making DNSCrypt more resilient to attack – I will continue to update this guide, I have a few more ideas.

One of the nice features of DNSCrypt is that it actually takes security into account. I wish this weren’t something to be shocked by, but, *gasp* it actually uses compiler security flags. Specifically, it uses the following flags:

-fPIC -fPIE -fstack-protector-all -fno-strict-overflow -fwrapv **

-fPIC and -fPIE tell the compiler to create a relocatable binary, completing the implementation of ASLR. It’s a mitigation technique we rarely seen used, despite it being somewhat critical, and it having been around for years. So right off the bat they’re doing more than most.

-fstack-protector-all (unlike the oft used -fstack-protector, which only protects functions using char arrays/strings) tells the compiler to protect every function with a stack canary. If an overflow occurs the canary may be overwritten, and the function will fail.

-fno-strict-overflow and -fwrapv are essentially the same (in other words, I don’t know the difference) and they tell GCC to not make assumptions about overflows, basically to not assume that overflows won’t occur. Compilers make the assumption that overflows won’t happen when they generate the optimized assembly, so they can build optimizations with that assumption – this prevents that, which is safer.

So these are nice, and we like them. But DNSCrypt also does a bit more.

You can create a new DNSCrypt user with no write rights, and it will chroot itself into that user, and drop rights. This is great, since a chroot’d process with no ability to write is difficult to break out of. And running as a separate user means no X11 access, it gets its own home folder, and it’s generally more isolated from the system – all good things!

But it means some other stuff too. Because it does all of the above we as users can take that protection further – beyond where typical programs allow us to. I think this demonstrates what a strong security model really can do when built from the ground up.

So, on to what we can do.

First thing’s first, we’re going to want some information on our DNSCrypt user.

run ‘id dnscrypt’

You should get something similar to:

id dnscrypt
uid=109(dnscrypt) gid=123(dnscrypt) groups=123(dnscrypt)

We’re going to need this.

IPTables On User

Note that if you’re using UFW this may cause issues, using UFW/GUFW with iptables isn’t recommended, and your mileage may vary  – to remove your UFW rules run ‘iptables -F’. 

Normally I’m not fond of outbound filtering, but because DNSCrypt separates itself into another user, it’s actually not such a bad idea. It means that DNSCrypt can’t just switch its outbound connection to another program under the same user account, and it means that the ports we limit will be limited to that user account specifically. This assumes you are using DNSCrypt under a user called ‘dnscrypt’.

So it’s a lot more worthwhile to set up outbound filtering here.

DNSCrypt should only need outbound access to port 443, with UDP. So we can restrict it to just port 443 and UDP with the following IPTables rules:

iptables -A OUTPUT -m owner --uid-owner dnscrypt -p udp  --dport 443 -j ACCEPT
iptables -A OUTPUT -m owner --uid-owner dnscrypt -j DROP

Basically, the first rule allows outbound access to the DNSCrypt user over port 443 and UDP, and the second rule denies everything. If the first rule is hit, and it passes, the second rule doesn’t have to come into play.


DNSCrypt is now restricted to UDP over port 443, and all processes running under the dnscrypt user are as well. If you followed the tip then no new connections can be made to your system except over port 53 (you can have dnscrypt use another port, in which case you’ll switch that port to whatever that one is. I have yet to figure the details of this out, I’ll edit it in when I do.)

Trusted Path Execution

If you care about security you’re already running Grsecurity, but if not, see my guide here.

Grsecurity has an option called Trusted Path Execution that allows us to limit a group, preventing it from executing files owned and only writable by root – since our program doesn’t run as root, and can’t write anywhere, it means it won’t be able to execute anything at all.

So check the TPE box and add the GID for untrusted users, in this case 123.

Now this protection is superfluous, DNSCrypt shouldn’t be able to write to the filesystem, so it shouldn’t be able to execute any payloads off of the file system, but it’s still good to have as the protection is now implemented by the user account itself, and doesn’t rely on the program to drop rights properly, or a perfect implementation of chroot.

Chroot Restrictions

While you’re compiling your Grsecurity kernel, you can also go ahead and turn on every single chroot restriction without worry – DNSCrypt works fine with them all. DNSCrypt already can’t write to its chroot, so  as far as I know there’s no known bypass as is, but you can safely enable all of these restrictions. Although some of the protections are a bit redundant due to the aforementioned write restrictions, there are a few that are quite nice, such as:



More restrictions on our exposed service.


Apparmor is an LSM (Linux Security Module) program that restricts a process. If Apparmor is the LSM used on your distribution (Ubuntu derivatives) you can find my profile here. Apparmor will restrict file access, what programs can be executed, what libraries can be loaded, etc. An attacker who winds up in a program that is confined with apparmor must either find a flaw in apparmor, or the profile, or they have to use a local escalation attack. If you’re using everything listed above this is going to be a lot of work for them.

Users of other LSM such as SELinux will need to build their own profiles. This shouldn’t be hard, DNSCrypt needs little file access to work.


Given the situation where an attacker finds himself compromosing the DNSCrypt-Proxy on a system that has done all of the above, they’re going to be pretty pissed off. There is still room for improvement, (seccomp filters) but right now an attacker is going to have to do a lot to get an exploit to be reliable.

For a program like DNSCrypt this level of security is great. It already chroots itself to a directory that it can’t write to, and they use compiler security, so you know they’re taking this stuff seriously. That’s what allows us to spend our time securing it further. If DNSCrypt did not so gracefully run as another user, and if it weren’t built to drop its rights to the extent that it does, then our apparmor profile would be more convoluted, TPE may not be possible, and an outbound Firewall would have been a useless attempt at security through obscurity. But because it’s built from the ground up to be this way we can reinforce it well.

Notes/ Tips

Much of this can be done to any process/ service with a bit of a change, but it’s nice to be able to do this to a process like DNSCrypt.


Keep in mind that you can add your own files to the makefile, such as “-march=native”, optimizing for your CPU. I can’t guarantee that this will play nice, or that it won’t add in unsafe compiler optimization! But you may end up using something like AES instructions since this deal swith crypto, and math, and this could speed things up.


Tip: The following commands will set your firewall so that:

1) If a connection is new, is over the loopback interface, is udp, and uses port 53, we accept it (allows dns resolution)
2) If a connection is already established from an outbound connection then we allow an inbound connection.
3)All other connections that do not meet the above criteria are blocked.

iptables -A INPUT -i lo  -m state --state NEW -p udp --dport 53 -j ACCEPT

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

iptables -A INPUT -m  state --state NEW,INVALID -j REJECT

Microsoft’s Security Bounty Program

Microsoft has revealed details on its new bounty program for security research. Unlike a typical bounty program that just pays a researcher for finding a specific vulnerability, Microsoft is offering rewards for a broader range of attacks on mitigation techniques.

  1. Mitigation Bypass Bounty. Microsoft will pay up to $100,000 USD for truly novel exploitation techniques against protections built into the latest version of our operating system (Windows 8.1 Preview). Learning about new exploitation techniques earlier helps Microsoft improve security by leaps, instead of capturing one vulnerability at a time as a traditional bug bounty alone would. TIMEFRAME: ONGOING
  2. BlueHat Bonus for Defense. Additionally, Microsoft will pay up to $50,000 USD for defensive ideas that accompany a qualifying Mitigation Bypass submission. Doing so highlights our continued support of defensive technologies and provides a way for the research community to help protect more than a billion computer systems worldwide.TIMEFRAME: ONGOING (in conjunction with the Mitigation Bypass Bounty).

As you can see the focus isn’t about specific vulnerabilities, it’s about hardening mitigation techniques to prevent entire classes of vulnerabilities. A mitigation technique, such as DEP, prevents direct code execution. Another technique, ASLR, makes bypassing DEP more difficult by preventing Return Oriented Programming.

Flaws in these techniques can lead to bypasses, and these bypasses can be used across vulnerabilities, and therefor have a much larger impact.

Microsoft has done this before. In the past their rewards program has led to a series of new “Anti-ROP” techniques in the EMET program. Improving and adding to these techniques drives up the cost of every exploit.

Microsoft is also paying out for Internet Explorer 11 vulnerabilities:

  1. Internet Explorer 11 Preview Bug Bounty. 
    Microsoft will pay up to $11,000 USD for critical vulnerabilities that affect Internet Explorer 11 Preview on the latest version of Windows (Windows 8.1 Preview). The entry period for this program will be the first 30 days of the Internet Explorer 11 beta period (June 26 to July 26, 2013). Learning about critical vulnerabilities in Internet Explorer as early as possible during the public preview will help Microsoft make the newest version of the browser more secure. TIMEFRAME: 30 DAYS

IE11 is available on the Windows 8.1 Preview, and Microsoft is hoping that researchers can help break into it so they can gauge security. While solving individual vulnerabilities does not exactly add much to security, it does help developers behind IE11 see where attackers will go. If I were an IE11 developer, and I got a response from a dozen developers showing that they could break into my program through the Javascript Renderer, I’d know that I needed to really focus on securing that component, because it’s likely the easiest spot to attack. So while those patches themselves may not be making the program much more secure, the knowledge I gain from viewing trends will.

I’d like to see more bounty programs like this, but Microsoft is in the best position for it – a browser can’t always do much about mitigation techniques, as they have more to do with the operating system and compilers. I think a lot of good will come from this program.

Why You Should Use NoScript

It’s commonly said that the browser and its plugins are the number one attack point for the average user. So locking down the browser is obviously key to maintaining a secure system. I’ve written a guide for Firefox as well as Chrome, but I want to take a post to really focus on the NoScript extension for Firefox.

NoScript is an open source project that aims to secure the browser. It prevents code from executing in the browser, such as Java, Flash, Javascript, Silverlight, or any other plugin, and it provides a few other features as well. It’s probably the number one best way to secure Firefox.

NoScript has three main modes:

1) Globally deny all scripts

Scripts on any webpage are blocked until whitelisted.

2) Allow Top Level Domain

Scripts from the top level domain (ie: the website your on, no third party content) are allowed to run, all others blocked.

3) Allow all scripts globally

In terms of security, it pretty much goes 1 > 2 > 3.

By blocking all scripts you prevent any attack that needs to make use of Javascript, Java, Flash, or another plugin. That covers the absolute vast majority of attacks we see against users.

NoScript’s default setting, deny all scripts, may be a bit overbearing for some. But even if you can’t handle having the default setting I still suggest installing NoScript and leaving it on 2 or 3, which are more manageable but still provide security features.

Even if you allow all scripts globally NoScript will do the following:

XSS Filter

NoScript includes its own XSS Filter, and it’s pretty great. XSS (Cross Site Scripting) is considered one of the most dangerous threats to security and NoScript provides a very strict filter, stricter than browsers include. Even if you whitelist globally you benefit from the XSS Filter.


NoScript can also force HTTPS redirection for websites, preventing MITM attacks on specific sites. NoScript also has Hyper Strict Transport Security support, which means that websites can tell it to always enforce HTTPS and it will. This feature is also present even with all scripts allowed.


NoScript provides Clickjacking protection via ClearClick. Clickjacking is a type of attack that takes advantage of invisible content. You think you’re clicking one thing but you’re actually clicking another. ClearClick reveals hidden attributes on a page any time you interact with it, and blocks that interaction. This defeats Clickjacking independently of Javascript/ iFrame blocking.


ABE, or Application Boundary Enforcement acts as a broker to determine whether separate web applications should be given specific rights – it provides isolation at the web applications level.


So it’s clear that even with NoScript set to Globally Allow you’re much better off than a vanilla Firefox. I highly recommend that if you’re a Firefox user you make use of NoScript at its default setting, but just having it installed for any of the above features is a good idea. It’s a great tool for preventing tracking and ensuring privacy on the web (there’s a reason why TOR uses NoScript!) as well as preventing exploitation.

Configuring Grsecurity Is Easier – New Autoconfig

My previous guide on configuring Grsecurity isn’t too difficult to follow, but if messing with those settings is more than you want to do, there’s an autoconfig option.

Open your configuration with make menuconfig and then traverse via:

Security options –>

Grsecurity –>

Configuration Method


Set configuration method to automatic.



You can state whether you need to run it in a VM, whether it’s for a server or desktop, whether you prioritize performance over security, and your special groups. And you can ‘tweak’ it from there, with the Customize Configuration option.

It takes seconds to configure the kernel with Grsecurity.

For my old guide see: