zlacker

[return to "Leaked stolen Nvidia cert can sign Windows malware"]
1. bratwu+B8[view] [source] 2022-03-05 11:29:23
>>Zuider+(OP)
Hmmm maybe i should keep windows offline for a few days…..
◧◩
2. gchamo+x9[view] [source] 2022-03-05 11:35:23
>>bratwu+B8
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.

◧◩◪
3. Genbox+Td[view] [source] 2022-03-05 12:16:32
>>gchamo+x9
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.

◧◩◪◨
4. gchamo+Nw[view] [source] 2022-03-05 14:48:46
>>Genbox+Td
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?

◧◩◪◨⬒
5. Genbox+PA[view] [source] 2022-03-05 15:19:39
>>gchamo+Nw
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.

◧◩◪◨⬒⬓
6. hulitu+LT[view] [source] 2022-03-05 17:16:10
>>Genbox+PA
> 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.

◧◩◪◨⬒⬓⬔
7. Genbox+IP1[view] [source] 2022-03-05 23:24:00
>>hulitu+LT
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.

◧◩◪◨⬒⬓⬔⧯
8. JetSpi+T8m[view] [source] 2022-03-12 13:12:40
>>Genbox+IP1
It is pseudo-security. SElinux and "mount noexec" already provide sysadmins with control over all the code that can be executed on a machine.
[go to top]