37 ms·

I’m not sure I agree with your fatalistic take on (1). As an example, the proof-of-concept proc macro attack from the article could be addressed by running proc

I’m not sure I agree with your fatalistic take on (1). As an example, the proof-of-concept proc macro attack from the article could be addressed by running proc macros in a wasm sandbox. I know there’s been some exploratory work done towards that. Similarly, all of the attacks that execute code at compile time are mostly addressed currently by building code in a Docker container. It’s not a perfect security measure, but it greatly increases the probability that a build.rs or proc macro attack will fail. Your (1) strikes me as something that can never be solved to provide 100% safety, but that there are partial solutions which, in practice, can significantly reduce the attack surface. And hiding behind “fundamentally unsolvable problem” will get in the way pushing for the meaningful half-measures that offer some degree of real-world protection.

kevincox 5y ago
> could be addressed by running proc macros in a wasm sandbox Kind of. That will stop the compromise on build, but odds are then you run the code anyways so injecting the code into the executable is almost as good. I guess if you are building an application that is always run in a sandbox anyways (like a wasm application that never sees sensitive data) then sandboxing proc macros could be good enough but I suspect that is a very rare case.
- curun1r 5y ago
  My comment specifically called it out as a half measure. But that doesn’t mean it’s not worth doing. One of the ways that I’d see a proc macro attack playing out in real life would be to attempt to obtain the API token from cargo login to allow the attacker to publish a malicious version of a popular crate. But if cargo login is only run on the CI instance responsible for publishing and developers test their code on their individual dev machines, the attack fails. We shouldn’t worry about making security 100% effective. Rather, we should be concerned with stopping as many different attacks as we can and providing users with as many building blocks as possible to let them protect themselves. There will always be vulnerabilities. But using that as an excuse for inaction isn’t helpful.
pjmlp 5y ago
The sandbox doesn't protect against injection of malicious code.
Diggsey 5y ago
> As an example, the proof-of-concept proc macro attack from the article could be addressed by running proc macros in a wasm sandbox. I know there’s been some exploratory work done towards that. Sure, you can (and we absolutely should) sandbox the build process itself. I meant "running other people's code outside of a sandbox", and should have specified that. The problem is that at some point you actually want to run the code you compiled, and then proc-macro exploits can still do whatever. > hiding behind “fundamentally unsolvable problem” will get in the way pushing for the meaningful half-measures that offer some degree of real-world protection. I didn't say they were unsolvable, I said that solving them requires someone or something to review the code. That's the only way you can gain trust that code does what it says it does. I even suggested some possible "meaningul half-measures" that could be implemented.

kevincox 5y ago

> could be addressed by running proc macros in a wasm sandbox Kind of. That will stop the compromise on build, but odds are then you run the code anyways so injecting the code into the executable is almost as good. I guess if you are building an application that is always run in a sandbox anyways (like a wasm application that never sees sensitive data) then sandboxing proc macros could be good enough but I suspect that is a very rare case.

curun1r 5y ago
My comment specifically called it out as a half measure. But that doesn’t mean it’s not worth doing. One of the ways that I’d see a proc macro attack playing out in real life would be to attempt to obtain the API token from cargo login to allow the attacker to publish a malicious version of a popular crate. But if cargo login is only run on the CI instance responsible for publishing and developers test their code on their individual dev machines, the attack fails. We shouldn’t worry about making security 100% effective. Rather, we should be concerned with stopping as many different attacks as we can and providing users with as many building blocks as possible to let them protect themselves. There will always be vulnerabilities. But using that as an excuse for inaction isn’t helpful.

pjmlp 5y ago

The sandbox doesn't protect against injection of malicious code.

Diggsey 5y ago

> As an example, the proof-of-concept proc macro attack from the article could be addressed by running proc macros in a wasm sandbox. I know there’s been some exploratory work done towards that. Sure, you can (and we absolutely should) sandbox the build process itself. I meant "running other people's code outside of a sandbox", and should have specified that. The problem is that at some point you actually want to run the code you compiled, and then proc-macro exploits can still do whatever. > hiding behind “fundamentally unsolvable problem” will get in the way pushing for the meaningful half-measures that offer some degree of real-world protection. I didn't say they were unsolvable, I said that solving them requires someone or something to review the code. That's the only way you can gain trust that code does what it says it does. I even suggested some possible "meaningul half-measures" that could be implemented.