7 ms·
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 explici
by 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 agoThis 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 agoI'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 agoI 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 agoWebGL 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 agoIt'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 agoThe translation layer is the safety layer. In principle, it's like running Java bytecode instead of machine code.
- deleted 2y ago[deleted]
- smolder 2y agoMy analogy was bad and I'd probably be wrong as you (and your sibling post) say to expect WebGPU to have any lurking dangers as compared to WebGL. I was mainly trying to express concern with new APIs and capabilities being regularly added, and the danger inherent in growing these surfaces.
- modeless 2y agoIt's clear that you know nothing about how WebGL or WebGPU are implemented. WebGPU is not more "raw" than WebGL. You should stop speaking confidently on these topics and misleading people who don't realize that you are not an expert.
- smolder 2y agoI'd dispute that I know nothing. I'm not an expert but have worked with both, mostly WebGL. Anyways, sorry, it was a bad analogy and you're right, I don't know enough, particularly to say that WebGPU has any unique flaws or exposes any problems not in WebGL. I'm merely suspicious that it could, and maybe that is just from ignorance in this case.
- 2y ago
- deleted 2y ago[deleted]
- smolder 2y ago> why should HTML be stuck with a JS projection of OpenGL ES while native developers get Vulkan? Because web browsers are supposed to be locked down and able to run untrusted code, not an operating system that reinvents all the same failings of actual operating systems. They should be functionality impaired in favor of safety as much as possible. For the same reason you don't get access to high precision timing in browser (a lesson that took a while to learn!), you shouldn't have arbitrary capabilities piled onto it.
- imiric 2y agoThose are all historical remnants. Modern web browsers serve a radically different purpose than they did in the 90s. It doesn't make sense to even keep calling them "web browsers" since most people don't know what a "web" is, let alone "browse" it. Modern browsers are application runtimes with a very flexible delivery mechanism. It's really up to web developers to decide what features this system should have to enable rich experiences for their users. Declaring that they should be functionally impaired or what they "should be" without taking into account the user experience we want to deliver is the wrong way of approaching this. To be clear: I do think we should take security very seriously, especially in the one program people use the most. I also think reinventing operating systems to run within other operating systems is silly. But the web browser has become the primary application runtime and is how most people experience computing, so enabling it to deliver rich user experiences is inevitable. Doing this without compromising security or privacy is a very difficult problem, which should be addressed. It's not like the web is not a security and privacy nightmare without this already. So the solution is not to restrict functionality in order to safeguard security, but to find a way to implement these features securely and safely.
- codedokode 2y agoBoth WebGL and WebGPU should be locked behind permission because they allow fingerprinting user's hardware (also they provide the name of user's graphic card). And because they expose your GPU drivers to the whole world.
- chrisjj 2y ago> why should HTML be stuck with a JS projection of OpenGL ES while native developers get Vulkan? Same reason kids should be stuck with Nerf guns while grownups have firearms.
- deleted 2y ago[deleted]
- exodust 2y ago> step up your game and make native applications. Each to their own but I consider native applications a step down from web apps. "Screw it, I'm giving up my web app and will now pay Apple/Google the protection money and margin they demand to shelter within their ad-ridden ecosystem lock-in." ... yeh that's definitely a step down.
- smolder 2y agoYou're talking like android and ios are the only platforms. The downsides of those platforms don't justify a web browser (which should be safe to use) granting excessive capability to untrusted code.
- nkrisc 2y agoIf you’re targeting a mass market audience they often are the only platforms. For many people their phone is their only computing device.
- lodovic 2y agoNeither Apple or Google are in scope for this issue. This is about NVidia GPUs.
- Thorrez 2y agoAre you saying that WebGPU should only be supported on Android and iOS, because Android and iOS have more secure GPUs? Desktop browsers shouldn't support WebGPU (but should continue supporting WebGL)?
- godelski 2y agoIsn't WebGPU supposed to be containerized? So that it only access its processes, which are the computations it is running for rendering? I honestly don't know much but I had heard it was sandboxed.
- a2128 2y agoIt's not uncommon that I go to Shadertoy and see strange visual artifacts in some shaders including window contents of other applications running on my system, potentially including sensitive information. It's difficult to make GPU access secure because GPU vendors never really prioritized security, so there's countless ways to do something that's wonky and accidentally leaks memory from something the app isn't supposed to have access to. You can containerize CPU and have strict guarantees that there's no way host memory will map into the container, but AFAIK this isn't a thing on GPUs except in some enterprise cards.
- flohofwoe 2y ago> ... including window contents of other applications running on my system, potentially including sensitive information. If this is actually the case (which I doubt very much - no offense) then please definitely write a ticket to your browser vendor, because that would be a massive security problem and would be more news-worthy than this NVIDIA CVE (leaking image data into WebGL textures was actually a bug I remember right around the time when WebGL was in development, but that was fixed quickly).
- godelski 2y agoYeah that sounds like a basic garbage collection issue and isn't that the very basics of sandboxing? Is the rule not to not hand memory to a sandbox that hasn't already been overwritten with 0s or random information? This sounds analogous to the old C lack of bounds checking where you could steal passwords and stuff just by accessing out of bound memory. Is this not low hanging fruit?
- whywhywhywhy 2y ago> I think the solution is to step up your game and make native applications Say goodbye to anyone supporting Linux at all in that case. These rare security issues are a small price to pay for having software that works everywhere.
- chrisjj 2y agoRephrasing that: malware that works everywhere is a small price for software that works everywhere. It isn't. And there is no basis for your assertion these security issues are rare.
- whywhywhywhy 2y ago> malware that works everywhere is a small price for software that works everywhere Yes. Although the malware we're talking about doesn't actually work everywhere but only one one brand of GPU. But I would take it working everywhere over my computer not being useful.
- cjk 2y agoAgree wholeheartedly (and I used to work on Safari/WebKit). Cross-platform app frameworks have never been a panacea, but I think there may be a middle ground to be found between the web and truly native apps. Something with a shallower learning curve, batteries-included updating and distribution, etc. that isn’t the web or Electron. That said, I worry that it’s too late. Even if such a framework were to magically appear, the momentum of the complex beast that is the web platform will probably not slow.
- vbezhenar 2y agoTCP/UDP access is behind explicit prompt and it's basically the same as executing downloaded application, so I don't think that it's anything bad. Basically you either install software to your local system which does not have any restrictions or you use web application which still is pretty restricted and contained.
- chrisjj 2y ago> TCP/UDP access is behind explicit prompt ... that is satisfied by a single click from malware or social engineering. Insane.
- vbezhenar 2y agoWould you be happy with two clicks? Three clicks? Like what's the principal difference? As I said, you can download and run arbitrary application with one click today. And may be second click to confirm to operating system (not sure if it's always necessary). Insane thing is that arbitrary application has instantly full access to your computer. And web application still heavily constrained and has to ask about almost every permission.
- chrisjj 2y agoI would accept zero clicks on a browser that I've installed without this dangerous feature and /with a promise no autoupdate will sneak it in/. The reason your web page has to be imprisoned in permissions is that it is a web page from just about anyone using access that the browser has given it without telling the user.
- chrisjj 2y agoClose your eyes before you see WebUSB. Reckless and irresponsible in the extreme.
- _flux 2y agoWebMIDI is cool, though! I updated my Novation Launchpad firmware with that.
- 2OEH8eoCRo0 2y agoThey just keep promising more access to my machine but don't worry it is all totally secure! We promise! Yeah sure, when has that ever worked out?
- fsflover 2y agoThis 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 agoGPU support for Qubes is coming.
- fsflover 2y agoOpt-in for chosen, trusted VMs is coming.
- thot_experiment 2y agoWhat is your threat model that you chose to daily something so restrictive?
- fsflover 2y agoNumerous 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 agoI 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 agoThis 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 agoThe 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.