Web browsers scare me: they're huge pieces of code, un-audited, they
have embedded Turing-complete interpreters, they live in a horribly
imsecure environment,
[I have to put in a plug here for James Mickens' classic
rant "To Wash It All Aawy" (Usenix ;login, March 2014, p.2-8):
https://www.usenix.org/system/files/1403_02-08_mickens.pdf
]
they pass untrusted data to image/audio/video plugins which are also
huge/unaudited/buggy, etc etc.
So, I'm thinking about how to exploit-mitigate a web browser (I'll use
firefox here for purposes of illustration, but this is basically generic
to any other web browser). This is in the context of a single-user
OpenBSD desktop (say a laptop).
My threat model is basically:
* I run firefox
* by default, the firefox process (and any plugins) all run under
my id, with the same priviliges I have
* I browse to a (unknown-to-me) hostile website
* hostile website exploits a vulnerability in firefox or plugin to
run malicious code on my computer (with all the priviliges of the
firefox process)
* malicious code can then
- read and/or write my $HOME/.ssh/
- create a transparent X window over the entire screen to act as
a keylogger to watch for the next time I type a credit card number
or login to a banking site
- write to my login scripts to make that keylogger persistent
- try to exploit vulnerabilities in my X server
- if I'm in group wsrc, try to install a backdoor in /usr/src/*
- if I'm in group wheel, try to sudo to root to install a rootkit
- etc etc
I can see several possible forms of exploit-mitigation:
(a) use the noscript firefox extension to block javascript
(b) use capsicum to sandbox forefox and any plugin processes
(c) run firefox in a chroot jail
(d) have firefox talk to an Xephyr(1) instance
so it's semi-isolated from the main X server
(e) maybe have firefox go through an ssh tunnel to localhost
(f) run firefox as an unpriviliged user _firefox, group _firefox, and
use Unix file permissions to deny that user access to $HOME/
(a) works and offers a fair bit of protection.... until some site that
I whitelist has a drive-by exploit. :( And noscript requires considerable
handholding in practice.
(b) and (c) could offer a lot of protection... but they would be a lot
of work to port/setup, probably more work than I can afford right now.
(d) seems promising; I don't know what it would do to the ability
to cut-and-paste between firefox and the outside world
I'm not sure if (e) is needed in combination with (d) in order to
block firefox from connecting to the main X server.
(f) seems pretty easy, and offers some (modest) protection.
I have some technical questions about doing that, which I'll save
for a seprate thread.
Some useful past discussions on this mailing list include
http://marc.info/?l=openbsd-misc&m=126116965209030&w=1
http://marc.info/?l=openbsd-misc&m=135442405732373&w=1
http://marc.info/?l=openbsd-misc&m=135569662813122&w=1
http://marc.info/?l=openbsd-misc&m=135767126712239&w=1
http://marc.info/?l=openbsd-misc&m=135767705914968&w=1
http://marc.info/?l=openbsd-misc&m=135771549729476&w=1
http://marc.info/?l=openbsd-misc&m=135771660029742&w=1
So.....
Are there other practical ways of securing an OpenBSD web browser?
[I'm afraid "just say no" fails the "practical" test. :( ]
What unobvious gotchas are there in (d), (e), and (f)?
Other tips-and-tricks?
ciao,
--
-- "Jonathan Thornburg [remove -animal to reply]"
<jth...@astro.indiana-zebra.edu>
Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
"There was of course no way of knowing whether you were being watched
at any given moment. How often, or on what system, the Thought Police
plugged in on any individual wire was guesswork. It was even conceivable
that they watched everybody all the time." -- George Orwell, "1984"
