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:

CONFIG_GRKERNSEC_CHROOT_FINDTASK

CONFIG_GRKERNSEC_CHROOT_CAPS

More restrictions on our exposed service.

Apparmor

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.

Conclusion

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

Hardening Ubuntu Linux

I’m going to keep some tips here for users looking to improve their security, when I update it I’ll tweet about it, so feel free to follow me @insanitybit. This is aimed at desktop users but naturally lots of it can apply to a Linux server. Some of this will be simple, trivial, and some of this will be quite a bit more difficult. I’m focusing specifically on Ubuntu but other distros will have similar features (replace Apparmor with SELinux). I will try to make this as comprehensive as possible, though I’m specifically avoiding items like Fail2Ban as it’s not really useful for users. You can consider this an extension of my ‘definitive guides‘ – The Definitive Guide For Securing Linux Ubuntu.

A lot of users believe that a distro such as Ubuntu will be so much more secure than Windows, purely through virtue of obscurity. As Linux popularity continues to grow you’ll see attackers begin to take notice. Just because attackers don’t care to hack Linux desktop systems does not by any means imply they aren’t capable of it, or ready to when it seems profitable.

Thankfully, Linux is really easy to secure. Despite some problems there are a lot of powerful projects that give users the power to secure themselves against many threats.

Securing Your Browser

First I’d like to start by linking to my guides for locking down Chrome and Firefox As a user your most exploitable area is your browser, it’s constantly taking in untrusted content, often over an insecure connection. I personally love Chrome’s Linux sandbox, but Firefox with NoScript is very powerful as well – I leave it to you to decide between the two based on your needs.

Enabling Ubuntu’s Firewall

Ubuntu comes with a firewall utility called UFW, but it isn’t enabled by default. The reason is that, by default, Ubuntu doesn’t have any open ports open (except for system services that are typically necessary for the average user). So is a Firewall strictly necessary? Well, if you’re behind a NAT router not so much, any open ports will expose you to local attacks, but you’re ‘hidden’ from the internet. Still, if you’re looking to secure your system you can simply run this command:

ufw enable

ufw default deny incoming

And it should prevent inbound access. You can create complex rules via iptables to restrict or relax your rules. You can also check out GUFW for a graphic interface to UFW. GUFW makes everything very easy to use.

You can use UFW/GUFW to create outbound rules for applications. Due to the amount that applications within a user ID can interfere with one another I do not feel that an outbound firewall is worthwhile for security, and it can be quite a bit of a pain. If you’re serious about setting up an outbound firewall I suggest you make strict use of user separation and apparmor, though even then the benefits are questionable (there is a reason programs like Comodo on Windows bundle their firewall components with strict HIPS software).

See this guide for further information on setting up firewalls. Courtesy of a very smart guy, Dangertux.

Run a Program As A Separate User

While the simplest way to restrict a program is AppArmor (see below) you can also make use of the native user/group Linux permissions in order to run an application as a different user. I’ve written a guide with Pidgin as the example. Separated programs will have less access to one another and they’ll live in a different user directory, with access only to that directory.

By separating a program to a new user we can also write more powerful firewall rules, as the program won’t be able to bypass an outbound rule as trivially.

For a risky program that doesn’t need to access other programs this may be a very viable option. For example, I run Xchat, which hasn’t been updated in about two years. For a program like this throwing as much security as possible at it isn’t a bad idea, since it doesn’t get patches, doesn’t use modern security techniques, and is internet facing.

Restricting DMESG

By default unprivileged users can read a lot of your systems logs. These logs can contain critical information for an attacker hoping to exploit your system further.

This is useful for debugging, but you’re not likely to have to do that. Running this command will prevent access by unprivileged users:

echo kernel.dmesg_restrict = 1 >> /etc/sysctl.conf

This feature is also included in the Grsecurity patch.

DNSCrypt

DNSCrypt is a DNS resolver that encrypts the content of your request between you and the first level resolver. It prevents an attacker from hijacking or viewing your DNS resolution and the program itself is hardened quite a lot.

For a guide to install.

For a guide to harden further.

Removing Attack Surface

One of the first steps to harden any operating system should always be disabling unnecessary programs/ services. Desktop operating systems don’t come “default secure” they come “default compatible” and that means meeting the needs of every person, generically. So while John may use his network printer Jane may not, but Jane’s system still comes with all of the attack surface necessary for network printing.

The network printing service is cupsd. It comes, by default, in an Apparmor profile, so it’s not like you should be incredibly worried about being exploited. And if you’re behind NAT you’re only exposed to local attacks. But, if you’re like me, you don’t print over a network and you have no need for this service. Are you likely to be attacked over it? Maybe, maybe not, but it’s not needed. So go ahead and remove that service.

