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.

The Free Software Foundation On SecureBoot

https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper-web

We have been working hard the last several months to stop Restricted Boot, a major threat to user freedom, free software ideals, and free software adoption. Under the guise of security, a computer afflicted with Restricted Boot refuses to boot any operating systems other than the ones the computer distributor has approved in advance. Restricted Boot takes control of the computer away from the user and puts it in the hands of someone else.

 

PatchGuard Should Mimic SecureBoot

PatchGuard is Microsoft’s implementation of Kernel Patch Protection available on Vista/7/8 64bit systems. The idea is to prevent any code from patching the kernel ie: third party code can not modify or change kernel code.

This has had an immense effect on the security of Windows 64bit systems. Rootkits are far more limited in what they can do and how they can hide.

The problem here is that no one’s allowed to patch it. That means we’re locked into the Microsoft security model, which until Windows 8 has been pretty awful (integrity levels.) So while a security company on 32bit can implement their own security model and have it act on a kernel-level (you need to be same rights or higher to properly intercept SYS_CALL etc) they’re just as limited as rootkits now, having to resort to other means to limit malware.

SecureBoot is another feature aimed at preventing bootkits. Where SecureBoot differs is that it maintains a whitelist so that signed software can actually ‘bypass’ (not truly a bypass as this is the design and strength of it) it.

It would have been cool if PatchGuard had done something similar. Had Microsoft implemented a vetting system for PatchGuard certs we’d still see security products on Windows capable of performing up-to-par with the 32bit counterparts.

Ubuntu Developer Responds To SecureBoot

I’ll preface by saying that this is not an official statement on behalf of Canonical as far as I know, simply a post on /r/ubuntu. The user is the Ubuntu Community Manager and his post about SecureBoot pretty much sums up my own opinions.

His post in its entirety: 

I think we would all agree that this is terrible that Microsoft are putting other Operating Systems in a position where either (1) they have to sign keys to boot, or (2) we have to ask users to switch off something in their BIOS that has “secure” in the title.

While mal-ware is indeed a threat, and quite nasty, I would have preferred to have seen a means in which a solution can be found that is not controlled by a large corporation who themselves has an Operating System product.

From an Ubuntu perspective, we are going to do everything that we can to ensure our OS boots on the widest range of hardware possible, and the story that Matthew Garrett tells is similar to our experiences in the Ubuntu world. Matthew’s story, and the challenges he has explored are not specific to Fedora, but to all Linux distributions.

I think the problem Microsoft is trying to solve is admirable…mal-ware at that lower level is dangerous, but I think the solution is putting companies like Canonical and Red Hat in a tough spot. [1]

This hits the nail on the head, really. Microsoft is trying to solve a problem and that’s great but in doing so they are putting distros and Linux users in a difficult place. As he says, it’s now a matter of supporting SecureBoot and paying VeriSign or asking users to disable a security feature.

One Final Post About SecureBoot?

I did a post highlighting the positive side of things and then a very negative M$$$-bashy type post. I want something I can point to that at least makes an attempt at fair and balanced with enough information for the reader to make a decision so here it is.

What Is SecureBoot?

SecureBoot is a UEFI protocol that blocks anything that isn’t digitally signed from running before the operating system starts. Essentially, untrusted code can not start before trusted code. This directly addresses an entire class of malware and attacks that we already see on systems in the real world. On a SecureBoot system the malware could not start up because it is not digitally signed.

Windows 8 (currently in Release Preview) uses SecureBoot by default on systems that have “Windows 8 Approved” hardware. This means that, by default, these systems will only boot code that’s been digitally signed.

You can disable SecureBoot on x86 devices but not ARM.

So How Does Linux Fit Into This?

Linux, in a SecureBoot environment, is considered untrusted code. It isn’t signed, therefor it can’t boot. Thankfully Microsoft has ordained that all x86 devices must allow the user to disable SecureBoot and users will also be able to sign software with their own keys. You can also purchase a Microsoft signature.

The problem is that, while Linux is not entirely locked out, it’s still discouraging. As a user you have two options:

1) Disable a security feature (potentially difficult to do)

2) Go through the procedure to sign your software with your own key (almost definitely very difficult to do)

And as a developer your options are:

1) Tell anyone who wants to use your OS to disable a major security feature (discouraging)

2) Pay 99 dollars to VeriSign for a Microsoft signature.

These options aren’t good. Microsoft has not locked Linux out but it’s now more difficult for small Linux distros to gain members and it’s more difficult for users to make choices about which distro to use.

And, to reiterate, Linux is entirely locked out of Windows 8 ARM devices.

It’s worth noting that other distros can not simply use Fedora’s bootloader. The entire chain of trusted software must be signed including kernels and modules. This is what complicates things for distros. I personally run my own kernel so this complicates things a ton for me as I now have to go through the process of signing my own kernel and modules and blah blah blah every damn time (well, not really, I don’t have EFI, but I would.)

So Is There A Bright Side?

There is, and in the spirit of fair and balanced I will delve into it.

