RCE in Visual Studio Code's Remote WSL for Fun and Negative Profit

Re:RCE in Visual Studio Code's Remote WSL for Fun and Negati... by Karliss on Tuesday December 21, 2021 @05:28AM (#29635942)

Issues like this have been repeated countless times in various IDEs, debugger interfaces and local services using browser as UI. Developers need to stop using network sockets as IPC channels for local services unless browsers significantly increase the restrictions on cross site requests. Similar situation with regular CSRF attacks. And it needs to be opt out not opt in. As long it's a responsibility of developer to implement proper authentication checks for something they consider a local service vulnerabilities like this will keep appearing.

[ Parent | on HN ]

Re:RCE in Visual Studio Code's Remote WSL for Fun and Negati... by stefan_ on Tuesday December 21, 2021 @06:47AM (#29636442)

> Browsers need to stop connecting to anything other than what's typed into the navigation bar.

Yes, indeed!

[ Parent | on HN ]

Re:RCE in Visual Studio Code's Remote WSL for Fun and Negati... by seoaeu on Tuesday December 21, 2021 @08:38AM (#29637226)

A web browser that doesn’t support links isn’t much of a web browser

[ Parent | on HN ]

Re:RCE in Visual Studio Code's Remote WSL for Fun and Negati... by e12e on Tuesday December 21, 2021 @11:08AM (#29638721)

... Or images? I suppose one might enforce a draconian same-origin policy.. But that would no longer be "the web" I think.

[ Parent | on HN ]

Re:RCE in Visual Studio Code's Remote WSL for Fun and Negati... by faeyanpiraat on Tuesday December 21, 2021 @08:41AM (#29637268)

Explicitly clicking on a link is almost like typing it in the url bar, so that can be an exception

[ Parent | on HN ]

Re:RCE in Visual Studio Code's Remote WSL for Fun and Negati... by Xelbair on Tuesday December 21, 2021 @06:56AM (#29636501)

oh how i would love this future.

[ Parent | on HN ]

Re:RCE in Visual Studio Code's Remote WSL for Fun and Negati... by cryptonym on Tuesday December 21, 2021 @08:55AM (#29637366)

At this point of time, I give it 10min before we get a magic_proxy nginx module, then your script src will be /magic_proxy/www.evilthirdpary.com/slow_multi_megabyte_script.js

You can still import all nasty third parties required by marketing department, bypassing first party protections and leading to even worse security. Or maybe maintain allow lists, basically that's a Content Security Policy.

Future is now old man.

[ Parent | on HN ]

Re:RCE in Visual Studio Code's Remote WSL for Fun and Negati... by MarkSweep on Tuesday December 21, 2021 @11:00AM (#29638621)

This already here, but made with a subdomain that CNAMEs to a tracker domain:

https://arxiv.org/abs/2102.09301

[ Parent | on HN ]

Re:RCE in Visual Studio Code's Remote WSL for Fun and Negati... by Xelbair on Tuesday December 21, 2021 @09:50AM (#29637878)

sure, but as other person stated -servers deals with that, and all legal implications about data protection apply to them - it's harder to weasel out of it that way.

[ Parent | on HN ]

Re:RCE in Visual Studio Code's Remote WSL for Fun and Negati... by Pxtl on Tuesday December 21, 2021 @09:41AM (#29637769)

At least then the server has to deal with the security implications of talking directly to the advertiser, instead of pushing the risk wholly to the client.

[ Parent | on HN ]

Re:RCE in Visual Studio Code's Remote WSL for Fun and Negati... by cryptonym on Tuesday December 21, 2021 @09:57AM (#29637955)

In the end the script is running on client, dealing with user data, not server data. Client is still taking the risk.

On moral/legal issues, integrating script from third or first party hostname sounds like technical detail. If you select partner to run their code on your pages, you should be responsible checking user consent when applicable and taking responsibility. British Airways has been fined £20m even if that script was not on their servers.

[ Parent | on HN ]

Re:RCE in Visual Studio Code's Remote WSL for Fun and Negati... by hdjjhhvvhga on Tuesday December 21, 2021 @07:28AM (#29636730)

Unfortunately, the companies that control today's web have a different view, and they are the ones in charge.

[ Parent | on HN ]

Re:RCE in Visual Studio Code's Remote WSL for Fun and Negati... by formerly_proven on Tuesday December 21, 2021 @06:31AM (#29636341)

In this case the application used websockets, which is supported by browsers natively - but another thing to keep in mind is that any website can send somewhat controlled HTTP requests (not subject to CORS/preflight) to just about anything, regardless of if that's an HTTP server or not. If the receiving side is permissive enough, things might happen. Possibly unwanted things.

[ Parent | on HN ]

Re:RCE in Visual Studio Code's Remote WSL for Fun and Negati... by nine_k on Tuesday December 21, 2021 @08:09AM (#29636995)

What if browsers learned to connect to Unix sockets? And windows named pipes? And users could control these endpoints by the usual filesystem permissions?

One can dream.

[ Parent | on HN ]

Re:RCE in Visual Studio Code's Remote WSL for Fun and Negati... by meepmorp on Tuesday December 21, 2021 @11:35AM (#29639015)

Isn't this more or less the idea behind plan 9?

[ Parent | on HN ]

Re:RCE in Visual Studio Code's Remote WSL for Fun and Negati... by Arnavion on Tuesday December 21, 2021 @04:32PM (#29642360)

You don't even need Windows named pipes. Windows supports AF_UNIX since 10.

[ Parent | on HN ]

Re:RCE in Visual Studio Code's Remote WSL for Fun and Negati... by turminal on Tuesday December 21, 2021 @08:22AM (#29637105)

More scope creep?

Browser are already way too big.

[ Parent | on HN ]

Re:RCE in Visual Studio Code's Remote WSL for Fun and Negati... by scandinavian on Tuesday December 21, 2021 @06:30AM (#29636334)

> And it needs to be opt out not opt in

In this case it's an extension that's not installed by default.

[ Parent | on HN ]

Re:RCE in Visual Studio Code's Remote WSL for Fun and Negati... by Karliss on Tuesday December 21, 2021 @07:00AM (#29636530)

I am talking about default behavior of browsers and network libraries used to implement services listening to network requests.

Not whether installing an extension whose purpose is interacting between locally running IDE and locally running VM can be considered opting in it interacting with network in any way.

[ Parent | on HN ]

Re:RCE in Visual Studio Code's Remote WSL for Fun and Negati... by niros_valtos on Saturday December 25, 2021 @11:11AM (#29684373)

The problem isn’t using one tech or another, but the fact that malicious extensions can be installed and we cannot detect it.

[ Parent | on HN ]

Re:RCE in Visual Studio Code's Remote WSL for Fun and Negati... by silon42 on Tuesday December 21, 2021 @06:02AM (#29636175)

Also, using browser as UI should not mean downloading JS ever.

[ Parent | on HN ]