[HN Gopher] Leaked stolen Nvidia cert can sign Windows malware
___________________________________________________________________
Leaked stolen Nvidia cert can sign Windows malware
Author : Zuider
Score : 158 points
Date : 2022-03-05 09:40 UTC (13 hours ago)
(HTM) web link (www.theregister.com)
(TXT) w3m dump (www.theregister.com)
| themusicgod1 wrote:
| As opposed to the regular nvidia cert which normally signs
| windows drivers (ie drivers for malware)? This is a total non-
| story
| asah wrote:
| For keys issued 6+ years ago...
|
| https://twitter.com/BillDemirkapi/status/1499735326406938625
| IYasha wrote:
| But... can we haz better Linux drivers after this? :)
| AshamedCaptain wrote:
| 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.
| pintxo wrote:
| 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?
| Genbox wrote:
| 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.
| pintxo wrote:
| Is there any proof that most others store their certificates
| on hardware?
| Genbox wrote:
| 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.
| native_samples wrote:
| I bought a Windows EV code signing cert just months ago. It
| comes in the form of a password protected USB token.
| gruez wrote:
| 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"
| imglorp wrote:
| 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.
| aaaaaaaaata wrote:
| The /shrug continues until everyone here stops buying Lenovo
| hardware after they shipped a rootkit, etc
| CyanBird wrote:
| Listen, I really like their Legion series
|
| If people have got recommendations I am all ears
| gruez wrote:
| > 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.
| AshamedCaptain wrote:
| You cant disable signature enforcement on Windows. You can
| test sign and only if you disable secure boot and enjoy
| desktop watermarks.
| Wowfunhappy wrote:
| ^ Not enough people are angry about this! I have a
| permanent watermark on my desktop because I use EDID
| overrides and some unsigned drivers for niche video game
| controllers. It sucks.
| krastanov wrote:
| 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?
| imglorp wrote:
| Linux lets you ignore signatures if you prefer. There are
| plenty of devices that don't.
| kevingadd wrote:
| 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.
| blablabla123 wrote:
| 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
| hulitu wrote:
| > We don't want grandma doing the equivalent of 'curl
| http://x | sudo bash' 4 times a week.
|
| That's why we have web browsers running untrusted remote
| code.
| linster wrote:
| "what's the point of laws so complex criminals can't understand
| them? They'll be broken anyway"
| PragmaticPulp wrote:
| "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.
| ddtaylor wrote:
| Defense in depth.
| postalrat wrote:
| 10 layers of weak defenses should be enough for anyone.
| jimmaswell wrote:
| > 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.
| willis936 wrote:
| I don't think their overlords can approve that they never
| see. That's the issue with bad private cert security. The
| system is as strong as its weakest link.
| bratwurst3000 wrote:
| Hmmm maybe i should keep windows offline for a few days.....
| IYasha wrote:
| As a person who has been doing this for past 20 years, I'd say,
| yes, you should )
| 15characterslon wrote:
| Best not turn it on again at all. Just to be sure ;)
| gchamonlive wrote:
| 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.
| Genbox wrote:
| 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.
| chousuke wrote:
| 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.
| Genbox wrote:
| 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...
| scns wrote:
| I bet he meant the small ones instead of major distros
| i.e. Red Hat/Fedora, Ubuntu, SUSE.
| gchamonlive wrote:
| 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?
| Genbox wrote:
| 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.
| hulitu wrote:
| > 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.
| jart wrote:
| 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.
| Genbox wrote:
| 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
| jart wrote:
| 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?
| hulitu wrote:
| Your certificates will expire. Your computer will be bricked.
| Genbox wrote:
| 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.
| gruez wrote:
| 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/
| ec109685 wrote:
| Then why are malware authors exploiting this vulnerability?
| hulitu wrote:
| Because some corporate environments only allow you to run
| signed executables. "Defense in depth" :)
| ec109685 wrote:
| So it's effective in those environments?
| ramshanker wrote:
| This would be revoked soon enough right?
| cesarb wrote:
| Probably not. It's an expired certificate, and AFAIK, expired
| certificates are removed from certificate revocation lists.
| encryptluks2 wrote:
| Probably not as revoking would likely break NVIDIA drivers.
| native_samples wrote:
| 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.
| willis936 wrote:
| 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.
| encryptluks2 wrote:
| The problem is re-downloading. I think this will take some
| time.
| h2odragon wrote:
| > 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
| [deleted]
| gjsman-1000 wrote:
| Well, that is... an interesting leak, but not exactly the types
| of certificate that this hacker group was treating to release on
| Friday.
| can16358p wrote:
| 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.
___________________________________________________________________
(page generated 2022-03-05 23:02 UTC)