SecureBoot is actually a really awesome feature. It prevents cold boot attacks* on disk encryption, it seriously restricts malware, and it’s actually implemented in an not totally horrible way (we can sign things! Way better than patchguard!)

*by preventing immediate loading of a livecd/usb for it. It also prevents bootkits, which bypass encryption.

Microsoft is actually subsidizing VeriSign keys so that they’re only 99 dollars (SSL certs can be 200-300 dollars and only last 1-3 years) so that’s pretty nice I guess…

And Linux distros are in fact already working on implementing SecureBoot, which will make transitioning to Linux (well, to some distros of Linux) as smooth as ever while still providing a really fantastic security feature. Fedora has already confirmed it’s working on it and Canonical is likely to announce the same soon.

SecureBoot is actually one of the better security protocols to come about. It’s not some silly little thing to block out mere theoretical attacks, it’s legitimately a strong layer of security.

How Should I Be Feeling?

I can’t really tell you how to feel about this situation. Some people are just happy for the security and are fine with using a big name distro and others are outright pissed at Microsoft and calling for their heads on a plate. But it’s my blog so I’m going to tell you how I feel…

Honestly, I’m really into security so part of me is happy to see it happen… but it feels very forced. I would have preferred to see this come about naturally. If SSL had come about naturally we probably wouldn’t have all of the problems we see today with CA’s just ‘tacked on’ as a last resort “couldn’t think of anything better, had to rush it” type deal. If the community had openly discussed how to do this in a way where everyone benefits I think things could have not only gone smoother but we would also end up with a more secure product. SecureBoot as an idea is amazing, one of the best ideas for security in the last few years really, but this is not the proper process for implementing it.

My 2 cents, I think this covers everything.

SecureBoot For Linux – What It Means For The Little Guys

In my last post about SecureBoot for Linux I was a lot more positive. Let me focus on why there’s more to it than a cool new feature.

SecureBoot is a security technique that prevents untrusted (unsigned) code from starting up before the operating system. Many rootkits start before the OS in order to bypass antiviruses and other forms of protection. SecureBoot will put a stop to this and it should be very effective.

When Windows 8 is released all “Windows 8 Approved” hardware will ship with SecureBoot meaning that only signed software, and that includes operating systems, can boot. So how does Linux fit into this?

Well, an unsigned Linux distro won’t be able to boot. That means they either have to get their own signatures onto the hardware by working with OEMs or they have to pay Microsoft to use their key. (Actually they pay VeriSign, Microsoft provides a subsidy.)

Yep, distro owners now have to pay VeriSign 90 dollars if you want your Linux distro to run. Now, that’s really not a huge deal for anyone running something like Fedora or Ubuntu – Fedora has already stated that they will be doing so. But what about smaller projects? There are hundreds of distros and not all of them are going to be able to just send out 90 dollars – they already have costs for maintaining and developing the system.

Maybe 90 dollars isn’t a huge amount of money but the sheer principal of having to pay VeriSign to run an OS that isn’t theirs to control is pretty backwards.

Look at Hannah Montana Linux. Yes, we can joke and laugh, it’s a bit silly but the idea is that there is a Linux for everyone. Someone out there thought “Hey, I bet some kid out there would really like this and I’m going to go for it” and it’s ideas like that that make Linux so amazing. There is absolute freedom. Anyone can set up their own distro and Microsoft shouldn’t be able to do a damn thing about it.

And yet something like Hannah Montana might not happen in a world dominated by SecureBoot systems. It stops being “this’ll be a fun project that some kids will benefit from.” SecureBoot outright prevents really great systems from being built. It limits that potential. Asking a user to install or dual boot Linux now means asking them to disable security features provided by Windows or the Distro owner has to pay VeriSign.

tl;dr Hannah Montana is the epitome of Linux and Microsoft is trying to kill it.

Windows 8 Release Preview Is Out – Let’s Talk Security

I could take screenshots and do a full review of the Windows 8 OS but some other blog that gets paid to do reviews would just do it better so I’ll stick to what this blog is for – security.

Windows 8 has officially been released as a Release Preview, meaning that just about everything you see in this RP is what you’ll see in the final release. The biggest changes in Windows 8 are pretty surface – the highlight is an entirely new Metro UI, which features a full screen start page and various other major UI changes. There are also some big changes under the hood – Windows 8 is a lighter, faster OS than 7 with lower RAM usage and improved multicore support. And then there’s security…

ASLR

Address Space Layout Randomization (ASLR) is a mitigation technique first designed by PaX foundation. The idea is to randomize a programs address space (the range of virtually memory addresses that make up a process) in order to prevent Return Oriented Programming (a technique used to bypass Data Execution Prevention.) Essentially, because the attacker does not know where areas of the address space are they are unable to make use of that address space in a way that would otherwise allow further compromise of the system.

ASLR relies on the attacker not being able to guess the location of address space. They only have three real options (in terms of defeating ASLR):

1) Find part of the address space that isn’t ASLR enabled

2) Make use of information leaks

3) Bruteforce through the addresses

Windows 8 attempts to directly address (1) and (3.)

/FORCEASLR

