[morgante]

Yikes, this is a pretty bad vulnerability. It's good that they fixed it, but damning that it was ever a problem in the first place.

Rule #1 of building any cloud platform analyzing user code is that you must run analyzers in isolated environments. Even beyond analysis tools frequently allowing direct code injection through plugins, linters/analyzers/compiler are complex software artifacts with large surface areas for bugs. You should ~never assume it's safe to run a tool against arbitrary repos in a shared environment.

I also ran a code analysis platform, where we ran our own analyzer[1] against customer repos. Even though we developed the analyzer ourself, and didn't include any access to environment variables or network requests, I still architected it so executions ran in a sandbox. It's the only safe way to analyze code.

[1] https://github.com/getgrit/gritql

[smarx007]

How was the sandbox implemented? Just a one-off Docker container execution or something more substantial?

[morgante]

We built on firecracker VMMs but today I'd just use a hosted provider like morph.so or e2b.dev.

[KingOfCoders]

Did I misread the article, or did they take the tool config from the PR not the repo?

[yxhuvud]

Unfortunately that mostly has to be the case or else the developer experience configuring these would be too bad.

[morgante]

The exploit is there either way.