8 ms·

If I'm reading the bulletin right, then all the issues can only be exploited from code already running on your machine. So if you have a single user machine and

If I'm reading the bulletin right, then all the issues can only be exploited from code already running on your machine. So if you have a single user machine and aren't already owned then this is a non-issue and the verbiage in the title and PC World article are not warranted. The people that actually need to update are: * Multi-user systems with some untrusted users. * Users with malware on their system already (which could privilege escalate) * virtualization hosts of untrusted guests.

HellsMaddy 2y ago
I wonder if it could be exploited via WebGL/WebGPU?
ummonk 2y ago
Does that mean it cannot be exploited through WebGL?
solardev 2y ago
I wonder if this affects Geforce Now
TazeTSchnitzel 2y ago
If you use a web browser or play multiplayer video games then there will be code running on your system that interacts with GPU drivers that you haven't explicitly chosen to download and which could potentially exploit certain vulnerabilities.
- smolder 2y ago
  This highlights why we shouldn't let browsers (google) keep expanding their reach outside of the historical sandbox. It's almost like all the in-browser Java and Flash problems being repeated. They're creating security problems more than helping legitimate developers. WebGL was fine. Websockets were fine. WebGPU and the recently proposed arbitrary socket API are jumping the shark. Raw GPU access and TCP/UDP access are simply bad ideas from inexperienced people and need to be shut down. If you truly need that stuff I think the solution is to step up your game and make native applications.
  - kmeisthax 2y ago
    I'm not sure why WebGPU is a step too far but WebGL isn't? Every other API for using a GPU went the same direction; why should HTML be stuck with a JS projection of OpenGL ES while native developers get Vulkan? The security properties of both are very similar, Vulkan/Metal/DX12 just lets you skip varying levels of compatibility nonsense inherent in old graphics APIs.
    - ChadNauseam 2y ago
      I agree. I'm not knowledgable enough to say for sure, but my intuition is that the total complexity of WebGPU (browser implementation + driver) is usually less than the total complexity of WebGL.
      - smolder 2y ago
        WebGL is like letting your browser use your GPU with a condom on, and WebGPU is doing the same without one. The indirection is useful for safety assuming people maintain the standard and think about it. Opening up capability in the browser needs to be a careful process. It has not been recently.
        macguillicuddy 2y ago
        It's my understanding that the browsers use a translation layer (such as ANGLE) between both WebGL and WebGPU and a preferred lower level native API (Vulkan or Metal). In this regard I don't believe WebGL has any more or less protection than WebGPU. It's not right to confuse abstraction with a layer of security.
        immibis 2y ago
        The translation layer is the safety layer. In principle, it's like running Java bytecode instead of machine code.
        deleted 2y ago
- fsflover 2y ago
  This is why Qubes OS, which runs everything in isolated VMs, doesn't allow them to use the GPU. My daily driver, can't recommend it enough if you care about security.
  - ThePowerOfFuet 2y ago
    GPU support for Qubes is coming.
    - fsflover 2y ago
      Opt-in for chosen, trusted VMs is coming.
  - thot_experiment 2y ago
    What is your threat model that you chose to daily something so restrictive?
    - fsflover 2y ago
      Numerous vulnerabilities are found in all browsers regularly, as well as in the root isolation in Linux. Similar with other OSes. The discussed article is one example. In addition, Qubes is not so restrictive, if you don't play games or run LLMs. See also: https://forum.qubes-os.org/t/how-to-pitch-qubes-os/4499/15 https://forum.qubes-os.org/t/how-to-pitch-qubes-os/4499/15
      - thot_experiment 2y ago
        I asked about your threat model, I'm aware that there are numerous vulnerabilities found in all browsers regularly. I just personally don't have a reason to care about that. It's like driving on the highway, every time you do it you create a period of vastly increased mortality in your life but that's often still very worthwhile, imo using Qubes is like going on back roads only because your odds of dying at highway speeds are so much higher.
- highwaylights 2y ago
  This to me is the big risk here. A worm hidden in a game mod or something. I can see it staying in the wild for a long time too. How many of the people that are playing on these cards, or crypto mining, or doing LLM work, are really going to even find out about these vulnerabilities and update the drivers?
  - gruez 2y ago
    >This to me is the big risk here. A worm hidden in a game mod or something. Game mods are already barely sandboxed to begin with. Unless proven otherwise (ie. by manually inspecting the mod package), you should treat game mods the same as random exes you got off the internet, not harmless apps you install on a whim.
- ferbivore 2y ago
  The attack surface from a browser is tiny. All you can do is call into ANGLE or Dawn through documented, well-defined and well-tested APIs. Or use things like canvas and CSS animations, I suppose. Browser vendors care a lot about security, so they try to make sure these libraries are solid and you can't interact with the GPU in any other way. Native applications talk directly to the GPU's kernel-mode driver. The intended flow is that you call into the vendor's user-mode drivers - which are dynamic libraries in your application's address space - and they generate commands and execute ioctls on your application's behalf. The interface between these libraries and the KMD is usually undocumented, ill-defined and poorly tested. GPU vendors don't tend to care about security, so if the KMD doesn't properly validate some inputs, well, that issue can persist a long time. And if there's any bit of control stream that lets you tell the GPU to copy stuff between memory you own and memory you don't... I guess you get a very long security bulletin. The point is, webpages have access to a much smaller attack surface than native applications. It's unlikely anything in this bulletin is exploitable through a browser.
