Leaked stolen Nvidia cert can sign Windows malware(theregister.com)
theregister.com
Leaked stolen Nvidia cert can sign Windows malware
https://www.theregister.com/2022/03/05/nvidia_stolen_certificate/
74 comments
If a corp like Nvidia cannot manage to store Code signing certs on hardware only, the whole process is broken beyond repair. What’s the value of signed code going forward?
The benefit of signed code is it grants hardware vendors a perpetual control, gatekeeping, and rent seeking role. It was never your hardware.
The cover story was security, which might be mathematically correct but in practice has been shown false in every way. Look how much malware gets signed and shipped on devices and sold on app stores: the vendor gets their cut, /shrug. Look how many devices have been intentionally bricked to force new sales - yay them again. And then there's the certificate management illusion.
The cover story was security, which might be mathematically correct but in practice has been shown false in every way. Look how much malware gets signed and shipped on devices and sold on app stores: the vendor gets their cut, /shrug. Look how many devices have been intentionally bricked to force new sales - yay them again. And then there's the certificate management illusion.
> The benefit of signed code is it grants hardware vendors a perpetual control, gatekeeping, and rent seeking role. It was never your hardware.
but in this case it's literally not caused by hardware vendors ? They're not even a party to this arrangement. The requirement is being enforced by windows, and the certificates are issued by various CAs. If you don't want that just use linux or something, or disable signature enforcement within windows.
but in this case it's literally not caused by hardware vendors ? They're not even a party to this arrangement. The requirement is being enforced by windows, and the certificates are issued by various CAs. If you don't want that just use linux or something, or disable signature enforcement within windows.
Most linux distros have used signed repository packages since forever, right? Not really challenging what you are saying, rather asking whether this is not already a very similar setup. I guess it is a social web of trust among package maintainers as opposed to the certificate authority root of trust in Windows. Or am I making a flawed comparison?
Linux lets you ignore signatures if you prefer. There are plenty of devices that don't.
You cant disable signature enforcement on Windows. You can test sign and only if you disable secure boot and enjoy desktop watermarks.
^ Not enough people are angry about this! I have a permanent watermark on my desktop because I use an edid override for my projector and hobbyist drivers for niche video game controllers. It sucks.
the reason is vendors. in the XP era, OEMs would write crappy drivers, which made Windows unstable or erratic. WHQL was established to ensure quality control, but vendors could simply disable signing if they couldn't be bothered to make their drivers up to code. the watermark was added to prevent such unscrupulous behavior.
Stop using windows. Stop accepting microsoft software at work.
I don't use Windows myself, but I have to develop for it, and hit this problems even when everything I develop is open source.
> Stop using windows. Stop accepting microsoft software at work.
Some people need money to sustain their families. As a prostitute you can choose your clients but this might lead to lower income. ( yes, i do think that me, having to use Microsoft software is prostitution, but i didn't had any employer which gave me a chance to install linux).
Some people need money to sustain their families. As a prostitute you can choose your clients but this might lead to lower income. ( yes, i do think that me, having to use Microsoft software is prostitution, but i didn't had any employer which gave me a chance to install linux).
The /shrug continues until everyone here stops buying Lenovo hardware after they shipped a rootkit, etc
Listen, I really like their Legion series
If people have got recommendations I am all ears
If people have got recommendations I am all ears
> What’s the value of signed code
A part of the roadmap to only allowing average users to execute native programs their overlords approve of. We're already sadly most of the way there with the scary dialogs and dark patterns anyone has to navigate to run anything unapproved.
A part of the roadmap to only allowing average users to execute native programs their overlords approve of. We're already sadly most of the way there with the scary dialogs and dark patterns anyone has to navigate to run anything unapproved.
“If it can’t be 100% perfect then what’s the point” is one of my least favorite arguments.
A single or even multiple breaches doesn’t suddenly remove all value from all other code signing models.
A single or even multiple breaches doesn’t suddenly remove all value from all other code signing models.
There is a hint of frequency illusion here. Millions of code signing certificates are stored securely on hardware devices or by other means. A leak of a private key every now and then does not negate the security of the entire ecosystem.
Is there any proof that most others store their certificates on hardware?
What gruez said is correct. Hardware token have been mandated for EV certificates for a long time by providers to prevent leaks.
I'll also add that Amazon Key Management Service, Azure Key Vault, and Google Key Management Service store several hundred million private keys combined with no leaks so far (they are non-exportable and access is audited)
It is very rare that we see malware signed by a publisher's certificate, which is why it is in the news every time it happens.
I'll also add that Amazon Key Management Service, Azure Key Vault, and Google Key Management Service store several hundred million private keys combined with no leaks so far (they are non-exportable and access is audited)
It is very rare that we see malware signed by a publisher's certificate, which is why it is in the news every time it happens.
No leaks does not imply security.
Hardware tokens are mandated for EV code signing certificates[1], but not for regular certificates. However, the certificate was from a while ago so that requirement probably wasn't a thing back then.
[1] https://www.digicert.com/signing/code-signing-certificates "REQUIRES TWO-FACTOR AUTHENTICATION USING HARDWARE TOKEN"
[1] https://www.digicert.com/signing/code-signing-certificates "REQUIRES TWO-FACTOR AUTHENTICATION USING HARDWARE TOKEN"
I bought a Windows EV code signing cert just months ago. It comes in the form of a password protected USB token.
Signed binaries use will come into being with trusted computing, they are embedding Denuvo in the operating system, aka future compilers will allow game companies and companies like autodesk to sign their exe's and the exe's if cracked can be added to a list that windows 11 can force update the bios to add these cracked exes to a list that will refuse to run.
That's the gist of trusted computing they are building an alternative internet/mainframe computer inside yours that they only have access to.
Where have you been the last 23+ years? The videogame industry has been stealing PC games since 1997 with ultima online. Hear it from the dev's themselves.
Don't think MMO's killed local PC games? Listen here kids.
https://youtu.be/lnnsDi7Sxq0?t=1134
EA killed ultima 9 when the UO beta got massive interest, that lead to the death of PC games as local applications, the industry from then on there was a massive war to back end all PC games, they couldn't immediately do that to quake and urneal because we'd been treated too good with Warcraft 1-3, Descent 1-3, Quake 1-3, and build engine games like Duke 3d. The entire industry has always wanted to kill piracy and Ultima online gave the entire industry the go ahead once they realized that many of our fellow programmers and gamers were irrationally stupid beyond their wildest dreams.
Anyone playing quake and Descent at the time fear the loss of dedicated servers and level editors which used to come with the games, we knew if Ultima online was successful that Publishers would want to back end every fucking PC game and that's the end of the personal computer and the return of IBM and mainframe computing.
"Signed exe's" and trusted computing is the return of mainframe computing of the 60's in new bullshit language but I don't expect the mmo/steam generation to do anything but froth at the mouth. When they were the ones killing gaming and gave birth to microtransactions.
You can't put MTX in diablo 1, warcraft 1-3, or starcraft 1 because they are local applications that run entirely from your pc. None of the code has been stolen out of the game carved back behind a user account and login requirement. Like with most PC games these days.
We're losing gaming history and generation mmo is to blame for their general cluelessness of the evil of mainframe computing.
That's the gist of trusted computing they are building an alternative internet/mainframe computer inside yours that they only have access to.
Where have you been the last 23+ years? The videogame industry has been stealing PC games since 1997 with ultima online. Hear it from the dev's themselves.
Don't think MMO's killed local PC games? Listen here kids.
https://youtu.be/lnnsDi7Sxq0?t=1134
EA killed ultima 9 when the UO beta got massive interest, that lead to the death of PC games as local applications, the industry from then on there was a massive war to back end all PC games, they couldn't immediately do that to quake and urneal because we'd been treated too good with Warcraft 1-3, Descent 1-3, Quake 1-3, and build engine games like Duke 3d. The entire industry has always wanted to kill piracy and Ultima online gave the entire industry the go ahead once they realized that many of our fellow programmers and gamers were irrationally stupid beyond their wildest dreams.
Anyone playing quake and Descent at the time fear the loss of dedicated servers and level editors which used to come with the games, we knew if Ultima online was successful that Publishers would want to back end every fucking PC game and that's the end of the personal computer and the return of IBM and mainframe computing.
"Signed exe's" and trusted computing is the return of mainframe computing of the 60's in new bullshit language but I don't expect the mmo/steam generation to do anything but froth at the mouth. When they were the ones killing gaming and gave birth to microtransactions.
You can't put MTX in diablo 1, warcraft 1-3, or starcraft 1 because they are local applications that run entirely from your pc. None of the code has been stolen out of the game carved back behind a user account and login requirement. Like with most PC games these days.
We're losing gaming history and generation mmo is to blame for their general cluelessness of the evil of mainframe computing.
https certificates leak all the time and we still use https. Something is better than nothing. Now, is it worthwhile to use code signing certs to try and certify the identity of the author? Maybe not, it was slowly phased out for https. But we certainly need something because the alternative (just download and run whatever) was tried and definitely did not work out. We don't want grandma doing the equivalent of 'curl http://x | sudo bash' 4 times a week.
I don't get why companies that large would bother considering not using HSMs. Basically it's about public-key encryption, even if https is not ideal, it's quite a widespread implementation that can be sufficiently secure for many use cases
My understanding is that HSMs are a requirement, and the leaked certificate predates it.
You put they keys in the owner's hands with a method of changing them that can only he done with physical access.
"what's the point of laws so complex criminals can't understand them? They'll be broken anyway"
Finally I can develop and publish open source drivers for Windows again.
Guess someone out there still believes that windows code signing is a security feature rather than just a way to keep the smaller developers out of the ecosystem.
Guess someone out there still believes that windows code signing is a security feature rather than just a way to keep the smaller developers out of the ecosystem.
For keys issued 6+ years ago...
https://twitter.com/BillDemirkapi/status/1499735326406938625
https://twitter.com/BillDemirkapi/status/1499735326406938625
This would be revoked soon enough right?
> Code signed with this cert will, in the right conditions, be accepted by Windows even though the certificate has expired.
The right conditions: https://twitter.com/BillDemirkapi/status/1499735326406938625
The right conditions: https://twitter.com/BillDemirkapi/status/1499735326406938625
Probably not. It's an expired certificate, and AFAIK, expired certificates are removed from certificate revocation lists.
Probably not as revoking would likely break NVIDIA drivers.
Very unlikely NVIDIA have been signing with an expired cert for 5 years.
The real reason this is problematic is that Windows kernel driver signing wasn't complete before 2015. For signing (of anything) to be robust, it must be paired with a timestamping server. The signature then has these components:
1. The signature itself.
2. The certificate.
3. A data structure containing a hash of the signature, and a timestamp, signed by a timestamping authority.
The purpose of (3) is to prove when the signature was computed, which in turn means that signatures can live longer than the certificates themselves. Note that normal Windows (and Apple) code signing for user space gets this right for a long time. Apparently Windows didn't in kernel mode until 7 years ago.
Introducing timestamping isn't all that easy. If you stop accepting signatures because the underlying certificate expired, then you just put a time bomb in everyone's computers. So Microsoft had to allow the usage of expired certs and hope they'd never leak. They (eventually) lost that bet and the cert will now be revoked, but it won't have been used for many years so probably the overall damage is small.
The real reason this is problematic is that Windows kernel driver signing wasn't complete before 2015. For signing (of anything) to be robust, it must be paired with a timestamping server. The signature then has these components:
1. The signature itself.
2. The certificate.
3. A data structure containing a hash of the signature, and a timestamp, signed by a timestamping authority.
The purpose of (3) is to prove when the signature was computed, which in turn means that signatures can live longer than the certificates themselves. Note that normal Windows (and Apple) code signing for user space gets this right for a long time. Apparently Windows didn't in kernel mode until 7 years ago.
Introducing timestamping isn't all that easy. If you stop accepting signatures because the underlying certificate expired, then you just put a time bomb in everyone's computers. So Microsoft had to allow the usage of expired certs and hope they'd never leak. They (eventually) lost that bet and the cert will now be revoked, but it won't have been used for many years so probably the overall damage is small.
Oh well. They should be revoked ASAP anyway. Old releases can be re-signed then re-downloaded.
Any situation where certs cannot be revoked for any reason is bad.
Any situation where certs cannot be revoked for any reason is bad.
The problem is re-downloading. I think this will take some time.
Hmmm maybe i should keep windows offline for a few days…..
It would require code execution on your computer in order to install a signed driver. That being said, any malware using the Nvidia certificate would be the easiest malware to find since we know the certificate used.
I always use opportunities like this to experiment with whatever workflow I have on Linux to see what state it's at. I just game on Windows and do work on Linux so for me the transition is always quite simple: just install what you want on Steam/lutris and compare performance.
Last time I was starting vanishing of Ethan Carter, but even though it was playable, the experience wasn't free of stutters, whereas windows ran flawlessly.
In any case, it is always nice to jump back and check out how far Linux has come.
Last time I was starting vanishing of Ethan Carter, but even though it was playable, the experience wasn't free of stutters, whereas windows ran flawlessly.
In any case, it is always nice to jump back and check out how far Linux has come.
A stolen code signing certificate affect Linux in the same capacity as Windows.
I'm of course ignoring the fact that a lot of Linux distros still do not have Secure Boot enabled by default, and therefore do not enforce any kernel driver signing policy.
I'm of course ignoring the fact that a lot of Linux distros still do not have Secure Boot enabled by default, and therefore do not enforce any kernel driver signing policy.
Huh? I don't know what you consider "Linux distros", but Fedora has had SB working and on by default for quite a while now.
Sure, Fedora has Secure Boot. So does Ubuntu, Debian and FreeBSD. According to DistroWatch[1], 26 Linux distros out of 927 have built-in support for Secure Boot, so I stand by what I said.
[1] https://distrowatch.com/search.php?pkg=shim&relation=lessequ...
[1] https://distrowatch.com/search.php?pkg=shim&relation=lessequ...
I bet he meant the small ones instead of major distros i.e. Red Hat/Fedora, Ubuntu, SUSE.
Probably because those distros haven't developed a relationship with Microsoft. I'm reasonably certain that in order to distribute Linux on SB, you have to build the kernel as a Windows executable and get MS to sign it.
Most manufactures decided to include Microsoft's signing key into firmware. That is not something Microsoft is in control of. Pre-loaded (factory) keys are much harder for Linux as it seems every distro wants their own signing key, and from an administration perspective, that is not easy to keep track of.
Everyone can load their own signing keys into firmware. However, if you want something that "just works", Microsoft signs a package called Shim[1] that can be loaded on most computers due to the pre-loaded keys.
A relationship with Microsoft is not needed in any way or form to have Secure Boot.
[1] https://launchpad.net/ubuntu/+source/shim
Everyone can load their own signing keys into firmware. However, if you want something that "just works", Microsoft signs a package called Shim[1] that can be loaded on most computers due to the pre-loaded keys.
A relationship with Microsoft is not needed in any way or form to have Secure Boot.
[1] https://launchpad.net/ubuntu/+source/shim
> Most manufactures decided to include Microsoft's signing key into firmware. That is not something Microsoft is in control of.
AFAIK if a manufacturer wants to sell Windows PC, it has to support secure boot.
AFAIK if a manufacturer wants to sell Windows PC, it has to support secure boot.
What's stopping the bad guys from using that shim to boot their own code? Is there a date when the shim expires and Microsoft has to renew it?
Well, it is a chain of trusted components that are responsible for loading the next component in the chain.
UEFI with Secure Boot enabled will only load the stage 1 bootloader if it is signed with the firmware trusted certificate. We don't know if this component is malicious, we just know it is signed by the certificate.
The stage 1 bootloader (shim) will then be responsible for loading the next component (stage 2 bootloader). It will only boot the component if it is signed with a trusted (chosen by the user/distro) certificate.
The bad guys can't insert themselves into this process, as they either have to be trusted by the UEFI firmware (protected by an owner password), signed by Microsoft (to replace the shim) or be signed by the distro's certificate.
As long as the chain is unbroken it is secure.
UEFI with Secure Boot enabled will only load the stage 1 bootloader if it is signed with the firmware trusted certificate. We don't know if this component is malicious, we just know it is signed by the certificate.
The stage 1 bootloader (shim) will then be responsible for loading the next component (stage 2 bootloader). It will only boot the component if it is signed with a trusted (chosen by the user/distro) certificate.
The bad guys can't insert themselves into this process, as they either have to be trusted by the UEFI firmware (protected by an owner password), signed by Microsoft (to replace the shim) or be signed by the distro's certificate.
As long as the chain is unbroken it is secure.
That's only possible if Microsoft signs a public key the distro owner controls and then embeds it inside a special build of their shim. In that case the distro owner can distribute any Linux Kernel they want, but they need authorization from Microsoft beforehand. Therefore you can't publish a UEFI Linux desktop without being in league with the adversary.
Aren't Linux packages signatures verified upon delivery with gpg keys? Whereas windows verifies them upon installation.
Can the same certificate be used to cause supply chain attacks?
Can the same certificate be used to cause supply chain attacks?
Verification of packages is something that is controlled by the distro, not the Linux kernel. However, if we are talking about drivers (modules), then they are verified at load time in both operating systems.
As for Windows packages, there are several "package" systems:
- AppInstaller (winget): A SHA256 hash is included in the application manifest. I might be wrong, but I do not believe the manifests are signed afterwards. Packages are verified upon installation.
- MSIX packages: They are signed and timestamped with a publisher certificate. They are verified upon installation.
- Executables: Not really packages as such, but PS1 scripts and .EXE executables support Authenticode signatures. They are verified upon execution.
As for Linux, there are several package systems:
- DPKG/DEB: Built-in support for verification with hashes generated at install time. Packages can be GPG signed for stronger security, but it is disabled by default. Repository metadata is often GPG signed.
- RPM: Like DEB above it supports verification with MD5. It also has GPG integration. I believe it is disabled by default as well.
Linux does unfortunately not have support for signatures of ELF executables.
As for Windows packages, there are several "package" systems:
- AppInstaller (winget): A SHA256 hash is included in the application manifest. I might be wrong, but I do not believe the manifests are signed afterwards. Packages are verified upon installation.
- MSIX packages: They are signed and timestamped with a publisher certificate. They are verified upon installation.
- Executables: Not really packages as such, but PS1 scripts and .EXE executables support Authenticode signatures. They are verified upon execution.
As for Linux, there are several package systems:
- DPKG/DEB: Built-in support for verification with hashes generated at install time. Packages can be GPG signed for stronger security, but it is disabled by default. Repository metadata is often GPG signed.
- RPM: Like DEB above it supports verification with MD5. It also has GPG integration. I believe it is disabled by default as well.
Linux does unfortunately not have support for signatures of ELF executables.
> Linux does unfortunately not have support for signatures of ELF executables
Fortunately. This whole pseudo security brings nothing.
People scream about right to repair. When certificate is revoked or has expired your computer will stop working. It's that simple.
Fortunately. This whole pseudo security brings nothing.
People scream about right to repair. When certificate is revoked or has expired your computer will stop working. It's that simple.
It is not pseudo security. A secure booted system that can only load signed software is the optimal solution for preventing unauthorized code from running. iOS on iPhone/iPad is a great example where you can be sure nobody can insert themselves into the OS unless it is signed by Apple.
There is nothing in Secure Boot that prevent people from running their own software. You can update the Secure Boot DB/DBX with whatever you want. Yes, the certificates expire - my computer was bought 4 years ago and Microsoft's UEFI CA will expire in 4 years. At that point I will probably have bought a new computer, but if I have not, I can update the certificate to the new one they released.
Secure Boot is very much an improvement over non-secure booting, and Authenticode signing is an extension of that security to enable signed-only software to run.
There is nothing in Secure Boot that prevent people from running their own software. You can update the Secure Boot DB/DBX with whatever you want. Yes, the certificates expire - my computer was bought 4 years ago and Microsoft's UEFI CA will expire in 4 years. At that point I will probably have bought a new computer, but if I have not, I can update the certificate to the new one they released.
Secure Boot is very much an improvement over non-secure booting, and Authenticode signing is an extension of that security to enable signed-only software to run.
It is pseudo-security. SElinux and "mount noexec" already provide sysadmins with control over all the code that can be executed on a machine.
> It is not pseudo security. A secure booted system that can only load signed software is the optimal solution for preventing unauthorized code from running. iOS on iPhone/iPad is a great example where you can be sure nobody can insert themselves into the OS unless it is signed by Apple.
Pegasus.
Pegasus.
As a person who has been doing this for past 20 years, I'd say, yes, you should )
Your certificates will expire. Your computer will be bricked.
Best not turn it on again at all. Just to be sure ;)
If malware makes it onto your machine, it's already game over. The certificate allows the attacker to load an arbitrary driver, but the attacker doesn't need that to steal all your data.
relevant xkcd: https://xkcd.com/1200/
relevant xkcd: https://xkcd.com/1200/
Then why are malware authors exploiting this vulnerability?
Because some corporate environments only allow you to run signed executables. "Defense in depth" :)
So it’s effective in those environments?
> So it’s effective in those environments?
No. Those environments will happyly install the malware code because it is signed by Microsoft.
No. Those environments will happyly install the malware code because it is signed by Microsoft.
The original post I was responding to was saying it was already game over regardless of whether hacker had the ability to sign their binary.
Clearly that isn’t true.
Clearly that isn’t true.
Well, that is... an interesting leak, but not exactly the types of certificate that this hacker group was treating to release on Friday.
I think they are "showing their teeth" cuing that it's just the beginning.
An interesting leak from a entity with a very interesting request in the first place.
An interesting leak from a entity with a very interesting request in the first place.
[deleted]
As opposed to the regular nvidia cert which normally signs windows drivers (ie drivers for malware)? This is a total non-story
But... can we haz better Linux drivers after this? :)