Reblogging SecureBoot

https://lwn.net/SubscriberLink/500231/0161d1d4b4b14c1a/

Really good summary that highlights the potential pitfalls of this situation.

One could simply ignore secure boot, requiring users to disable it before they can install Linux on their machines. That imposes a potentially scary or difficult task on those users; by the specification, secure boot cannot be disabled by the software directly. There may also be resistance from users who see a switch saying “turn off security” and don’t want to flip it. This approach will work fine for hard-core Linux users and developers, but seems certain to lose other kinds of users.

Pretty much hits the nail on the head there. If secureboot could be disabled through some admin control panel interface it would defeat the purpose since it’s basically meant to restrict rootkits that gain admin. So the user will either have to open the system up and flip a switch (not that daunting for the Chromebooks actually) or go through what is potentially a pain in the ass to get the keys working.

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.

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

Secure Boot In Fedora – Hope?

A recent article highlights the new world of secure-boot Windows computers and how Fedora 18 will be arriving very much around the time of Windows 8.

Secure Boot is a security implementation that aims to prevent untrusted code from running before the OS loads. It’s a powerful new security method and it directly attempts to prevent multiple different attacks that can be (and have already been) used by malware to dig deep into the system.

Implementing Secure Boot in Linux is actually really great. It’s Linux so you know, without a doubt, that limiting a users freedom is absolutely out of the question and they’ll take security to the highest level possible. Users can still use their own kernels (they just have to sign the kernel themselves, it complicates things but not a ton) so don’t worry, you don’t need to turn it off to maintain the same level of freedom as always.

After all of the entirely unjustified hype that Windows 8 Secure Boot would kill Linux or that new hardware would lock you out it’s really great to see that the Distros are working on incorporating this feature and making use of it to the full extent. I do wish it were under better circumstances instead of having to fight not to be locked out of hardware… but it’s not nearly as terrible as what it could have been and we get a neat security feature out of it.

So while Linux has had its hand forced in this situation we do gain a really neat security feature.

It’s lukewarm but I’m happy.