Assessing My Own System
So I’m sick today, and very very bored. Nothing out there is interesting right now so I have nothing to really write about. So I’m just going to write about how I secure my system, and where the threats are on a system configured this way. Very bored.
I run Ubuntu 13.04.
Attack Surface
The attack surface on this system is fairly easy to determine – where is data coming in from? Keep in mind that my system is not default, I remove and disable many programs/ services that could otherwise expose me to local attacks.
Mainly, these are the only programs that interact with the outside world:
1) DNSCrypt
2) Chrome
3) Pidgin
4) DHClient
5) Updates (apt)
6) Kernel *
These are the programs that interact with the internet, and that’s where the initial attack is most likely to begin – physically local attacks are less important to me, as that would entail someone broke into my house and I have other shit to worry about.
- The kernel is only exposed to the outside world through TCP/IP stack, and in this case I’m only assessing it as a threat for local attacks.
DNSCrypt
DNSCrypt is a program used to encrypt your DNS requests. It’s a cool program, and while it interacts with the internet, it’s pretty secure. It chroots itself and uses secure flags. I have it running in an Apparmor profile that limits rights significantly, I have iptables rules set up to restrict its internet access, I have the UID it runs in running with few rights and TPE restrictions.
The product isn’t out there that much as far as I know, so there could still be some surface vulnerabilities in there. Thankfully, because DNSCrypt’s developer took the time to secure it, attacks on it would be very difficult – an attacker may compromise DNSCrypt but they are left in a severely limited environment and the easiest way out would likely be a local kernel exploit (more on this in the kernel section).
I would deem DNSCrypt very difficult to attack.
Chrome
My browser of choice is Google Chrome Beta, which, like DNSCrypt, also makes use of modern mitigation techniques and chroots. Chrome has a really powerful sandbox, making use of many of the security features of Linux including namespaces, chroots, and seccomp filters.
Chrome takes in untrusted input all of the time. Loading this page I sent out input, and I got unencrypted input back – I have no real way to determine whether an attacker intercepted the transmission and sent me back an exploit page and this is the case every time I load an unencrypted page.
So Chrome definitely deals with a lot of hostile code very directly. But the areas of code that are most exposed – the Javascript renderer, Flash plugin, etc, are all run within very restricted environments. On top of that Javascript is limited by TLD and plugins are all click to play. I also run Chrome in an Apparmor profile.
So while an attacker has a lot of opportunity to exploit Chrome they will have a very difficult time breaking out of the sandbox. In a typical sandbox the path of least resistance is often exploiting the kernel to bypass the restrictions but Chrome limits kernel exposure with seccomp filters making that much harder.
I would deem Chrome incredibly difficult to attack.
Pidgin
Pidgin is an IM Client, and it also takes in untrusted input by default. It makes use of modern mitigation techniques as well, but doesn’t use any sort of sandbox like the above programs. Pidgin messages are not encrypted, so an attacker could potentially MITM them, substituting their own messages, potentially allowing an exploit. They could also simply instant message me through a friends compromised account, or even through a new account if I’m convinced to ‘allow’ the message (I almost always do if the name isn’t blatantly spam).
I run Pidgin in an apparmor profile, so there is a sandbox around it, but it’s less than ideal as a lot of exceptions must be made to allow it to work properly. An attacker could potentially abuse Px, Cx rules to gain rights.
Pidgin is likely the easiest program to attack on my system, though that isn’t saying much as an attacker still needs to do quite a bit of work.
DHClient
DHClient is responsible for assigning the computer an IP address based on the network configuarion. It only listens to the local network, so it’s not exposed outside of my network. Because of this an attacker must go through another component on the network – my phone, another laptop that’s connected, or the router. they must then attempt to exploit DHClient.
DHClient also uses modern mitigation techniques, and it’s run within an Apparmor sandbox.
Because it is only exposed locally I would consider DHClient incredibly difficult to exploit.
Updates
Every time I update I take in some executable file and run it as root. I don’t know of a single distro that updates over a secure connection like HTTPS, but they do all sign packages by default. The issue is that signing is not enforced (that I know of) so one application may not use a signature. If that’s the case an attacker just replaces the application with their own, and it’s installed.
I believe every package I have installed is in fact signed, which means that an attacker would have to find a hash collision, which is incredibly difficult and something only an incredibly motivated and rich attacker (as in a country) could possibly due, and doubtful in the case of SHA any time soon.
Attacking apt in this way is not currently feasible, though once there’s more work on attacking SHA it could very well be – Flame did it for MD5.
Kernel
The kernel is the core of the operating system – I’ve mentioned local privilege escalation multiple times as a way to bypass other security measures such as sandboxes. That escalation exploit is most likely to go through the kernel.
I compile my kernel with Grsecurity, which makes exploitation of kernel vulnerabilities significantly harder. There are numerous mitigations that are years ahead of what you’ll find elsewhere, so an attack on the kernel may be completely removed, or, it might take weeks instead of days to create.
Attacking a Grsecurity kernel, even after you get remote code execution in one of the above programs, is very difficult.
Where I Could Be Better
I could set up RBAC through Grsecurity, which would be an extra layer of access control.
Ubuntu could start shipping PIE so that an attacker can’t attack a root service locally as easily.
Ubuntu could start using TLS for updates.
Pidgin and DHClient could implement seccomp filters.
Conclussion
That’s pretty much it. That’s where I see my attack surface, and you get a little insight into how my own system is set up. I honestly don’t feel that I need to do most of this to stay safe, but I get very bored and using these tools is nice motivation to learn how they work in detail. So you get to see what ‘security through boredom’ truly means.
blog comments powered by Disqus