Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code
I stopped working on Ubuntu because decisions were increasingly being made internally rather than anywhere that volunteer contributors could influence them. The "Click here to instantly break your mouse" thing was just the final straw. There's a component to the story that involves beer and a hilarious reply vs. reply all error on an iPhone, but I don't remember it being about anyone siding with Scott - there's a picture somewhere of me deactivating my Ubuntu membership a few minutes after sending https://lists.ubuntu.com/archives/ubuntu-devel/2008-February/025141.html , which hardly gave them time to.
I'm sorry, you're right - I was under the impression that overcommit_memory defaulted to permissive rather than heuristic allocation. However, overcommit_ratio is also ignored by default.
You can malloc() as much as you want until you run out of address space. That's 3GB on 32-bit systems, no matter how much RAM you have. Things will only go wrong if you attempt to use it for anything.
Removing the CMOS battery didn't recover this system, which is pretty much what I'd expect - UEFI variables are typically stored in the same hardware as the firmware itself, and unplugging batteries doesn't kill your firmware.
The system doesn't fail to boot. The system doesn't even complete its power-on self checks. The screen is never turned on. It never responds to keyboard input. It's bricked. This machine's not coming back to life without an SPI programmer.
The kernel can execute ring 0 instructions. Your initrd can't. The difference is that you could construct an appropriately modified hibernation image that booted an arbitrary kernel - or even an entirely separate OS. In that scenario, your kernel is effectively a new bootloader, except unlike the signed bootloaders it'll happily boot an entirely unsigned OS. That's unlikely to end well.
But, conceptually, you're right. Secure Boot doesn't magically make a system secure, but it *is* a vital part of system security - if you can't trust your kernel, any other security you attempt to build is pretty much pointless.
You don't need an exploit or a kernel patch. You just need to replace the firmware's function pointer to GetVariable(), which is a thing you can do because you're running untrusted code in the firmware context. The OS has no way of knowing that you're doing that.
Please describe how Windows can accurately determine whether it was booted in Secure Boot mode or not. For an encore, describe how Trusted Computing can limit the code you can boot. As far as I know, single machine local attestation is an unsolved problem.
How does Windows know whether it was booted in secure mode? It makes the EFI GetVariable() call. Which is a function pointer handed to it by the firmware. Which you can modify if you're running untrusted code. So, no, Windows can't tell.
If you were a serious virus writer you'd already want to use the Microsoft CA to sign your rootkit so you can install it as a signed driver in Windows. Secure Boot moves the vulnerability down the stack, but even now a compromised Microsoft signing key is still massively desirable to virus authors.
Microsoft have told me that they'll revoke certification for any vendor who doesn't provide the appropriate options. If you have examples of machines that have certification and which don't allow any modification of the key database, let me know so we can find out if they were telling the truth.
BIOS boot sector protection has never prevented writes to the MBR unless you're running DOS - any actual OS uses direct hardware access instead of using the BIOS, and so it can't be blocked. It'd be possible for the BIOS to complain that the MBR's been modified, but it has no way of verifying that the partition boot code or the actual bootloader are still secure. Unsurprisingly, malware authors take advantage of this - https://support.kaspersky.com/viruses/solutions?qid=208280748 has a list of modern bootkits.
Slashdot Mirror
Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code
They didn't provide the source code with the router.
There is no requirement to put up a download link, but there is a requirement to provide the source code to any third party that asks for it
I stopped working on Ubuntu because decisions were increasingly being made internally rather than anywhere that volunteer contributors could influence them. The "Click here to instantly break your mouse" thing was just the final straw. There's a component to the story that involves beer and a hilarious reply vs. reply all error on an iPhone, but I don't remember it being about anyone siding with Scott - there's a picture somewhere of me deactivating my Ubuntu membership a few minutes after sending https://lists.ubuntu.com/archives/ubuntu-devel/2008-February/025141.html , which hardly gave them time to.
Wubi doesn't support UEFI. Once it does, it can use the same signed bootloader that Ubuntu currently uses.
I'm sorry, you're right - I was under the impression that overcommit_memory defaulted to permissive rather than heuristic allocation. However, overcommit_ratio is also ignored by default.
"Setup mode" is part of the UEFI specification. You can add any keys you want to while you're in it.
You can malloc() as much as you want until you run out of address space. That's 3GB on 32-bit systems, no matter how much RAM you have. Things will only go wrong if you attempt to use it for anything.
Removing the CMOS battery didn't recover this system, which is pretty much what I'd expect - UEFI variables are typically stored in the same hardware as the firmware itself, and unplugging batteries doesn't kill your firmware.
The system doesn't fail to boot. The system doesn't even complete its power-on self checks. The screen is never turned on. It never responds to keyboard input. It's bricked. This machine's not coming back to life without an SPI programmer.
Unfortunately not in this case.
30-day hassle-free return policy.
Yes, but Windows requires signed drivers.
Disabling secure boot means you can easily lie to the OS about whether or not secure boot is enabled.
If it were an anti-piracy measure then there wouldn't be a requirement for you to be able to disable it.
The kernel can execute ring 0 instructions. Your initrd can't. The difference is that you could construct an appropriately modified hibernation image that booted an arbitrary kernel - or even an entirely separate OS. In that scenario, your kernel is effectively a new bootloader, except unlike the signed bootloaders it'll happily boot an entirely unsigned OS. That's unlikely to end well.
But, conceptually, you're right. Secure Boot doesn't magically make a system secure, but it *is* a vital part of system security - if you can't trust your kernel, any other security you attempt to build is pretty much pointless.
You don't need an exploit or a kernel patch. You just need to replace the firmware's function pointer to GetVariable(), which is a thing you can do because you're running untrusted code in the firmware context. The OS has no way of knowing that you're doing that.
"The GetVariable() call returns a decryption key that the hardware calculated"
No it doesn't. It returns a 1 if the firmware claims to have booted securely, and a 0 if not. You're thinking of Measured Boot, not Secure Boot.
Please describe how Windows can accurately determine whether it was booted in Secure Boot mode or not. For an encore, describe how Trusted Computing can limit the code you can boot. As far as I know, single machine local attestation is an unsolved problem.
How does Windows know whether it was booted in secure mode? It makes the EFI GetVariable() call. Which is a function pointer handed to it by the firmware. Which you can modify if you're running untrusted code. So, no, Windows can't tell.
If you were a serious virus writer you'd already want to use the Microsoft CA to sign your rootkit so you can install it as a signed driver in Windows. Secure Boot moves the vulnerability down the stack, but even now a compromised Microsoft signing key is still massively desirable to virus authors.
Microsoft have told me that they'll revoke certification for any vendor who doesn't provide the appropriate options. If you have examples of machines that have certification and which don't allow any modification of the key database, let me know so we can find out if they were telling the truth.
You've linked to a story about a traditional MBR bootkit that doesn't even run under UEFI. Secure Boot is, as far as anyone knows, not yet cracked.
It's not DRM. You can turn it off in the firmware and there's no way for the OS to know that you did.
BIOS boot sector protection has never prevented writes to the MBR unless you're running DOS - any actual OS uses direct hardware access instead of using the BIOS, and so it can't be blocked. It'd be possible for the BIOS to complain that the MBR's been modified, but it has no way of verifying that the partition boot code or the actual bootloader are still secure. Unsurprisingly, malware authors take advantage of this - https://support.kaspersky.com/viruses/solutions?qid=208280748 has a list of modern bootkits.
Sure. The user shouldn't enrol keys unless they trust whoever provided it and the chain of trust that they assert exists.