I'd have taken a trip down to Buenos Aires and sold it.
RCE in Visual Studio Code's Remote WSL for Fun and Negative Profit
11–20 of 109 posts
Re: RCE in Visual Studio Code's Remote WSL for Fun and Negative Profit
#12I'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…
Re: RCE in Visual Studio Code's Remote WSL for Fun and Negative Profit
#13Not making websockets follow the same-origin policy was a mistake.
Re: RCE in Visual Studio Code's Remote WSL for Fun and Negative Profit
#14Issues 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 it's an extension that's not installed by default.
Re: RCE in Visual Studio Code's Remote WSL for Fun and Negative Profit
#15Issues 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…
Re: RCE in Visual Studio Code's Remote WSL for Fun and Negative Profit
#16Earlier 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.
Re: RCE in Visual Studio Code's Remote WSL for Fun and Negative Profit
#17Not making websockets follow the same-origin policy was a mistake.
Re: RCE in Visual Studio Code's Remote WSL for Fun and Negative Profit
#18Issues 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…
Yes, indeed!
Re: RCE in Visual Studio Code's Remote WSL for Fun and Negative Profit
#19Issues 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
#20Issues 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.
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.