Shuttleworth: Why Windows 8 made us ditch GPL Linux loader | Hacker News Reader

Shuttleworth: Why Windows 8 made us ditch GPL Linux loader

theregister.co.uk

29 pointscooldeal41 comments

"The idea is to block viruses from tampering with the boot process and injecting themselves into a system before they can be detected."

Does anybody serious believe that UEFI will "block viruses" from meddling with any boot process? Are boot-sector viruses even a problem any more, because it was pretty obvious that boot-time viruses (like "Brain") were only widely spread by MS-DOS and early Windows, that required a lot of boots. Boot-time viruses never made inroads in other populations of computers, just like Macro viruses never made inroads except in "Word" dominated environments.

UEFI is a power play, pure and simple, just like Digital Rights Management (a.k.a. "copy protection").

Even worse, it opens up a whole new attack vector:

"UEFI reimplements a full networking stack, unlike many BIOSes, and therefore is a target for remote security exploits" [http://catless.ncl.ac.uk/Risks/26.18.html#subj13]

SO as soon as someone cracks/leaks the Microsoft key, they can compromise all the Arm tablets?

Disclaimer: Not a programmer and not into details of hardware, just interested

Yes, they would have the ability to compromise all PCs (ARM, x86).

Notes, though:

* All BIOS-based PCs and many ARM-based PCs (as well as other CPU-based units) are currently vulnerable. As others have noted, this is not a very active threat vector compared to, say, Flash bugs and infected software ("...to view this p0rn, you have to install this codec" - bam! you are pwned).

* Ability to bypass the key signing via a stolen key is necessary but not sufficient for an attack. You also have to get (trick) the user into installed infected boot-type code. The advantage is that you can then install rootkit-class software, which is very very hard to detect and eradicate.

* People with "powerful" keys take extensive measures to protect them. Having said that, people with "powerful" keys have slipped up, which causes a lot of problems. Examples: Microsoft's key (an old one) was hacked and used to sign the "Flame" virus, Mozilla's private key revealed, the RSA key token hack.

References:

http://news.cnet.com/8301-10805_3-57446466-75/flame-virus-sp...

http://www.itnews.com.au/News/252766,comodo-hacker-reveals-m...

http://blogs.computerworld.com/17995/rsa_securid_hacked_2fa_...

Boot-sector or similar viruses are absolutely a problem, thanks to the prevalence of spyware. Just ask anyone who routinely deals with end-user desktop maintenance. You generally have to alter your cleaning techniques every few weeks to deal with the latest and greatest.

At my workplace, I get alerts whenever our security event monitor notices a pattern consistent with malware. We've had ~10 boot sector malware infections since May, most of them being ZeroAccess. Our policy is to reimage the computer rather than try to remove it, in order to keep maintenance times low.

As you mentioned, ZeroAccess is spyware that installs itself to the master boot record to avoid detection or removal. Boot sector viruses are indeed still an unfortunately common issue.

Power play for what? Boot time root kits are a serious problem for Linux, OSX and Windows. http://www.stoned-vienna.com/ IOS already signs their UEFI and blocks Linux from installing so it looks bad when Apple is not even mentioned in any UEFI discussions. The Ipad is the most used ARM tablet and any competitors need to at least do what Apple does if they want to compete. If Apple did not lock the boot-loader it would then be susceptible to known root-kits that are incredibly hard to detect once loaded. Linux and Android are also vulnerable to this attack.

Yes they are reappearing. Look up "bootkits".

Excellent! How do they spread? People no longer leave MS-DOS or Windows 1.0 "boot floppies" in A: to get infected on the next reboot.

The implementation of UEFI needs to be flawless for the keys and the signing to make any difference, leaked or not, except for control of the consumer marketplace. Look at "rooting" Android smartphones, or putting alternate OSes on the Wii. Imperfect implementations spoil the security.

Even if "bootkits" are making a boot sector virus comeback, UEFI will not make much more than a temporary difference.

They don't spread by themselves, they are installed by rootkits to help hide them. I recently had to clean up such a rootkit.

>Does anybody serious believe that UEFI will "block viruses" from meddling with any boot process? Are boot-sector viruses even a problem any more, because it was pretty obvious that boot-time viruses (like "Brain") were only widely spread by MS-DOS and early Windows, that required a lot of boots. Boot-time viruses never made inroads in other populations of computers, just like Macro viruses never made inroads except in "Word" dominated environments.

I have addressed this in a previous comment here. http://news.ycombinator.com/item?id=4190483

All this only serve to make ms strong again on consumer market. It's the good old bait and switch. And Ubuntu suckers are going right into

"ohh i have money. I can buy into the game and finally have more installs than Debian"

Let's see how that plays out later, since we all know this boot shenanigans do nothing it advertised (virus, security) and only serve to harden the installation of non windows os

If by "money" you mean $99 to buy a certificate from Verisign. Debian also has $99 to throw at Verisign, it's just making up its mind as to whether it wants to.

I'm not saying I'm happy about any of this, but complaining about the money makes you sound exactly as credible as someone calling Ubuntu suckers because they pay for SSL certificates. (Especially because SSL has all the same issues of root keys owned by rapacious trusted third parties, and a security benefit that isn't obviously that big, these days...)

the sucker part is about the big picture. SSL for all it's problems still is the closest to provide http securely. This safeboot thing helps with nothing. at all.

now back to the sucker part. thanks to ubuntu, everyone now instead of complaining or not buying hardware because free drivers aren't provided, will just and gladly use binary ones. and then complain that linux is unstable. i know it's a fine line to walk since otherwise they will just complain linux is not compatible with anything... but i think the later is fixable.

It is ridiculous that a linux company can so misunderstand copyright. GPL cannot compel you to open source your code or to give out security keys. They can seek damages against you if you violate the license.

As a more extreme example, lets say I have software with a license that requires you to punch yourself in the face in order to use it. If I find you've used it without punching yourself in the face; I can't compel you to punch yourself in the face, I can only collect monetary damages and get a court to forbid you from using my software anymore.

When you've tightly tied yourself to a single GPL product, it may be easier to just comply with the GPL than to switch to using non-GPL software, but a bootloader is hardly a tightly integrated part of an OS; they could release with grub 2 and switch to elflinux if it is determined that they were violating the GPL3 by not divulging their keys.

Under common law, damages were all you could seek for violation of a contract[1], but under equity a court can order that the contract terms be honored. That's called "specific performance".

There are certain conditions under which specific performance is not an option. One of those is if it would cause undo hardship on the defendant. That would be sufficient to rule out a court ordering you to punch yourself in the face.

Offhand, I can't think of any of these conditions that would apply in the case of the GPLv3 requirement to disclose signing keys, and so don't see why specific performance would not be a possible outcome there.

[1] There is some question as to whether or not free and open source licenses should be treated as contracts in litigation, or if such cases should be treated as copyright infringement cases with the license only coming up as a possible defense.

In other words, just violate the license until you get caught? I don't understand what you are saying here.

If you violate the GPL license on code you are distributing, you can be legally compelled to stop distributing the code and pay damages to aggrieved parties. You cannot be compelled to fulfill arbitrary requirements of the license, like sharing private information, your own source code, punch yourself in the face, fly to the moon, or give up custody of your first-born child.

If you successfully argue that the GPL forms a contract (and I'm not sure if it does or not), you can argue for specific performance instead of damages.

There is one hook in the GPL that makes this a very dangerous game: if you are found to be in violation, you lose your rights given by the license until they are explicitly reinstated by the copyright holder. Just starting to comply with it is not enough. Depending on how the GRUB team wants to play this, this could get messy. Canonical loosing all rights to GRUB would be a fun case, especially when it comes to all the releases that still use GRUB.

See: http://www.softwarefreedom.org/resources/2008/compliance-gui... (5.2, Termination)

Also, as a Linux vendor, you really don't want to get caught violating the GPL voluntarily.

I have to question if any high profile development team has the balls to actually prevent Ubuntu from using their software. Ubuntu dropping your packages from a default install would have enough of an impact, but having them removed from the repos as well seems catastrophic.

Canonical is not really a small-time player in the Linux world.

Yes, but Canonical advocating GPL breaches and strong-arming a high-profile team into a standoff? Would any of the sides want the fallout of that?

My point was that it is not true that you can just pay up when convicted and continue as before if you are found to be in violation of the GPL.

That's true in all these discussions. You always have the option to simply stop selling your product, however for most companies that's probably a worse option than giving away the source code. I think that's why it's usually left out of the discussion.

It's like saying Americans will be forced to buy health insurance soon. They don't have to if they quit their job and keep their income below the poverty level, but that's not really a viable alternative for most, so "forced to buy health insurance" remains an accurate summary.

Even so, I doubt they want to pay damages either.

Yes, but then don't go on the record saying that if you shipped with grub 2 you could be compelled to divulge your keys, that's either a lie, or a misunderstanding of how copyright works.

I don't think it's a lie or a misunderstanding, but a reasonable summary of the situation. They shouldn't have to mention the "pay damages and stop shipping the software" alternative, since that is always an implicit possibility.

> GPL cannot compel you to open source your code or to give out security keys. They can seek damages against you if you violate the license.

FSF's stance on this seems to be different from yours.

Quoting from the blog post[1]:

>This fear is unfounded and based on a misunderstanding of GPLv3. We have not been able to come up with any scenario where Ubuntu would be forced to divulge a private signing key because a third-party computer manufacturer or distributor shipped Ubuntu on a Restricted Boot machine. In such situations, the computer distributor -- not Canonical or Ubuntu -- would be the one responsible for providing the information necessary for users to run modified versions of the software.

See the last line? So basically FSF is claiming that the private key must be divulged, just not by Ubuntu, but the OEM. What if the OEM is a Ubuntu partner? They would be in a bind, having to chose between divulging the key(and probably having it revoked when a rootkit starts using it) and throwing their OEM partner under the bus.

As you said, if the bootloader is easily replaceable with something with a more open license, why subject yourself to this possible headache?

[1] https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot...

They didn't even contact the FSF to discuss the matter. FSF wrote a white paper about this and stated that the GPL would not force them to release the public key. Also, does anyone really believe UEFI is not going to be compromised ? The entire thing ridiculous. It's a power grab, and a lot of leaders in the open sourced movement are going to come out of this looking like a pack of fools.

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

The FSF whitepaper is still a bit ambiguous -- it says that they can't come up with a scenario in which they'd require Canonical to disclose the private key. It's not as strong as saying the GPLv3 text definitely does not require it, or, better yet, that they definitely will not require it, as copyright holders to GRUB.

Now because FSF is also the copyright holder of GRUB, their interpretation of the GPLv3 is trustworthy in this context, but in other contexts, the FSF doesn't get to issue retroactive interpretations about the text of the GPLv3. So seeking the advice of actual lawyers about what the actual text means is entirely reasonable.

I would speculate the SFLC said the FSF would try and sue to get the keys in a "civil-war", not that the GPL mandates Canonical giving out the keys.

I have been trying to find the answer to this, is there a requirement to store the custom keys installed on a SafeBoot UEFI system in flash or otherwise in hardware? Are they stored in EBDA or on a disk partition? I can't see how the standard prevents infection by writing a valid bootsector key to the disk otherwise.

Shuttleworth: The SFLC advice to us was that the FSF could require key disclosure if some OEM screwed up.

Does anyone know what he's talking about here?

The GPL3 sees the signing keys are part of the source code, so they have to be provided along with the binaries. The relevant part of the license is in section 6, third paragraph from the bottom. If an OEM ships a signed copy of Grub 2, the license states that they need to provide the keys as well. The fact that the keys come from a third party (Canonical) makes no difference here. The keys still need to be provided.

I don't think the license says the keys are part of the source code. It says they have to provide information on how to run your own modified version of the software.

In this case it would be as simple as allowing the user to install their own key or disable secure boot. If an OEM didn't do that and pre-installed Ubuntu on the machine there is no way that Ubuntu would be required to reveal their private key, they did nothing wrong, the OEM is the one who violated the license and they are on the hook for damages.

TLDR: Canonical asked some copyright attorneys who specialize in software licensing rights if the GPL would create issues. They said it could, and that Canonical could but probably would not be liable if such issues arose. Canonical decided that the easiest, most pragmatic thing to do was to switch bootloaders and not have to deal with this issue at all.

GRUB is a decent bootloader, but it's not sufficiently better than the alternatives to justify the additional costs keeping it would have imposed. (These additional costs would likely not be actual expenditures, but reserves booked pursuant to accounting standards).

I used Ubuntu and promoted it like crazy. Until i realized it's pernicious to open software. Too many compromises. binary drivers everywhere. Now this. The Ubuntu moved gnome3 crap that led to the least community driven direction a project ever took.

Heck and i always seen gpl extremists as crazy and release all my code under mit... And even so i refuse to use Ubuntu anymore.

Sounds like you're a Debian sort of guy, then. That's fine- but, understand that the reason Ubuntu is at the forefront of "Linux on the desktop" is because of its willingness to compromise.

You can never have everything; Ubuntu cares more about things that lead to adoption (i.e. usability), Debian cares more about purity.

I doubt that Ubuntu is "the forefront of 'Linux on the Desktop'" because it is willing to compromise and use binary blobs and the like.

The reason is that there is a proper organization that people trust and understand behind it (Canonical). People with incentives, money and ads.

Idealism has little to do with it. Granted, Ubuntu would be a bit less popular if they were as pure, but I don't think it makes much of a difference in the end.

Really? I have plenty of hardware that simply will not work at all without the binary blobs -- no graphics, no network connection, etc. I've tried installing Debian on some of my machines, only to find that it doesn't boot and I need to install Ubuntu instead.

Ubuntu wouldn't lose on mere "popularity" by being less pragmatic, they'd lose on hardware compatibility. It's pretty easy for a technical user who knows they want Linux to find hardware well-supported on Linux before they buy it, but the average user will come with a computer already purchased, and ask if Ubuntu works on their computer.

I beg to differ. It's surely not the only reason, but I remember back around 5.10, there were a lot of people observing how much they liked things like the easy install of binary graphics or WiFi drivers, for example.

uh... everything* that ever shows up at ubuntu passed by my machine running debian sid. how is that leading adoption?

* excluding unity

Reply on news.ycombinator.com