Hi,
I wanted to ask whether there were any security concerns around the ERB-based pre-processing of RuboCop config added in #7920?
I can see how this is a very useful feature. Indeed, I used it in our own RuboCop config here @bambooengineering, only to find that Hound CI currently does not support it (I've opened a PR there for it, which triggered this).
For example, if nefarious person X has a repo with RuboCop config that did something bad (like a curl POST to their server of the contents of the user's SSH key), is there anything to stop that from happening?
I realise it's difficult to hide this, as the bad code would be right there, in the config file. But I guess you wouldn't necessarily think to look at the RuboCop config file for a project before running rubocop locally?
Am I missing something?
Thanks,
Joe.
The config file already allows to require any Ruby file... So looks like running RuboCop on untrusted config files was already potential security issue. Preprocessing the config file with erb does add another attack vector.
We could consider having a --untrusted CLI option that would disable the ERB preprocessing and the include options in the config. I don't know if that's sufficient. For example I imagine that existing cops are ok, but I'm not familiar with most of them, and it is imaginable to have a vulnerable one. An example would be a cop that uses the config to compile a NodePattern, and NodePattern allows arbitrary code execution e.g. #eval('any code here').
Still, I imagine that the need for this would be extremely limited; I'm not sure what's the point of running rubocop on code you don't trust...
Still, I imagine that the need for this would be extremely limited; I'm not sure what's the point of running rubocop on code you don't trust...
Exactly. After all, the configuration is transparent and everyone can inspect it. Plus, I imagine you'd be using RuboCop only on projects that you actually work on.
Thanks for your responses @marcandre and @bbatsov.
Yep, that's fair enough. Obviously there is always going to be trust involved in any code you run. I was just thinking more from the angle of whether it opened up any hidden or unexpected routes in for untrusted coded to be executed, but I don't think so, so I'll close this issue now 馃憤.