You can check for programs listening on your system with the following command:

netstat -tulnp

Look up any services and carefully consider the benefit/ necessity of them. If you don’t need them or want them, remove them.

Another tip is to use checksec.sh. Run the following command: (You must first set the file as executable)

./checksec.sh –proc-all

It will provide you with a list of running services along with information about their security – whether they use NX, stack canaries, and if they’ve been compiled as Position Independent Executables (PIE). This may help you make a more informed decision about removing a service.

Mount /tmp With noexec,nodev,nosuid

Many programs require read/write access to /tmp but, for the most part, no programs actually need to be able to execute from there. Mounting this area with the noexec, nodev, nosuid can provide some level of security. Rather than creating a new partition for /tmp I find it’s just easier to use RAM (it expands as needed and doesn’t require partitioning , one benefit being a (potential) performance increase, though I wouldn’t bet on it.

Copy the following into your /etc/fstab file.

tmpfs /tmp tmpfs mode=1777,nosuid,nodev,noexec 0 0

If you want to create a new partition for /tmp you can find a guide online for that. It’s kinda a pain. The downside to running it in RAM is, obviously, you lose some RAM. If you want to limit the amount of RAM it can use (tmpfs expands as needed) you can change the line to (for 512M):

tmpfs /tmp tmpfs size=512M,mode=1777,nosuid,nodev,noexec 0 0

I recommend that if you follow the above you make use of AppArmor to improve the level of security this adds. If you use /tmp in RAM one benefit is that, in your AppArmor profiles, you should be able to remove map rules for some programs that map /tmp for performance reasons.

AppArmor

AppArmor is the Linux Security Module of choice for Ubuntu. It implements Mandatory Access Control on a per-process basis. It’s very simple to learn how to use AppArmor and I’ve written a guide. In the guide I provide tips for creating strong AppArmor profiles and avoiding potential pitfalls.

A program like Pidgin has a lot of access to your system. It runs as the same user as many other programs on your system and therefor is granted a fair amount of control over them. It can read many areas of the system that it doesn’t need to read, it can write to quite a few too. AppArmor restricts it to only the resources it needs, making both remote and local privilege exploits more difficult to pull off.

I’ve written a few very strict AppArmor profiles myself that you’re welcome to use as a starting point. [Xchat][Pulseaudio] [Java]

32bit users will have to adjust as needed, though it should be as simple as replacing the x86_64 with i386 (I’ll add variables for this at some point so you won’t have to).

Every internet facing program deserves an AppArmor profiles. It’s the simplest way to implement least privilege on a per application basis.

PaX and Grsecurity

PaX and Grsecurity are patches for the Linux kernel (the Grsecurity patch contains both, don’t just use PaX). PaX and Grsecurity have been at the forefront of security for more than a decade, bringing some of the most important security mitigation techniques to systems today, such as Address Space Layout Randomization (ASLR). ASLR is a great example of a mitigation technique that doesn’t have a great implementation in typical vanilla systems. The ASLR in your average distro, like Ubuntu, introduces far less entropy into the system, which degrades its use. The ASLR is also missing critical features, such as brute force deterrence, among others. PaX and Grsecurity bring these features and many many others to Linux. No operating system has as complete ASLR as PaX and, really, nothing else compares.

Not all of these features are compatible for desktop users, or even necessary, but a number of them will work on an Ubuntu desktop. You can see my guide for patching and compiling a Grsecurity Linux kernel, with notes about compatibility issues for desktop users.

Many of these security features directly relate to desktop security. Many applications and services use chroot to run programs in a separate environment. Chroot is incapable of restricting programs that can run as root, multiple bypasses are possible. Chrome is one such program, along with many other services (like avahi-daemon), so using the chroot hardening features of Grsecurity will provide a considerably more secure environment.

PaX and Grsecurity can be implemented with very little performance overhead, and very few stability issues if configured properly. If you’re really looking to secure your Linux system and you’re willing to take the time to compile it you should give it a try.

Learn how to compile your own Grsecurity Linux kernel here.

Patching

None of the above will make up for a system that is out of date and unpatched. If you’re using an older kernel and userland applications an attacker will be able to chain together enough exploits to bypass any restrictions/ measures you’ve taken, no matter how powerful. Make sure to stay up to date for all applications.

You can push patch time further by hardening the system – time to develop an exploit for a hardened system is longer. This does not mean you can postpone indefinitely, it just buys you time to test patches and improve your patch management.

Something To Keep In Mind

This all works best in conjunction. Grsecurity and PaX are honestly the best security software there is, in my opinion, but they can’t make up for a completely insecure userland. If you’re running programs that opt out or don’t make use of modern technology there’s only so much they can do. It’s very unfortunate but, even on 64bit, Ubuntu ships with a lot of services not using Position Independent Executable code – at this point it’s necessary to harden the programs in other ways.

And the same goes both ways. If you’re not using Grsecurity and PaX then your kernel is less secure, meaning that even if you harden a userland application with apparmor an attacker will have a much easier time exploiting the kernel and escaping the profile.

If you’re annoyed about your distro coming with insecure settings email them about it. You can reach Canonical:

http://www.canonical.com/about-canonical/contact

 you have suggestions for canonical.com or ubuntu.com, please email us atwebmaster@canonical.com or webmaster@ubuntu.com.

And if you have any suggestions for this guide please let me know in a comment. I’ll happily include any relevant information.

Follow me @insanitybit for updates and more articles like this.

Speeding Up Unity On Ubuntu With ATI Cards

I use Ubuntu 12.10 with Unity and I run a mid range ATI 5000 series GPU. Performance was surprisingly good in 12.10 after a fresh install (upgrade made performance horrible) but while playing Flash/HTML5 video things slowed down considerably, and using Super + W (expose) was much slower.

I searched around for some quick tips and found two that have apparently improved things significantly.

sudo apt-get install compizconfig-settings-manager

Then go to the CCSM and the OpenGL plugin and disable “Sync to Vblank”.

Go back to CCSM and then the Composite plugin. This time disable the “Check refresh rate”.

Expose is now much quicker/ smoother. Noticeably so – even while I’m playing video in Chrome. The difference is like night and day – I can reload pages/ tabs alongside the video and move windows around and it’s all smooth.

Make sure you’re on the latest ATI drivers. Due to Valve pushing for better Linux drivers the most recent versions (12.8/12.9) feature vastly improved performance.

The Ubuntu Amazon ‘Privacy’ Issue

There’s been a lot of talk about a recent feature to Ubuntu 12.10 – when you type into the Dash you receive back information from Amazon based on your input. There’s a massive outcry that this is a privacy violation or even a security issue, and the media’s been fueling it as much as they can. I’m going to try to explain what’s going on here and where the issues actually lie.

How It Works

The feature activates when you type messages into the Dash – a feature of Unity that takes in your text input and outputs relevant information. When you type into your Dash info is sent to Canonical and then Canonical sends the info to Amazon, the information is then sent back to Canonical form Amazon and finally lands on your system. What is sent is only what you type in, nothing more.

The idea here is that I can type in “Vacuum” and now I get books on vacuum cleaners or some such thing. The Dash is meant to be a ‘conduit’ of information, you type a word and it responds with everything related to that word. Amazon is just one more way to provide information to you.

The Problem?

Users seem to think this is a privacy issue. I think people hear “OMG Ubuntu has Amazon ads now! And it can see what you type!” – no. No, Amazon can not see what you type and they’re not ads. They can see the words you put into the Dash and Canonical acts as a proxy, so really, it’s Canonical that “sees” what you’ve typed into the Dash.

So this isn’t some full system keylogger or some such thing, it’s Canonical (the company behind Ubuntu, that packages your system components for you) seeing what you type into the Dash.

So ask yourself – what do I type in the Dash? For me it’s simple – I would type “Pidgin”, “Chrome”, “Homework” and open those files/ programs via Dash. Not exactly personal information.

Unless you’re typing in “porn” or your social security number perhaps you should question how sensitive the information in your Dash really is. Really, what is it that you enter that’s scary?

And then remember that Canonical doesn’t need some clever Dash keylogger to steal your information… they’ve “got root” as Mark Shuttleworth put it. If you don’t trust Canonical you shouldn’t be using their Operating System because they could easily patch up a kernel to spy on you or any other system component that they build on your behalf.

I’ve heard people claim “But what if someone accidentally puts a password in?” well, uh, yeah, that sucks! Canonical then sees your password… not that they need it since, again, they have root. And all of this information is sent to Canonical via secure encrypted connection.

Even beyond all of this users seem to have missed that it’s always been this way. Yes, your Dash has always communicated via internet – how do you think it gets ‘recommended apps’ from the software center? Or music? It’s done this for a long long time and nothing has changed.

And, of course, you can easily disable this by typing “Privacy” into the Dash and disabling the feature.

It comes down to a simple question – do you trust Canonical?

Ubuntu Rethinks SecureBoot – GRUB Is Back In

SecureBoot is a feature of Windows 8 implemented through the EFI hardware on the latest laptops. The feature aims to allow only trusted and signed code to run when the computer starts up, which would cripple many rootkits. An unfortunate side effect to this is that legitimate code that’s not signed won’t run so if you were to try to boot (for example) Ubuntu in its current state it would fail, SecureBoot would recognize it as untrusted code.

There was a lot of commotion over this but leading distros such as Fedora and Ubuntu have had a public response. Ubuntu had previously planned on implementing a primary bootloader, which would be signed, but it wouldn’t be GRUB. The issue with GRUB was cited as the GPL3 license being too restrictive. Because the key used to sign the bootloader has to remain a secret Canonical (the financial backers of Ubuntu) feared that, through the GPL3, they might be forced to release the code. The GPL3 is kinda shitty because it, in so many words, states that no part of the software using GPL3 code can be closed source. The EFF (holders of the GPL3) have decreed that the private key is not an issue and it won’t violate the GPL3 to keep it private.

As such Canonical has decided to keep GRUB and use it in its SecureBoot implementation.

Valve Starts A Blog About Linux Gaming – Steam Immenent

The Valve Linux Team has started a blog dedicated to gaming on Linux. There was confirmation some time ago that games would be coming to Linux through Steam and it’s great to see them putting their full force behind this.

The truth is that this whole situation has been surrounded in rumors and this blogs purpose is to give you a direct line to the source.

I think what’s exciting is that even non-gamers will benefit. 

1) More games = more users. I know dozens of people who would switch to Linux if it weren’t for games.

