Linux Foundation Secure Boot System Released | Hacker News Reader

Linux Foundation Secure Boot System Released

blog.hansenpartnership.com

125 pointsonosendai31 comments

Doesn't matter if it's signed code. I still turned off Secure Boot on my T430. It is rare that I have ever gotten malware, much less any that execute code at boot. Boot-sector virii died off in the late 90s.

Make no doubt about it; this is just another monopolistic implementation of restrictive technology by Microsoft.

> any that execute code at boot. Boot-sector virii died off in the late 90

Are you sure? It looked like rootkits/bootkits are still pretty rampant?

The security world is as driven by fashion and old-concepts-with-new-names as the rest of the software industry. The general treadmill is basically

1. Look at this bug! lolz,pwnd

2. Script kiddie tools made around it and lots of variants are popular

3. Security improves as prevention tools get better

4. 0day experts look in other systems. (aka goto 1 with a different subsystem argument).

5. Eventually, as techniques in all subsystems improve, the original area of exploration is again the lowest hanging fruit, with a slightly different guise.

For example - SQL injection is just a variant of the old pipe injection attack (also, pipe injection is coming back a bit, because newer programmers haven't seen it, and older programmers have forgotten about it).

Another example you're starting to see more of again: IP stack attacks - as ip is being offloaded into the NIC you're starting to see a revival of "lets see what we can do to the ip stack" but this time it's in the card itself. (Actually there is some really cool stuff going on here...)

So yeah, boot time attacks are pretty common and in these days, but not necessarily in the main boot path, but in cards with firmware, especially those that have DMA.

Additionally with tools like metasploit, you can keep around a huge toolkit of root-kits and so on, so if a system is vulnerable to known boot-time exploits, you can use them even if you'd forgotten them.

Can you elaborate on "pipe injection"? I can't find references to the term after brief searching, and I'm curious.

Sure, you know how SQL injection is just adding extra SQL statements to user input, and taking advantage of improper escaping to get the database to do your bidding? Pipe injection is the same thing but in cases where shell commands are called with arguments taken from user input. It was very common in older Unix systems to have various bits of a complicated system actually just be the result of another standard command with proper args/input. So you find a place where something like system is used, or there is a call to sh -c , or so on, and if the input is improperly escaped, add:

    |adduser ...

or change the password, or so on to get a root shell or account.

This has actually come back into style in certain places again, because so many devices are just linux boxes with busybox utils on constrained systems (think home routers for example a lot of those just display the output from various linux commands in their firewall stuff). But programmers don't always think about "what if someone is going to try and do pipe on this..." and you end up with a pipe injection.

It also can be used for privilege escalation if you have a lot of custom setuid stuff available for your sysadmins and someone manages to get a local account. (unfortunately more common than one would hope).

Ah, I see. Thanks for the explanation.

You'll find it under the slightly more general 'command injection'[1] which includes the use of other shell operators as well

[1] https://www.owasp.org/index.php/Command_Injection

Not on Linux. And in my 10+ years of Windows computing, I have never once gotten a bootkit. It's simple: install a myriad of security applications, and don't visit any suspicious websites.

It's common sense, really.

How do you know if you have a bootkit? I could have one running on my system right now syphoning off data, I probably don't but I can't think of any way that I could prove that I didn't even if I ran every anti-malware program in the world.

Not proof, I guess, but possible countermeasures:

* run the OS from (known good) media mounted read-only (in the olden days, some websites ran off Knoppix CD's and rebooted often :)

* (Red Hat): rpm -Va to verify the package database, binaries, config files etc. (after verifying the original package database hasn't changed, by checksumming / diffing with an offline copy)

* iptables rules which drop (and log) all traffic on all interfaces (then selectively add minimalist rules)

> in the olden days, some websites ran off Knoppix CD's and rebooted often

That sounds horrific for performance.

Not at all. Once the OS and webserver (and whatever apps you need) are in memory, it's just as fast as a hard-drive.

Non executable data (the majority of data served by webservers) can still reside on magnetic media or on a NAS.

Did you hear about TDL/TDSS bootkit? http://www.nobunkum.ru/analytics/en-tdss-botnet 16 millions were infected. Distributed via partner programs with download sites, including bundling with installers Oracle-way. Do you think that because you were not affected such cases must not be prevented?

Ignoring your vibe for conspiracy theory, I was personally looking forward to a solution like secure boot.

Imagine securing your entire system with something like Truecrypt, using multiple layers of encryption, only to be defeated by a 1KB bootloader that performs Man in the Middle attack.

the idea of a verfied boot does not imply "UEFI secure boot" where microsoft holds the keys to access your hardware.

Yes it does to a good extend. Under your analogy, the key to internet would be held by VeriSign, since all SSL signing must chain back to their signature.

The key better be held by a company that I can hold responsible for in court if something were to goes wrong, than some random layman.

I'm not 100% sure what this means. I remember hearing a lot of rabble rabble a few months back about Microsoft placing some roadblocks on hardware that would make it more difficult to install Linux on machines.

Does this mean this is now a non-issue?

Thanks in advance.

It's been a non-issue for a couple of months - the Linux Foundation implementation is an alternative approach, but there's already a freely-available signed bootloader that distributions can use.

I disagree that's a non-issue. Recently a relative's 10+ year old computer broke down. After buying a new one, until I was able to boot from an external linux usb/CD disk and be able to boot linux from the hard disk after installation, took several trips to the BIOS to change a myriad of UEFI settings, which is completely non-trivial to someone that just wants to try a live CD.

With secureboot enabled (the default on windows 8 certified hardware, or pretty much all x86 consumer platforms), you can't simply insert a linux installer or livedisk. You have to either play around with keys, or disable secureboot in the UEFI configuration.

If your OS doesn't allow arbitrary code to be run on the raw machine (so a chain of trust on executables), microsoft provides a signing service. This is a problem for linux, due to the way it allows any code to run privileged. This is a problem because if a generic linux kernel was signed, it could be used to bypass secureboot (since it allows you to run any code, and it would be trusted).

Some distros are looking at disabling all these features, so that their distro image can be signed. This would disable all third-party modules, and disallow other features (that most people probably don't use anyway).

This specific post is about an a key management program, that allows a user to install their own keys, so they can sign their own linux image. A simpler option allows you to put your machine in another mode that disables secureboot. Like the UEFI configuration option, this is a roadblock to new users, who want something to "just work". So unfortunately yes, it's still an issue.

Meanwhile Ubuntu's Wubi-based installer is rendered useless since the Windows 8 bootloader won't load it (nor will it load anything except Windows apparently if SecureBoot is enabled).

I don't think Wubi's ever worked with UEFI systems.

Great news but this entire situation is still a cluster-fuck.

Yep ... and I feel like we are feeding the trolls.

I don't feel safe at all. The same way goverments could ask Microsoft to have a builtin backdoor for Windows, they could ask for a signed rootkit.

Microsoft is actually in quite an interesting situation here. Although they have a lot of power in deciding what they sign, they also have a large obligation due to their now monopoly position. It's these situations that antitrust laws can start applying, but Microsoft would have to abuse their position for that to happen.

They probably don't even have to ask. They could A) steal MS's signing key. B) Find a security flaw in an already signed bootloader. C) Ask MS to sign a non-rootkit bootloader with a subtle security flaw.

cache: http://webcache.googleusercontent.com/search?q=cache:http://...

Amazing. An article about "Secure Boot" and they transmit...

A MD5 of the file.

The nineties called, they want their MD5 back.

Yep. They should have instead published SHA2/SHA3 hashes.

I'm pretty sure the md5 hash is just to test the integrity, to make sure it isn't corrupt. Due to all the other trust issues (no HTTPS), the insecure aspects of md5 don't really matter.

Reply on news.ycombinator.com