Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I honestly don't understand how this can be legal. There's precedent, at least in the US. The Bell system was forced to allow non-AT&T hardware on their network. Automobile manufacturers were required to allow third parties to service vehicles.

Also, I don't understand the need. I've heard the excuses about malware, but is that even a significant problem? I know I've never booted up a machine and said to myself, "You know what I need? An upgrade to my BIOS."

I mean, it is purely and transparently anti-competitive. But why now? This is something the 90s, we're-deathly-afraid-of-linux Microsoft would do. So why now and not then?




> I honestly don't understand how this can be legal.

Are you serious? It's mandatorily configurable. Are you suggesting that Secure Boot just not be implemented by motherboard manufacturers? Or rather that Microsoft should just pretend it doesn't exist?

Secure Boot is quite a useful part of the UEFI specification, albeit maybe not in the average case. I should hope it doesn't get ignored just to satisfy conspiracy theorists.


Secure Boot might be a useful part, if everybody could add his own keys to his own board, and delete existing keys for Microsoft and others. But one has to pay to get his key signed by Microsoft. This is comparable to install own software on an iPhone, where one has to pay Apple to unlock a devices.

The most dangerous malware is now produced by states.

If RedHat and Ubuntu can pay their us$99, I guess NSA, BND, CIA, Mossad and others can also. So secure boot is not adding any security, imho. There was already the case that Microsoft implemented a backdoor in NT export versions for NSA 13 years ago.


> There was already the case that Microsoft implemented a backdoor in NT export versions for NSA 13 years ago

There was conspiracy theory speculation that they did so, if it is _NSAKEY that you are thinking about, but few competent cryptographers or security researches took that seriously. Typical responses were like this: http://www.schneier.com/crypto-gram-9909.html#NSAKeyinMicros...


Actually, the Logo requirements specify that you must be able to add your own keys:

> It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK.


You can not change the boot loader on ARM for Windows 8. And you likely can not change it for Intel for next Windows version.


The former claim is absolutely true, and I'm not happy about it. But that is surely the standard for all ARM devices out today, is it not? Locked bootloaders?

Anyway, the latter claim is purely conjecture. Why would they change convention once everyone has already implemented all this standard/custom mode stuff that they require for 8?


Apple and Android devices are all closed so that excuses Microsoft from doing the same? Guess again; they are all wrong.


>Secure Boot might be a useful part, if everybody could add his own keys to his own board, and delete existing keys for Microsoft and others. But one has to pay to get his key signed by Microsoft.

That is exactly what Microsoft mandates for secure boot for Windows 8 certification. Please stop spreading misinformation.


I thought that only applied to x86 processors, not ARM?


The problem is not rootkit embedded in the BIOS, the problem is rootkits embedded in the boot sector.


Actually, I suspect that the problem isn't rootkits, it's Windows 7 Loader, the one way to pirate windows they haven't been able to squash since it runs from the boot sector.


On the other hand, the TDSS rootkit modifies the boot sector to hook the loader to allow the rootkit which is an unsigned driver) to load.


I guess, because Microsoft now realized that they lost the age of internet, they lost the browser war, the search engine war, and the mobile phone war. They know that Windows 8 sucks that much, that people want to install Windows 7 or Linux, and they need to prevent us doing this.

Its similar like a dictator shooting at civilians at the moment he realized that he lost the love of his people.


> I guess, because Microsoft now realized that they lost the age of internet, they lost the browser war, the search engine war, and the mobile phone war. They know that Windows 8 sucks that much, that people want to install Windows 7 or Linux, and they need to prevent us doing this

Then why did they make it so that to get your x86 hardware certified and allowed to use the Windows 8 logo, you are REQUIRED to provide a UEFI setting to turn off secure boot and to allow the user to remove and add keys?

If they are trying to prevent people from running Linux or Windows 7, you'd expect them to leave it up to the OEM whether or not secure boot can be disabled or the keys can be modified--knowing that many OEMs would not bother, rather than explicitly requiring the OEMs to allow that.


> If they are trying to prevent people from running Linux or Windows 7 [...]

If they were trying to do this, all they'd have to do is tell OEMs to only allow the system to boot with Windows bootmgr. No fancy signature checking required! And they could have done it at any point in the past, even with BIOS.


> I've heard the excuses about malware, but is that even a significant problem?

Pasted from one of my earlier comments:

Here are some references about boot malware which UEFI secure boot can prevent.

http://www.chmag.in/article/sep2011/rootkits-are-back-boot-i....

http://www.theregister.co.uk/2010/11/16/tdl_rootkit_does_64_....

http://www.computerworld.com/s/article/9217953/Rootkit_infec....

I recommend reading atleast the first link.

Here's one juicy bit:

TDL4 is the most recent high tech and widely spread member of the TDSS family rootkit, targeting x64 operating systems too such as Windows Vista and Windows 7. One of the most striking features of TDL4 is that it is able to load its kernel-mode driver on systems with an enforced kernel-mode code signing policy (64-bit versions of Microsoft Windows Vista and 7) and perform kernel-mode hooks with kernel-mode patch protection policy enabled.

When the driver is loaded into kernel-mode address space it overwrites the MBR (Master Boot Record) of the disk by sending SRB (SCSI Request Block) packets directly to the miniport device object, then it initializes its hidden file system. The bootkit’s modules are written into the hidden file system from the dropper.

The TDL4 bootkit controls two areas of the hard drive one is the MBR and other is the hidden file system created at the time of malware deployment. When any application reads the MBR, the bootkit changes data and returns the contents of the clean MBR i.e. prior to the infection, and also it takes care of Infected MBR by protecting it from overwriting.

The hidden file system with the malicious components also gets protected by the bootkit. So if any application is making an attempt to read sectors of the hard disk where the hidden file system is stored, It will return zeroed buffer instead of the original data.

The bootkit contains code that performs additional checks to prevent the malware from the cleanup. At every start of the system TDL4 bootkit driver gets loaded and initialized properly by performing tasks as follows: Reads the contents of the boot sector, compares it with the infected image stored in hidden file system, if it finds any difference between these two images it rewrites the infected image to the boot sector. Sets the DriverObject field of the miniport device object to point to the bootkit’s driver object and also hooks the DriverStartIo field of the miniport’s driver object. If kernel debugging is enabled then this TDL4 does not install any of it’s components.

TDL4 Rootkit hooks the ATAPI driver i.e. standard windows miniport drivers like atapi.sys. It keeps Device Object at lowest in the device stack, which makes a lot harder to dump TDL4 files.

All these striking features have made TDL4 most notorious Windows rootkit and it is also very important to mention that the key to its success is the boot sector infection.

Another bit:

The original MBR and driver component are stored in encrypted form using the same encryption. Driver component hooks ATAPI's DriverStartIo routine where it monitors for write operations. In case of write operation targeted at the MBR sector, it is changed to read operation. This way it is trying to bypass repair operation by Security Products.


It is exactly like stealth viruses in DOS, 20 years ago.

The problem is not overwriting MBR; the problem is privilege escalation (in this case, ability to install it's own driver without user's knowledge). The operating system has means to make all processes behave. So now Microsoft throws up hands and says, that they cannot make Windows secure?




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: