security question re: recent Jenkins advisory
attritionorg opened this issue · comments
Regarding the recent Jenkins advisory: https://jenkins.io/security/advisory/2018-12-05/
"Jenkins uses the Stapler web framework for HTTP request handling. Stapler’s basic premise is that it uses reflective access to code elements matching its naming conventions. For example, any public method whose name starts with get, and that has a String, int, long, or no argument can be invoked this way on objects that are reachable through these means. As these naming conventions closely match common code patterns in Java, accessing crafted URLs could invoke methods never intended to be invoked this way."
Is this a fundamental issue in Stapler, or is this specific to Jenkins implementation? Curious if other applications should be concerned about this. Thanks!
I came here with the same question. This appears to be related to this commit:
28e8eba
It would seem there is a vulnerability in stapler that will be fixed in 1.256 once it is published. Right now the latest version in Maven is 1.255.
Perhaps @daniel-beck or @Wadeck can add some info as the authors of that commit?
Is this a fundamental issue in Stapler, or is this specific to Jenkins implementation? Curious if other applications should be concerned about this. Thanks!
This is actually a good question, and I'm not quite sure of the answer myself.
It's a fundamental property in Stapler's use of naming convention for its routing, and carefully written applications can just not expose public fields or methods matching the conventional getWhatever name on objects they make reachable through routing unless they're intended to be routed, and thereby largely sidestep the problem, with the single exception of Object#getClass() and anything reachable transitively through that. So it really depends on the application whether it uses these (very common) code patterns that would allow this to be exploited. This is the case in Jenkins, and it needed additional protections in the form of implementations of the newly added SPI.
If you're using Stapler as your framework, I recommend setting the org.kohsuke.stapler.Dispatcher.TRACE property to true, and look at HTTP response headers, as well as the output of the 404 error page for URLs that don't exist to understand what is considered routable by Stapler, and follow that transitively to interesting places to understand whether your application is impacted.
FWIW we searched a while back for users of Stapler as a web framework and came up empty, and between this and not getting any responses to other Stapler-related security fixes we just assumed there was nobody else using it (besides Hudson, but that project appeared dormant last I checked).
It would seem there is a vulnerability in stapler that will be fixed in 1.256 once it is published.
Security updates of Stapler are not published to repo1, as the Jenkins security process basically requires them to be deployed to repo.jenkins-ci.org. Only the next regular update will be published as usual. In fact, every version you see tagged in this repo but not on repo1 will have been created to fix a security vulnerability in Jenkins, and may well fix a security vulnerability in Stapler itself.
We could mirror security releases of components like Stapler to OSSRH so they get into Central, though it would take a little more effort.
FWIW if I were dealing with a fairly small web application, ideally without the extension model of Jenkins, I'd implement the SPI so it required all getters, fields, and web methods to be explicitly annotated with a new annotation making it explicit. This should be a few dozen lines on the SPI implementations in your application at most, plus the new annotation on all getters, fields, and web methods used.
The size of the corresponding patch in Jenkins is so large because we needed to support an extensive ecosystem of plugins that needed to continue to work.
Considering this answered. @attritionorg @rschultheis Please ping me in case of further questions.
All good @daniel-beck, thank you and your team for responding so quickly to this mess!