fsckboy 2y ago
>if you have a single user machine and aren't already owned then this is a non-issue if you have a single user machine and ARE already owned then this is REALLY a non-issue for you.
ryukoposting 2y ago
I wonder if single-user systems running something like a1111 should be concerned. Could the plugin system be an attack vehicle?
- gruez 2y ago
  A cursory search suggests such plugins aren't sandboxed and run with the same privileges as the main program itself, so I'd definitely be suspicious of any plugin.

HellsMaddy 2y ago

I wonder if it could be exploited via WebGL/WebGPU?

ummonk 2y ago

Does that mean it cannot be exploited through WebGL?

solardev 2y ago

I wonder if this affects Geforce Now

TazeTSchnitzel 2y ago

If you use a web browser or play multiplayer video games then there will be code running on your system that interacts with GPU drivers that you haven't explicitly chosen to download and which could potentially exploit certain vulnerabilities.

smolder 2y ago
This highlights why we shouldn't let browsers (google) keep expanding their reach outside of the historical sandbox. It's almost like all the in-browser Java and Flash problems being repeated. They're creating security problems more than helping legitimate developers. WebGL was fine. Websockets were fine. WebGPU and the recently proposed arbitrary socket API are jumping the shark. Raw GPU access and TCP/UDP access are simply bad ideas from inexperienced people and need to be shut down. If you truly need that stuff I think the solution is to step up your game and make native applications.
- kmeisthax 2y ago
  I'm not sure why WebGPU is a step too far but WebGL isn't? Every other API for using a GPU went the same direction; why should HTML be stuck with a JS projection of OpenGL ES while native developers get Vulkan? The security properties of both are very similar, Vulkan/Metal/DX12 just lets you skip varying levels of compatibility nonsense inherent in old graphics APIs.
  - ChadNauseam 2y ago
    I agree. I'm not knowledgable enough to say for sure, but my intuition is that the total complexity of WebGPU (browser implementation + driver) is usually less than the total complexity of WebGL.
    - smolder 2y ago
      WebGL is like letting your browser use your GPU with a condom on, and WebGPU is doing the same without one. The indirection is useful for safety assuming people maintain the standard and think about it. Opening up capability in the browser needs to be a careful process. It has not been recently.
      - macguillicuddy 2y ago
        It's my understanding that the browsers use a translation layer (such as ANGLE) between both WebGL and WebGPU and a preferred lower level native API (Vulkan or Metal). In this regard I don't believe WebGL has any more or less protection than WebGPU. It's not right to confuse abstraction with a layer of security.
        immibis 2y ago
        The translation layer is the safety layer. In principle, it's like running Java bytecode instead of machine code.
        deleted 2y ago
fsflover 2y ago
This is why Qubes OS, which runs everything in isolated VMs, doesn't allow them to use the GPU. My daily driver, can't recommend it enough if you care about security.
- ThePowerOfFuet 2y ago
  GPU support for Qubes is coming.
  - fsflover 2y ago
    Opt-in for chosen, trusted VMs is coming.
- thot_experiment 2y ago
  What is your threat model that you chose to daily something so restrictive?
  - fsflover 2y ago
    Numerous vulnerabilities are found in all browsers regularly, as well as in the root isolation in Linux. Similar with other OSes. The discussed article is one example. In addition, Qubes is not so restrictive, if you don't play games or run LLMs. See also: https://forum.qubes-os.org/t/how-to-pitch-qubes-os/4499/15 https://forum.qubes-os.org/t/how-to-pitch-qubes-os/4499/15
    - thot_experiment 2y ago
      I asked about your threat model, I'm aware that there are numerous vulnerabilities found in all browsers regularly. I just personally don't have a reason to care about that. It's like driving on the highway, every time you do it you create a period of vastly increased mortality in your life but that's often still very worthwhile, imo using Qubes is like going on back roads only because your odds of dying at highway speeds are so much higher.
highwaylights 2y ago
This to me is the big risk here. A worm hidden in a game mod or something. I can see it staying in the wild for a long time too. How many of the people that are playing on these cards, or crypto mining, or doing LLM work, are really going to even find out about these vulnerabilities and update the drivers?
- gruez 2y ago
  >This to me is the big risk here. A worm hidden in a game mod or something. Game mods are already barely sandboxed to begin with. Unless proven otherwise (ie. by manually inspecting the mod package), you should treat game mods the same as random exes you got off the internet, not harmless apps you install on a whim.
ferbivore 2y ago
The attack surface from a browser is tiny. All you can do is call into ANGLE or Dawn through documented, well-defined and well-tested APIs. Or use things like canvas and CSS animations, I suppose. Browser vendors care a lot about security, so they try to make sure these libraries are solid and you can't interact with the GPU in any other way. Native applications talk directly to the GPU's kernel-mode driver. The intended flow is that you call into the vendor's user-mode drivers - which are dynamic libraries in your application's address space - and they generate commands and execute ioctls on your application's behalf. The interface between these libraries and the KMD is usually undocumented, ill-defined and poorly tested. GPU vendors don't tend to care about security, so if the KMD doesn't properly validate some inputs, well, that issue can persist a long time. And if there's any bit of control stream that lets you tell the GPU to copy stuff between memory you own and memory you don't... I guess you get a very long security bulletin. The point is, webpages have access to a much smaller attack surface than native applications. It's unlikely anything in this bulletin is exploitable through a browser.

fsckboy 2y ago

>if you have a single user machine and aren't already owned then this is a non-issue if you have a single user machine and ARE already owned then this is REALLY a non-issue for you.

ryukoposting 2y ago

I wonder if single-user systems running something like a1111 should be concerned. Could the plugin system be an attack vehicle?

gruez 2y ago
A cursory search suggests such plugins aren't sandboxed and run with the same privileges as the main program itself, so I'd definitely be suspicious of any plugin.