Details
-
Bug
-
Status: Resolved (View Workflow)
-
Major
-
Resolution: Fixed
Description
Remoting does not check whether the cached file's checksum matches before using it[1]. User with build permission can use this to inject new classes or different class implementations/resource content manipulating the cache and waiting for agent to restart.
This can be used for denial of service attack against nodes as they will connect to Jenkins correctly but refuse to fulfill remoting requests with strange exceptions.
More sophisticated attack can trick agent to execute custom code and therefore produce incorrect results, try to abuse existing {{SlaveToMasterCallable}}s or generate malicious files/reports to be published on masters.
There do not seem to be a way to load those classes to master JVM or send new callable there if slave2master security is on, AFAIK.
Attachments
Issue Links
- links to
Code changed in jenkins
User: Oliver Gondža
Path:
src/main/java/hudson/remoting/Checksum.java
src/main/java/hudson/remoting/FileSystemJarCache.java
src/main/java/hudson/remoting/JarLoaderImpl.java
src/test/java/hudson/remoting/ChecksumTest.java
src/test/java/hudson/remoting/FileSystemJarCacheTest.java
http://jenkins-ci.org/commit/remoting/cdd5bce5725d338b129c63c22b8e6a132e77865c
Log:
JENKINS-39547- Corrupt jar cache (#130)We need a way to calculate reliable checksums and as implemented it causes
temporary write-then-move files to have checksums cached never to use used.
This moves checksum caching to FileSystemJarCache.