Hacker News Reader

Comment by Jaygles | Hacker News Reader

This is a huge deal right? VSCode has to be one of the most popular editors and the standard way of setting up the Rust toolchain on a machine would get you in a state that makes you vulnerable to this.

View on HN

The only component is an editor that runs some code automatically.

A python plugin for an editor would have the same problem - if it imports a python module for any reason, like code completion. Same problem of arbitrary code execution.

I think we should work on solutions. Sandboxing both for editor plugins and for regular rust builds, should become the norm.

Sandboxing isn’t necessary. Proper use of SELinux, which the Linux kernel in your computer already supports even if your distro doesn’t enable it, would already prevent any process other than ssh from reading your private key. The build system could run ssh and ssh would be allowed to read the key, but the key is still safe as long as ssh cannot be tricked into revealing it. Since that’s generally believed to be the case, no sandboxing is necessary.

If your distro doesn’t enable SELinux, or your distro’s SELinux policy doesn’t protect your ssh keys, then you need to upgrade. If you don’t use Linux, then you need to upgrade to Linux.

Calling it a need to upgrade if I don't have SELinux is a little combative --- I'm perfectly happy with my AppArmor thankyouverymuch :)

I’ve not used AppArmor much, but I guess it’s at least better than nothing :)

We use SELinux at work. It's really a lot of work to check all requests whether they're legitimate or not.

No argument there. The one downside of any fine–grained security system is the work it takes to build and maintain the security policy.

SELinux is nothing but a maintenance burden for developers and users. There's a reason no major distro beyond the Fedora line that enables it by default, including the one I work one; it almost invariably frustrates users, has incomplete support for the workflows they use, and so they turn it off anyway. I literally turned off SELinux on my new ARM64 Fedora machine last week, because it prevented me from installing a third party binary (which I am a developer of.) That binary in turn needed its own ability to use namespacing support to sandbox applications (in a manner that works and offers enhanced security on any Linux distro, not just SELinux ones), etc. It's a non-starter.

> Since that’s generally believed to be the case, no sandboxing is necessary.

That's where you're wrong. It's necessary even if you believe it's not. It's been proven time and time again that this is the case and that the "belief" no flaws exist is wrong.

Sandboxing approaches that use techniques like namespaces, and capability security have become vastly, vastly more popular over the years on Linux, and they're going to keep getting more popular, precisely because they work where SELinux fails (that is, 98% of the running Linux systems and distros that actually exist). Browsers, WebAssembly, systems like Flatpak with "Portals" -- all of them have moved into capability-inspired and "component" sandboxing approaches, to achieve this level of security independent of the host operating system. If Chrome had decided to use SELinux instead of its own sandboxing approach, it's security model would be completely inferior to what it is today.

Don’t confuse the sandboxing a browser does with other types. I would never argue that a browser shouldn’t sandbox javascript. The kernel should also prevent the browser from reading your SSH keys as well, just in case :)

If I rememver correctly, the python plugin for vscode asks me whether I trust the project before running anything. At least that was the case when I last opened a Jupyter notebook in vscode.

This is as huge a deal as "using ./configure && make install to exfiltrate secrets."

It's a class of supply chain attack focusing on build time code evaluation. Almost every programming language has some kind of support for arbitrary code execution at build time, and any project of scale is going to require it.

RCE isn't an interesting exploit when the system is literally designed to run code from somewhere else.

This isn’t build time though really, which I agree is a moment you would expect to run arbitrary code. This is “edit time.”

It is build time. Whether rust-analyzer should run build-time code at initialization is a different discussion.

That is a more philosophical definition of build time than what I am referring to.

It's not philosophical, it is literal.

Rust macros and build.rs require build commands to be executed by the rust compiler (cargo check, for example).

These are third party tools that have been implemented to execute build commands during initialization. It's not an issue with Rust, it's an issue with the implementation of the language client and text editor allowing the client to initialize when opening a workspace.

What I mean is that my definition of build time is more things that happen when you are running a build. If you do build time things at other times then I don’t personally consider them build time activities any more. You have converted your build time activities into something more general at that point.

They may be spiritually or metaphorically still build steps in some sense, but they are happening outside that context.

No, it's worse. People will have very different expectations. Running 'make install' especially as root implies a high level of trust, so users will be appropriately cautious. Users won't expect that simply opening code in an editor will be similarly risky (though it's similar to malicious Word and Excel macros, Office now disables those by default for documents coming from an untrusted source, like via email).

It requires never actually running the program to be worse than the status quo in any language. If you run code it's trivially a code execution.

Reply on news.ycombinator.com