Live data from Hacker News

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

parsiya.net

11–20 of 109 posts

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

#11

I'd have taken a trip down to Buenos Aires and sold it.

I am not 100% sure, but wouldn't that be a crime under the laws of many countries? If someone left their car unlocked with keys next to your house. Will you also steal it and sell it to somebody?

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

#12

I'd have taken a trip down to Buenos Aires and sold it.

While most of me likes the idea of being paid good money for my efforts, or even for doing nothing if I can get away with it, a rather pesky part of me (a nagging entity that calls itself “a conscience”) would take all the fun out of doing it by enabling harm to others (via selling information on possible exploits, for instance). The other blockers of course being that I have neither the skills nor the time to find s…

meh, if you don't do it someone else will.

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

#13
post #4

Not making websockets follow the same-origin policy was a mistake.

I suppose that case can be made, but in this case the direct cause of the vulnerability is the WebSocket server not checking the HTTP Origin header in direct violation of the standard (RFC6455), which is spells out at that doing so is a MUST. I could maybe understand whitelisting localhost and file URLs, but giving a carte blanche -on every single interface no less- is just absurdly negligent.

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

#14
post #5

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…

> And it needs to be opt out not opt in

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

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

#15
post #5

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…

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.

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

#16

Earlier quoted context omitted.

While most of me likes the idea of being paid good money for my efforts, or even for doing nothing if I can get away with it, a rather pesky part of me (a nagging entity that calls itself “a conscience”) would take all the fun out of doing it by enabling harm to others (via selling information on possible exploits, for instance). The other blockers of course being that I have neither the skills nor the time to find s…

meh, if you don't do it someone else will.

I prefer to judge others by standards I keep myself, rather than slipping mine towards the lowest common denominator. Both because it is morally right IMO and, I must admit, because I like feeling a little superior.

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

#18
post #5

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…

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

Yes, indeed!

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

#19
post #18
post #5

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…

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

oh how i would love this future.

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

#20
post #5

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…

> And it needs to be opt out not opt in In this case it's an extension that's not installed by default.

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.

Post reply on HN