Bottomley: Owning your Windows 8 UEFI Platform [LWN.net]

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 18, 2013 3:44 UTC (Mon) by heijo (guest, #88363)
Parent article: Bottomley: Owning your Windows 8 UEFI Platform

An easier and better plan:
1. Disable Secure Boot
2. Business as usual

to post comments

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 18, 2013 10:14 UTC (Mon) by dsommers (subscriber, #55274) [Link] (9 responses)

Which also reduces the security layer secure boot adds. But of course, security stuff is always so complicated so lets just turn everything off and hope for the best!

/me wonders if people have completely forgotten these good old boot sector viruses

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 18, 2013 11:31 UTC (Mon) by ekj (guest, #1524) [Link] (8 responses)

Secure boot makes essentially zero difference to the security of the average computer-user.

The things she cares about are trojans sniffing things like banking-details and passwords, and perhaps weaknesses in browsers or other exposed programs that leads to the PC becoming zombied.

Secure boot makes essentially no difference to any of this. If you've got a unpatched IE, or an outdated version of Java, or if you double-click everything you get in email, you're precisely as screwed with or without secure boot.

Of course the average PC-user also never changes OS, so secure boot would likely not even be noticed by her/him anyway.

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 18, 2013 12:42 UTC (Mon) by dsommers (subscriber, #55274) [Link] (2 responses)

> The things she cares about are trojans sniffing things like banking-
> details and passwords, and perhaps weaknesses in browsers or other
> exposed programs that leads to the PC becoming zombied.

True

> Secure boot makes essentially no difference to any of this. If you've
> got a unpatched IE, or an outdated version of Java, or if you
> double-click everything you get in email, you're precisely as screwed
> with or without secure boot.

True too. But you then ignore that secure boot removes an attack vector. That attack vector has not been used as much as it was during the DOS times, where BIOS vendors after a while added features to block writes to the boot sector. Secure boot ensures that the core OS loaded is unmodified. Which can even be seen as an extension of this old "don't write to boot sector" feature.

Secure boot makes it in fact harder to modify the earliest code loaded on a system. If you get trojans, backdoors, keyloggers, etc loaded at the very earliest boot stages, it is also more likely you can hide that code from the end-user's additional security programs. This is the attack vector secure boot can defend against. And the reason such an attack might be possible, is due to lack of secure boot and not properly updated system with latest updates for OS, third-party software and anti-virus/anti-scam/anti-spam/anti-whatever software. Secure boot is an additional layer of security, not a replacement of anything else.

Sure the boot process might not be the easiest attack vector at all, but the end-user side is getting more and more attention through security products, making the currently used attacks harder. Secure boot is just filling a gap, a gap which is best solved hardware wise. And if nothing is done in this area, this is where more attacks will be diverted in the future. And with "nothing", I also include "disable secure boot".

For the end-user, such security mechanisms needs to stay out of their way. Just like firewalls. And that is the current standard. However, firewalls can be tweaked even better, which is not a task the average end-user might care for at all. But the firewall is there with a usually decent protection. Users interested in a higher security level can tweak this to make it harder.

Secure boot is a similar mechanism. Most users shouldn't ever notice it as, as you say, they won't change the OS. But for those who do change the OS; providing mechanisms to have a secure system, even through the boot sequence, is a good idea.

Remember all the fuzz and noise caused when Microsoft enabled the firewall by default in one of the Windows XP service pack? This discussion about secure boot is an iteration of that. But very few hardly complain about that decision nowadays.

But by all means, there are people who disables firewalls, SELinux, authentication mechanisms, etc, etc - and in the future secure boot ... For such users anything which says "increased security" will always be a hassle, no matter what it is, and it will be disabled. That attitude is a failure by default, IMO.

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 18, 2013 19:53 UTC (Mon) by hummassa (guest, #307) [Link] (1 responses)

> True too. But you then ignore that secure boot removes an attack vector.

No, it doesn't, and the proof for that is Apple's products jailbreaks. One of them used a simple crafted PDF that subverted the "secure boot" infrastructure.

> That attack vector has not been used as much as it was during the DOS times,

This has a reason: while it may be practical in an embedded and usually homogeneous environment, in a standard-PC env, the attacker must have code to read every one of the one hundred different filesystems if he wants to compromise the system via boot. IOW, the attacker must be an entire OS.

> where BIOS vendors after a while added features to block writes to the boot sector.

This had not detained nor even slowed down malware at that time (yes, I am that old) and it was considered just a nuisance because it difficulted NECESSARY system updates; you know, to patch vulnerabilities &c... Many, many people turned this off in BIOS. Ah, and once you entered another OS, this was not effective because the other OS bypassed BIOS and talked directly to the hardware. THAT is the reason this is not in effect in today's PCs...

> Secure boot ensures that the core OS loaded is unmodified.

Yes. But from a security standpoint, this would ONLY be a good thing if the core OS loaded was PROVEN secure. If you load a swiss cheese of vulnerabilities, unmodified, this is a BAD thing.

> Which can even be seen as an extension of this old "don't write to boot sector" feature.

Yes. Equally uneffective, equally a nuisance, equally time-consuming for no good reason.

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 18, 2013 20:21 UTC (Mon) by raven667 (subscriber, #5198) [Link]

>> True too. But you then ignore that secure boot removes an attack vector.
>No, it doesn't, and the proof for that is Apple's products jailbreaks. One of them used a simple crafted PDF that subverted the "secure boot" infrastructure.

Are you sure? Are you saying that there were jailbreaks that were permanent and that can't be removed or detected and that persist across reboots and upgrades of the OS? Are you sure it was the boot infrastructure that was being bypassed, rather than the OS kernel?

>> Secure boot ensures that the core OS loaded is unmodified.
>Yes. But from a security standpoint, this would ONLY be a good thing if the core OS loaded was PROVEN secure. If you load a swiss cheese of vulnerabilities, unmodified, this is a BAD thing.

That is an absurd position to take because you and I both know that the OS kernel is not and never will be "proven" secure, also this is not a claim which is being made by secure boot proponents or by the spec so to defend against claims which weren't made is the creation of a straw man on your part.

Secure Boot can only help prevent permanent, undetectable modification of the firmware and stage 1 bootloader by those not authorized by the system owner (such as malware), what the OS kernel and later code does with this known good system state is up to the implementor, usually they are going to want to push the known good state as far as they can (until arbitrary code which can be under the control of an attacker is run and re-compromises the system), by doing their own signature checking and whatnot.

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 19, 2013 11:40 UTC (Tue) by drag (guest, #31333) [Link] (4 responses)

> Secure boot makes essentially no difference to any of this. If you've got a unpatched IE, or an outdated version of Java, or if you double-click everything you get in email, you're precisely as screwed with or without secure boot.

Kernel level root kits are now common place on both Windows and Linux. It's now 'script kiddie' level technology. Anti-virus and rootkit detector software is worthless at detecting these threats and it is a practical impossibility (ie: more work then it's worth) to 'clean' a system that has been taken over by these things.

Signed bootloader and kernels is a step in the right direction.

No point in going backwards when UEFI signing is under your control.

Secure boot

Posted Feb 20, 2013 9:36 UTC (Wed) by man_ls (guest, #15091) [Link] (3 responses)

I don't think that secure boot is a big improvement. For me (I want to run Debian on my machines) it is definitely more trouble than it's worth. Perhaps if you want to run stock Red Hat on stock hardware -- and that is the point: vendor lock-in. So thanks but no thanks.

For the record, cleaning up an 0wned machine can be very instructive. I have had the pleasure of doing it on one client's machine and it was a very interesting experience: from the trojaned SSH to the spam sender to a script that (I suspect) tried to flood the connections of any white hat that tried to recover the machine (e.g. me). And as a bonus, something like 50 GB worth of vuln scan data gathered by the machine in its free time. After a huge upgrade, several scans and some very basic cleanup the problems have not resurfaced. Perhaps the intruders were not very good at their job.

Secure boot

Posted Feb 21, 2013 16:46 UTC (Thu) by drag (guest, #31333) [Link] (2 responses)

There is no way for you to know that you cleaned up that machine properly.

That's the problem.

It's one thing to screw around with a 'owned' machine for your own bemusement, but it's quite another to actually get it to a point were you know it is secure.

With a kernel level root kit you must not trust any user space tools. This means that any sort of checksum utility or package checking feature provided by RPM or apt is completely worthless. Any anti-virus or root kit checker is completely worthless. Any access to any compromised binaries can be intercepted and redirected to their 'proper' versions. Payloads, directories, and volumes that potentially contain many GB of data can be easily hidden completely from the root user.

None of this is 'special' or '7331' features. This is very routine stuff that is common to inject and use in any compromised machine.

For example I help a friend try to clean up a Windows XP machine.

In this particular case I believe it was a web exploit that caused the attacker to get access to the machine. From that point they installed a rootkit that subverted the NT kernel. From what I read it installed a driver into the kernel using APIs provided for the file systems. It created a secret subvolume in the main C drive that allowed them to install and run whatever they wanted.

Exploit leaded to root kit. The rootkit then would download various payloads that would try to do things like send spam or try to gleam bank passwords and such things.

These 'payloads' would be what would be noticed by the user. Their google searches would get all screwed up. Or the anti-virus would notice changes to the system binaries and such things. You'd run the ant-adware or anti-virus utilities that various websites would recommend you to use to remove this or that troublesome software and that would work.. but you'd never hit the rootkit.

Then some days later the rootkit would just download and install some other malware.

So people's machines would seem like they would get compromised over and over again, but it really only needed to happen once.

> Perhaps the intruders were not very good at their job.

Perhaps the intruders didn't give a crap if you detected them or not.

Or perhaps they thought the administrator was incompetent enough enough that they wouldn't notice and that when you did notice they changed their approach to something more secretive.

Really the only appropriate action, unless you are seeking to press charges or something like that, would be to wipe the server and restore it from a known good backup. Anything else is a disservice to yourself or the people you are trying to help. Cleaning up manually may help or may not. It's really impossible to be sure.

Cleaning up a compromise

Posted Feb 21, 2013 17:32 UTC (Thu) by man_ls (guest, #15091) [Link]

You have a point, of course. But it largely depends on the context. An absolute like "there is no way to know you succeeded so better wipe the whole machine" can be true if you are working for the NSA. In this particular case the crackers just wanted to send their bloody spam from the server; they were not interested in anything else. In fact we were getting lots of abuse reports, which stopped after the cleanup. It is possible that the spammers still had another backdoor into the system (besides the compromised SSH binary), but why would they enter the machine and not send any more spam? In this case the proof is in the pudding.

Rootkit detectors are supposed to work well, at least in Linux. It is an arms race between them and rootkit developers, but in this case my money is definitely on the good guys. On Windows it is probably harder to be thorough.

On my personal desktop machine I would be much more paranoid. On this particular web server wiping it out was more trouble than doing a cleanup, and by the way the customer wanted it this way. Perhaps a poor excuse, but good enough for me in this situation. So I am not going to advice anyone else to clean up a compromised machine, just to consider carefully your options.

Secure boot

Posted Feb 22, 2013 13:30 UTC (Fri) by ekj (guest, #1524) [Link]

You can boot to a known-good rescue-system from a usb-stick or cd-rom or whatever, and use the tools there to scan your system.

Ofcourse this is only good if you trust your bios to actually load what you tell it to load, but that's true with secure boot too: if you don't trust your bios to load what you tell it to, then there's little reason to trust the same bios to correctly implement secure boot.