Hacker News Reader

Comment by MaxBarraclough | Hacker News Reader

Will this API be opt-in, or can we expect another security disaster like with WebGL?

https://news.ycombinator.com/item?id=16457791 , https://www.contextis.com/en/blog/webgl-a-new-dimension-for-... , https://www.contextis.com/en/blog/webgl-more-webgl-security-...

Edit I should have given a quote from one of the articles covering the issue, so here's one:

> anyone running Firefox 4 with WebGL support is vulnerable to having malicious web pages capture screenshots of any window on their system

View on HN

It's up to the browser to decide if it's enabled by default at some point in the future. There is nothing in a Web API saying that it has to be forcefully enabled.

I do share the concern that security of talking to the GPUs is hard. We'll do our best. I think it's important for the Web platform to reach this capability.

Interestingly, the implementations are more diverse, because there isn't a single Angle-like library that everyone is going to use. This may mean that it's easier to find a vulnerability in a concrete browser, but harder to make an exploit that works portably.

I feel like this should require the user's explicit permission, just like audio, camera, location or Flash and Java Applets at the end of their life.

WebGPU is a great innovation, but we have both privacy and security concerns here. It should be available where and when the user wants it, not silently in the background.

Why don't you say the same about CPU or RAM? In the end it's just resources that are abstracted away to the user, used with the purpose of performing tasks in the most efficient way possible.

Because some resources have mature security controls around them, and some don't.

Why do you care if someone can see your bank account number? In the end they're just numbers.

> Because some resources have mature security controls around them

So we thought, then ROWHAMMER arrived..

What you really want is a security first web browser, not something that must prioritize feature completeness to achieve commercial success. I would love a spin-off of the Tor browser sans Tor.

A lot of other web APIs and features had rce vulnerable implementations in stable browser releases when they were new, some worse than others. Eg webaudio, SVG, etc. Not an excuse of course but tells of the cross cutting systemic problems.

Browsers should be run in a VM, via a fake GPU which is mapped to a window ( possibly root window ) of a main desktop. Giving code fetched from the internet in real time full access to hardware, especially complex hardware, is lunacy. I'm shocked that neither Google nor Mozilla still have internalized this lesson.

The browser should simply disable WebGPU by default. It's already intended to be sandboxed, but given what happened with WebGL, I'm not convinced we can trust it. There's nothing to gain by faking a GPU.

Edit For clarity, I'm saying you may as well just disable WebGPU. A CPU-based simulated GPU would indeed improve security, but its performance would be so atrocious that there would be no point having it compared to the existing drawing APIs.

There is - it is a GPU with all the bells and whistles but even if the browser's security context is broken, the browser cannot access anything on a real desktop.

It's not clear what you have in mind here, but I think you're referring to using a CPU-based virtual GPU to power the browser's WebGPU engine, to avoid GPU-related security issues.

A CPU-based fake GPU is guaranteed to have performance so poor that it isn't worth doing. This is the reason modern graphics APIs don't make provisions for CPU-based implementations.

If we aren't confident in the security of the WebGPU implementation (and we're agreed that we aren't), the solution is simply to disable support for WebGPU in the browser. The browser can still offer facilities like the Canvas API.

> It's not clear what you have in mind here, but I think you're referring to using a CPU-based virtual GPU to power the browser's WebGPU engine, to avoid GPU-related security issues.

That was my mistake - i was not clear. I'm talking about virtualized GPUs that can be passed to a VM running a minimum system needed to boot a browser.

Ok, so you're suggesting always running the browser in a VM, and using the GPU from within the VM (via the host OS of course).

I believe significant work has been done on the browser/graphics sandboxing problem. Whether browsers use techniques comparable to virtualisation, I don't know. I'm afraid I don't know much about how that's done, or how effectively virtualisation is able to contain the operations of VMs, or how high the performance penalty is.

Going with guesswork though, it seems to me virtualisation doesn't offer particularly solid guarantees here. If the host OS has a buggy graphics driver, it would presumably be possible for it to leak data back to the VM. Any facilities the GPU can offer to help contain semi-trusted graphics contexts, should presumably be available for use directly by the browsers, without running a guest OS in virtualisation.

The reason why I want to see a virtualized web browser is because it is becoming an insanely complex piece of software with an insanely large attack surface.

I do not want my browser to be able to talk to Bluetooth devices that are connected to my desktop. I do not want want my browser to be able to access random files on my file system simply because it is accessible to me. I do not want a web browser have ability to have GPU access outside the specific virtualized section of it that can only access the part of the screen and off-screen buffers associated with the window of a browser.

I started localizing different web browsers into dedicated VMs that have just a minimal operating system and a web browser. It works well enough for my use case ( i can playback youtube video almost like I could do it on my 2015 laptop ) but it is definitely hacky.

> The reason why I want to see a virtualized web browser is because it is becoming an insanely complex piece of software with an insanely large attack surface.

This is true, and it's the reason Chromium goes to great lengths to sandbox itself to contain the damage regarding JavaScript engine exploits. Annoyingly Firefox is lagging behind in that regard.

> I do not want a web browser have ability to have GPU access outside the specific virtualized section of it that can only access the part of the screen and off-screen buffers associated with the window of a browser.

Virtualisation will improve your general security, but it's isn't a perfect abstraction especially when it comes to GPUs, and it's not a rock-solid guarantee of the isolation assurances you want. [0] I believe cloud-computing providers never split a GPU between customers, for instance. Disabling sharing of the GPU with the VM would further improve your security at the price of performance.