2) More games = better driver support! Well, hopefully. It would be great to see GPU vendors take Linux more seriously.

So I’m excited. I won’t ever ditch Windows entirely for one reason or another but at least now I’ll have one less reason to boot into it.

Just got Windows 7 Installed

So as you may have read I’m now using a 128GB SSD. I’ve allocated 87.4GB of that space to Windows 7, which I’ve secured with EMET (DEP Always On, SEHOP Opt Out, ASLR Always On).

The vast majority of this space is going towards games. Borderlands is a full 21GB (don’t ask, special version) and Skyrim is another 7GB or so.

I have another 40GB of space for my Windwos partition and about 25GB for Ubuntu. Plenty. I could fit a whole other OS on here.

Why So Few PIE Executables?

What’s up with this? The output for checksec.sh shows the vast majority of packages running PIE’less.

How is this still the case? Some of these are SUID binaries (pulseaudio) and it’s really weird that they aren’t PIE enabled. Quite a few are missing stack canaries as well.

Why?

edit: After looking most of these seem to be related to Unity. I looked a few up and removed them as I don’t need them. Better, but not great – I don’t mind that my indicator-cpufreq doesn’t support PIE, what I mind is Ubuntu shipping with so many not using PIE/ stack canaries.

edit2: A user commented explaining that on x86 there is a significant performance impact. I was actually aware of this but I didn’t realize how significant. The thing is, I’m on 64bit, and I don’t really want PIE on *every* executable file.