In Windows 7- if I run a program like Firefox*, which is ASLR enabled but I use Norton Toolbar, which isn’t ASLR enabled I basically defeat the purpose of ASLR because there’s a predictable address. Windows 8 address this with /FORCEASLR, a compile time flag that will force the entire address space to be ASLR enabled (oversimplification, not entirely true, good enough.)

The benefits are obvious, simply using the /FORCEASLR flag in your program means that no other program will significantly degrade the effectiveness of ASLR.

*Firefox has actually solved this issue by forcing toolbars to use ASLR. It’s an outdated example but it works.

Improved Randomness

ASLR effectiveness necessitates the inability of an attacker to guess or predict locations of address space. If there isn’t sufficient address space or there isn’t sufficient entropy the ASLR won’t be effective and an attacker can bruteforce their way to a useful area.

Windows 8 has improved the random number generator and thereby increased randomness in ASLR.

For 32bit systems this is important. Virtual address space on a 32bit system is much smaller than that of a 64bit system (addressable space on 32bit is 2^32 as opposed to 2^64 for 64bit) so bruteforcing is much easier. Improved randomness will make this more difficult – though because of the small address space it’s potentially a lost cause.

Guard Pages

Guard pages work to prevent usable buffer overflows. Developers can make use of Guard Pages to protect areas of address space – when an attacker tries to overflow an area protected by Guard Pages, they’ll end up throwing an exception.

AppContainer

There aren’t a lot of details about AppContainer yet but it looks like Windows is finally getting proper Mandatory Access Control. The ability to apply finely grained application MAC is hugely beneficial both to preventing and limiting exploitation.

Programs don’t have to squeeze into low integrity anymore, they can use whole-process sandboxes (which aren’t actually better, just easier) to segregate themselves from the system.

The jury’s out on this feature. If it’s as powerful as AppArmor I’ll be happy.

Internet Explorer 10 Metro

IE10 Metro runs in the new Metro environment (WinRT) and is sandboxed from the rest of the system.  It also contains a built in Flash player, which Microsoft has integrated into the browser for improved stability, security, and performance. A smart move on Microsoft’s part as the Flash player is still necessary for viewing a ton of the internet and it is also one of the most commonly exploited applications.

Internet Explorer 10 Desktop

The desktop IE10 (and this applies to Metro) will make use of all of the new security mitigations like FORCEASLR and improved randomness. IE10 will also include an “Enhanced Protected Mode”, which implements a further least-privilege mode based on the earlier Protected Mode principals.

The enhanced protected mode continues IE’s least privilege model, which is great and it should prove more difficult to break out of.

Full System Smart Screen

Smart Screen is an application reputation and heuristics system. Previously it was built into IE9 and an NSS Labs report noted it blocking 96+% of malware (there isn’t enough research on the effectiveness, take that report with a golf ball sized chunk of salt.)

SmartScreen in Windows 8 is now system wide. If an application hasn’t been seen before by MS you get a little message saying “hey, we haven’t seen this before, be careful.”

Personally, I don’t like it and I don’t think it will be effective. That’s just me. I don’t think users are capable of making decisions based on information like that and it threw me a ton of “false positives” (not actually FPs as it’s not calling it malware, same principal) so my trust in its opinion of software is seriously diminished. It won’t be effective for the same reason an AV that throws false positives isn’t effective – if I can’t trust the product I’ll never know when it’s right or wrong.

We’ll see.

SecureBoot

SecureBoot is a much reviled feature as everyone though MS would be locking Linux out of Windows 8 hardware. As I posted about earlier Fedora is already working on implementing it. SecureBoot prevents untrusted code from running before the OS. This will prevent rootkits from bypassing full disk encryption and/or wedging themselves deep into the operating system. It’s a great security feature and I think it will be very effective.

Microsoft Security Essentials 

MSE is a widely used antivirus known for being pretty light and quiet – no false positives. It provides pretty decent detection ~50% when out of date and making use only of heuristics (most people probably don’t stay up to date) but I think we can expect that to fall.

As MSE has gotten more popular it’s also started to drop in performance. This is the case with any popular program. The first thing a hacker will do with their payload is test it against a number of antiviruses (automated tools exist for this) and if it passes by MSE but maybe Panda catches it they might release it anyway because MSE still makes up a huge part of market share.

Windows 8 will increase that market share and increase how seriously hackers take bypassing MSE. It’s detection, not preventative, so it’s flawed in that way.

Did I Miss Anything?

I’ve probably forgotten something. If so, leave me a comment.

All in all, Windows 8 is significantly more secure than Windows 7. If AppContainer turns out well it’ll be a huge boon. Even without AppContainer the numerous memory protections added as well as SecureBoot put Windows 8 far ahead of 7 and I’m excited to see Microsoft really taking security seriously. Personally I still feel safer on Ubuntu thanks to being able to do this but it makes Windows feel way more viable and competitive.

Sources:

https://blogs.msdn.com/b/b8/archive/2011/09/15/protecting-you-from-malware.aspx?Redirected=true

https://blogs.msdn.com/b/securitytipstalk/archive/2012/03/27/internet-explorer-10-offers-enhanced-security.aspx?Redirected=true