[0] https://www.hpcwire.com/2018/05/31/gpus-excellent-performanc...

> Annoyingly Firefox is lagging behind in that regard.

This has not been true since quite a while. Firefox has employed sandboxing even before the multi-process work (which culminated in the Quantum branches of Fx releases that added more and more sandboxing with each release). Before that, Moz went a different way than OS level sandboxing by principal containerization (I forgot the correct term, sorry), which worked in terms of separation of execution contexts (of Web JS and other parts like the styling system, plus the browser internals). Elements of that implementation have been removed by now (iirc) since the multi-process split required different communication paths anyway (which also enabled per-origin/-tab/-window OS-Level sandboxing), so that code was no longer needed.

Thanks for the reply, you know much more about it than I do.

What could an attacker do if they were able to trick the JIT into emitting evil native code?

I would say there is no simple answer to your question. However, I am not able to give you an authoritative answer to your question anyway. If you are interested, you can start here[1] or try and ping the moz-security people

[1] https://wiki.mozilla.org/Security/Sandbox

Thanks

> There's nothing to gain by faking a GPU.

Moving applications that can do anything into sandboxed pages in a browser that can't do arbitrary things to the user's system is a win. The more capable the browser is, the more things that once would have been downloaded applications can become safely sandboxed pages.

As I said, it's already intended to be sandboxed for security. As I've clarified in an edit, my point was that CPU-based virtual GPUs perform so poorly that they aren't worth implementing.

Could just have an interface to request access for use, such as with camera and sound/microphone.

Browser should not be an arbiter of it wanting to access camera/microphone/bluetooth/gpu/etc. Browser should only be able to ask host and it should be hosts' job to allow/deny access based on a policy, asking a user, time of day, etc.

If they did that the feature would be DOA. Some of us want it.

Obviously you know better than Microsoft, Google, Apple, Intel, Mozilla and anyone else working on WebGPU.

Interestingly, this is not far from how things currently work with webgl - the sandbox, separate renderer process & browser internal safe GL implementation. No doubt webgpu will use similar things. It'd of course be a nonstarter to give full access to hardware or anything of the sort.

I agree that it would be nice to see stronger hypervisor based sandboxes.

The web is an ever growing rube goldberg machine of security vunlerabilities. The web is impossible to secure and the web will never be secure. Only browse sites that you trust, with JavaScript disabled and adblocking enabled, and hope that they haven't been compromised. This is the best you can do in the face of the reckless behavior of browser vendors.

Fingerprinting is one security concern.

Security implications are always good to point out, though this is not unique to webGPU at all. Some fingerprinting techniques don't even require enabling javascript.

Crypto mining is another

Whether or not the API is opt-in is orthogonal to its security hardening - this is a false dichotomy.

But that's not what parent was saying, I think. He was saying that WebGL not being opt-in was a security disaster; while saying nothing about the security hardening of the WebGL module itself.

Even when a module is well tested, I'd like non-essential modules to be opt-in too.

I’d like Javascript to be opt-in. Turning it on by default was a mistake.

You are free to disable it as a very small minority.

The web is not a static document viewing anymore. Now I agree, that sites should have a static fallback, as I also do not want to run a full webapp, when all I want is a static article for example. But this is because of a different problem - the financing of most of the web, through advertisment and not the fault of javascript.

Much like frames, iframes and window.open are really useful features... advertisers and abusers made it bad. I remember the first time I saw a popup in the 90's, my first thought was, "oh this is going to get bad." And I would never buy a product from X10.

I'm not suggesting any false dichotomy, I'm trying to reason about the likely security consequences given what we saw with WebGL in Firefox: serious security flaws in its implementation, with the features enabled in the browser by default. See my links above, one of which summarises with anyone running Firefox 4 with WebGL support is vulnerable to having malicious web pages capture screenshots of any window on their system.

My thoughts are along these lines:

    ┌────────────────────┬──────────────────────────┬──────────────────────────────┐
    │                    │  Secure implementation   │  Insecure implementation     │
    ├────────────────────┼──────────────────────────┼──────────────────────────────┤
    │ Opt-in             │  Minimal security impact │  Significant security impact │
    │ Enabled by default │  Minimal security impact │  Security disaster           │
    └────────────────────┴──────────────────────────┴──────────────────────────────┘

First time I've seen a decent-looking ASCII table in an HN comment. Well-done!

Thanks, it's technically not an ASCII table, it's from the Unicode (single line) style of https://ozh.github.io/ascii-tables/

Running firefox 4 (or any other comparably old browser), this would be the least of your security problems, it's not even RCE. The stream of discovered vulnerabilities is constant.

What's your point? Do you really think I was suggesting that people are still running Firefox 4?

When WebGL was first implemented in Firefox - long ago - it shipped with serious security flaws. This struck many people as sadly predictable, as graphics APIs like OpenGL are not intended to be accessible from untrusted code. WebGPU seems awfully similar to WebGL in this respect: it's trying to wrap a low-level graphics API in a secure sandboxed API. This isn't the equivalent of a routine addition like a new feature in CSS.

The point was that seen from the future, old browser versions are always full of holes in all kinds of features, more in new features than old ones, we should fix the systemic problems that make browsers so ridden with vulnerabilities.

But yes I am guilty of some whataboutism here, WebGL did have some unique problems and WebGPU devs hopefully learn from them.

This is really old information

Reply on news.ycombinator.com