NVIDIA today put out an official Security Bulletin, noting multiple flaws found in their Windows and Linux drivers. The good news is that drivers are already out that fix the problems, which I'll detail below.
Here's all those that affect Linux, brace yourself, there's quite a few of them:
CVE‑2022‑34670 - NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer handler, where an unprivileged regular user can cause truncation errors when casting a primitive to a primitive of smaller size causes data to be lost in the conversion, which may lead to denial of service or information disclosure.
CVE‑2022‑42263 - NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer handler, where an Integer overflow may lead to denial of service or information disclosure.
CVE‑2022‑34676 - NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer handler, where an out-of-bounds read may lead to denial of service, information disclosure, or data tampering.
CVE‑2022‑42264 - NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer, where an unprivileged regular user can cause the use of an out-of-range pointer offset, which may lead to data tampering, data loss, information disclosure, or denial of service.
CVE‑2022‑34674 - NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer handler, where a helper function maps more physical pages than were requested, which may lead to undefined behavior or an information leak.
CVE‑2022‑34678 - NVIDIA GPU Display Driver for Windows and Linux contains a vulnerability in the kernel mode layer, where an unprivileged user can cause a null-pointer dereference, which may lead to denial of service.
CVE‑2022‑34679 - NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer handler, where an unhandled return value can lead to a null-pointer dereference, which may lead to denial of service.
CVE‑2022‑34680 - NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer handler, where an integer truncation can lead to an out-of-bounds read, which may lead to denial of service.
CVE‑2022‑34677 - NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer handler, where an unprivileged regular user can cause an integer to be truncated, which may lead to denial of service or data tampering.
CVE‑2022‑34682 - NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer, where an unprivileged regular user can cause a null-pointer dereference, which may lead to denial of service.
CVE‑2022‑42257 - NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer (nvidia.ko), where an integer overflow may lead to information disclosure, data tampering or denial of service.
CVE‑2022‑42265 - NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer (nvidia.ko), where an integer overflow may lead to information disclosure or data tampering.
CVE‑2022‑34684 - NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer (nvidia.ko), where an off-by-one error may lead to data tampering or information disclosure.
CVE‑2022‑42254 - NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer (nvidia.ko), where an out-of-bounds array access may lead to denial of service, data tampering, or information disclosure.
CVE‑2022‑42258 - NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer (nvidia.ko), where an integer overflow may lead to denial of service, data tampering, or information disclosure.
CVE‑2022‑42255 - NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer (nvidia.ko), where an out-of-bounds array access may lead to denial of service, information disclosure, or data tampering.
CVE‑2022‑42256 - NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer (nvidia.ko), where an integer overflow in index validation may lead to denial of service, information disclosure, or data tampering.
CVE‑2022‑34673 - NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer (nvidia.ko), where an out-of-bounds array access may lead to denial of service, information disclosure, or data tampering.
CVE‑2022‑42259 - NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer (nvidia.ko), where an integer overflow may lead to denial of service.
There's also a few for NVIDIA VGPU and they affect Tesla too. There's also some that only affect Windows, this isn't a Linux-specific thing but a lot of them are just in their Linux drivers.
As mentioned, the good news is that drivers are already out that solve them. For GeForce users you want minimum driver versions 525.60.11, 515.86.01, 510.108.03, 470.161.03 or 390.157. For RTX, Quadro or NVS you want a minimum driver version of 525.60.11, 515.86.01, 510.108.03, 470.161.03 or 390.157. To put it very simply, if you're not using the very latest NVIDIA drivers in whatever series — update now, all previous versions are vulnerable to the drivers released on November 22nd.
Going by the bulletin page, the issues were public on November 28 but they've seemingly only just actually put out the security bulletin email.
Article taken from GamingOnLinux.com.
vengador4201 Dec 4, 2022
All of this is sort of a strong perimeter approach tough since one of the single most important things is to harden the system itself. Of that, probably the most important method is to apply operating system and other software updates as soon as practical. This makes sure that announced and unannounced security fixes are applied (sometimes it's prudent for a security fix to be shipped quietly at first to allow the global ecosystem to get patched at least some before making the existence of the vulnerability that was fixed known).
Hardening the system itself matters a lot because it may only take an attacker achieving arbitrary code execution to then exploit a vulnerability in the system that could then be chained through other exploits, if needed, to reach privileged access on the system or otherwise compromise the system and/or its data. The mentioned driver vulnerabilities in the OP seem to all downplay the impact, but I believe I've seen other vulnerability descriptions of "out of range", "out of bounds", "null pointer dereference", and "information disclosure" result in arbitrary code execution, which at the kernel level can mean full system compromise, which as the OP notes, can be done by an unprivileged user, thus arbitrary code execution with those kernel-level vulnerabilities may mean full system compromise, meaning patching the vulnerabilities should be done as soon as practical.
Why as soon as practical? Because an awful lot of vulnerabilities in browsers and the like can lead to arbitrary code execution as the user running the application, which combined with the above, could mean full system compromise. And that's on top of all of the code we're running on our systems from others that we have to trust hasn't suffered what's effectively a supply-chain compromise or in some of our cases, we run because it looks like it'll do something we want (I'll also admit to not always reviewing some code before running it that's from sources other than my OS distribution or some other widely-known and used source and I generally know how to do such a review).
So patch early, patch often. Patching sooner is almost always better than patching later; with good backups, which we should all have (3 copies, 2 backup copies on different media types, 1 backup copy off-site), can minimize a lot of the impact of patching too soon in the rare cases its a problem.
And to expand on what @BlackBloodRun said, if you're not running a service disable it (and possibly uninstall it) since a service that's not available/running/installed can't be hacked no matter how good the attacker is at hacking that service. Like-wise, if you don't use an application, uninstall it: that's one less thing an attacker could potentially exploit if they do manage to get arbitrary code execution on your system. If you must run SSH, especially open to the Internet, a tool like fail2ban can reduce the risk, especially if password-based authentication is used.
walther von stolzing Dec 4, 2022
Yeah, my personal preference is still to always enable the firewall (also in a home setup) and I still recommend to do so, but I guess it is no longer a sin to not do so.There's nothing wrong with that
In fact, I do the same. I was merely explaining why some may or may not use a firewall. My biggest complaint is that ssh is activated by default on new installs with password authentication and some distros then open up port 22. It's basically asking for trouble.
(If there's one thing everyone absolutely should do is disable ssh password authentication and if using ssh, switch to key based authentication. If not using it, disable the service.)
-- and to cut down the noise in your logs, use a port other than 22 on interfaces connected to the outside world. People are quick to point out that this is not a security measure; & that's true, but it's not meant as such. You just don't want to see 10000 failed attempts per day from probes all over the world on your little home computer.
(Same with opening :80 or :443 to the outside world, regardless whether you're exposing anything of importance. There are a billion probes poking at those ports, no matter what the address might be.)
vengador4201 Dec 4, 2022
and to cut down the noise in your logs, use a port other than 22 on interfaces connected to the outside world. People are quick to point out that this is not a security measure; & that's true, but it's not meant as such. You just don't want to see 10000 failed attempts per day from probes all over the world on your little home computer.
(Same with opening :80 or :443 to the outside world, regardless whether you're exposing anything of importance. There are a billion probes poking at those ports, no matter what the address might be.)
...assuming they're not just looking at all ports with a tool like masscan (think nmap, but much faster at scanning for open ports).
No. You only need to assume most of them aren't doing full port-range probing, only a few. It's for cutting down on log noise, not for making it safer. It doesn't make it actually safer exactly because of those fewer cases where all ports are targeted instead of just the default ones.and to cut down the noise in your logs, use a port other than 22 on interfaces connected to the outside world. People are quick to point out that this is not a security measure; & that's true, but it's not meant as such. You just don't want to see 10000 failed attempts per day from probes all over the world on your little home computer.
(Same with opening :80 or :443 to the outside world, regardless whether you're exposing anything of importance. There are a billion probes poking at those ports, no matter what the address might be.)
...assuming they're not just looking at all ports with a tool like masscan (think nmap, but much faster at scanning for open ports).
Patreon
PayPal
See more from me