The issue is not that *every* package is not using PIE. It’s that so many packages that seem ‘security critical’ are not using PIE eg: I don’t care so much that hud-service is running without PIE but I do care that Pulseaudio (SUID) and DNSMasq are running without PIE.

Fedora Just Won’t Install

It’s consistently telling me there’s a problem with my file system. There isn’t.

This is a shame because I find it kinda weird that Ubuntu doesn’t have exec-shield, software that allows you to control DEP policies in a similar manor to EMET. The great thing about Windows is that, through EMET, you can set policies for DEP and ASLR.  Ubuntu doesn’t have that.*

It actually doesn’t suck that much since NX is used in literally every process on my system. It’s not that big a  deal. But I still would have liked to have tried Fedora.

 

*Actually Ubuntu can change ASLR policies through 

/proc/sys/kernel/randomize_va_space
By default (2) it randomizes mmap base, heap, stack, and VDSO page. 

Ubuntu v Fedora And My New Solid State Drive

So last night I was installing Fedora just to see how it is and my hard drive, which had been clicking for a while, up and died. It just choked then and there.

So today I picked up my new Samsung 830 128GB. Very nice drive, very nice price too – less than a dollar/GB. After two hours of trouble shooting just to realize I hadn’t plugged it in properly I’m now installing Ubuntu and Fedora. I’ll keep them both installed and I’ll hopefully be able to compare the two and pick one for my future usage.

Fedora and Ubuntu are really two of the biggest names in Linux so I’m really interested to see how I adapt.