add ParserConfiguration#setParsers to blacklist

[meiswjn]

Add ParserConfiguration#setParsers to blacklist. This function allows to run scripts in the agent-context without further approval by adding them as parsers in the global configuration
-> Privilege Escalation

Testing done

Submitter checklist

Preview Give feedback

1. Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
2. Ensure that the pull request title represents the desired changelog entry
3. Please describe what you did
4. Link to relevant issues in GitHub or Jira
5. Link to relevant pull requests, esp. upstream and downstream changes
6. Ensure you have provided tests - that demonstrates feature works or fixes the issue

[meiswjn]

@uhafner I thought that this might make sense

[jglick]

Fine I guess, though oddly specific. What would have made you think this method would be safe to approve to begin with?

There are many thousands of signatures possible in the Java Platform and Jenkins core and various Jenkins plugins, many of which would be security risks. Admins really should never approve anything unless they are Java developers with Jenkins expertise who have studied the method in detail and concluded that it could not be used maliciously (and submitted a PR to this repo to add it to the default whitelist).

The blacklist is intended to capture a handful of signatures which are both especially dangerous, and seem like plausible candidates for approval that an admin might mindlessly approve otherwise. For example GroovyObject.setProperty might appear as a rejected signature if you try to use reflection-heavy idioms in a sandbox, and if you know nothing about Groovy internals this might sound unremarkable, but in fact it would open up a giant security hole to approve it.

Is this ParserConfiguration.setParsers something that users would commonly attempt to include in a Jenkinsfile or other sandboxed script?

[meiswjn]

@jglick Thanks for your reply!

I think it should be part of this list because the plugin is used pretty often and using this function is documented here:
https://github.com/jenkinsci/warnings-ng-plugin/blob/master/doc/Documentation.md#creating-a-groovy-parser-programmatically

This may lead people to use this function.

[jglick]

can also be created using a Groovy script from within a pipeline

Ah, that is not good advice!

https://github.com/jenkinsci/script-security-plugin/pull/533/checks?check_run_id=17600899807 is because plugin-supplied signatures cannot be validated in a unit test here. They must be manually verified, then explicitly suppressed from the test as known to be impossible to validate.

[dwnusbaum]

This doesn't make sense to me. In jenkinsci/warnings-ng-plugin#1599 you added addParser and deleteParser methods which in combination have effectively the same behavior as setParsers, so why would we only blacklist the old method?