irl:/dev/blog

The web used to be simple. It used to be a place where you could go and find reference materials, news and discussions about just about anything. All this content was wrapped up in HTML, maybe with some CSS to give it a tidier look, and served over HTTP. Unfortunately this is no longer the case. You can no longer survive on the web with cookies or JavaScript disabled as websites have been designed expecting that people will have those features available in their browser. On top of that, not satisfied with HTML, CSS and JavaScript (which, by the way, is Turing-compatible – there is not really a need for anything beyond JavaScript for client side scripting in the browser) we’ve got Adobe Flash, Microsoft Silverlight and Java applets too. Because these technologies exist, they are used, and anyone attempting to visit a site using them will have a pretty difficult time in navigating it without allowing the code, that you’ve likely never seen the source to and have no reason to trust, to run on your computer.

Navigating to a URL is seen as implicit consent that whatever happens to be there can run on your computer automatically. It’s true that Java has been riddled with enough security problems that there are now a series of “Are you sure?” boxes, but for Flash, Silverlight and especially JavaScript there are no such warnings. If you want to browse the web without problems, you have to accept that there are going to be security risks and eventually you’re going to get punched in the face by a malicious bit of code. Bug-proof software doesn’t exist, but blindly allowing code authored by strangers run on your computer seems like a bit of a risky strategy to me.

When I was using Linux, I would use Vimperator (a Firefox extension to make Firefox behave like Vim). Now that I’m trying to be more security aware, this is definitely not an option any more for the reasons given above. Then I thought, well, if the attack is inevitable does it really matter which browser I’m using? I then turned my research efforts to looking at “sandboxing” the browser. My initial thought was to use a virtual machine but this was far too great an inconvenience. Having to boot up twice to browse the web would get rather annoying. Then I thought about chrooting, which would prevent the browser from messing with my system in any real permanent way (hopefully) although a browser is a complex thing and so building a chroot environment for it would also be a complex thing.

Then I came across systrace in OpenBSD. systrace allows for an application to be wrapped by it so that any system calls can be audited and blocked if they do not match the policy. There is even an option to automatically generate a policy based on what the application uses during normal use, which can of course be edited by hand later. This appeared to be a perfect convenient solution to the problem. Unfortunately, it seems that systrace has some fundamental flaws that prevent it from being reliable as a security tool. The idea was good, but the way in which OpenBSD implements system calls just doesn’t allow for the sort of thing that systrace was aiming for.

So, building a sandbox is either going to involve a complicated initial setup (the chroot) or an inconvenience every time I want to browse the web (a virtual machine). It seems the long term solution is going to be do build the chroot, but until then, it would be nice to have at least a slightly more secure system than Firefox alone provides. This is when I came across xombrero, which I’m using to write this blog post. According to the xombrero website:

xombrero is a minimalist web browser with sophisticated security features designed-in, rather than through an add-on after-the-fact. In particular, it provides both persistent and per-session controls for scripts and cookies, making it easy to thwart tracking and scripting attacks.

In additional to providing a familiar mouse-based interface like other web browsers, it offers a set of vi-like keyboard commands for users who prefer to keep their hands on their keyboard.

The default settings provide a secure environment. With simple keyboard commands, the user can “whitelist” specific sites, allowing cookies and scripts from those sites.

It seems that “secure by default” is not actually the case in the build I’m using (from the OpenBSD 5.3 packages repository) but it was easy enough to disable JavaScript and cookies. This way nothing is enabled until it’s actually needed and at that point you can make the decision, although not necessarily an informed one, as to whether or not you want to take the risk.

Of course, I’m still vulnerable to malicious code in sites I thought I could trust, and helpless to libpng exploits as images are loaded by default and any bugs in the HTML/CSS rendering engine (WebKit in the case of xombrero) but this is definitely a step closer to the secure browser I’m dreaming of. The trouble with the web is that it’s always becoming a more complex system when really, for a lot of sites, simpler would definitely be better.