-
-
Notifications
You must be signed in to change notification settings - Fork 8.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[JENKINS-47736] Switch Remoting/XStream blacklist to a whitelist #3120
Conversation
Seems to have had some snapshot confusion with |
…ome an IOException caught by Descriptor.save.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seems ok - some comments left inline
LOGGER.log(Level.FINE, "permitting {0} since it is an array", name); | ||
return false; | ||
} | ||
if (Throwable.class.isAssignableFrom(c)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am sure throwables
used to be blocked? was there not a good reason to block them - has this changed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not recall any case of Throwable
s being (deliberately) blocked. In fact I recall some suggestion to allow org.codehaus.groovy.runtime.powerassert.PowerAssertionError
and the like through despite their whole package subtree being in the standard blacklist.
I tried for a while to whitelist individual Throwable
s but found it completely impractical: every miscellaneous kind of exception that might get thrown in the course of a typical Remoting call wound up having to be added. I think this was in UserResponse
, despite the existence of ProxyException
, though it has been a while.
Also ErrorAction
tries to directly record any Throwable
terminating a Pipeline step, only using ProxyException
for problematic classes.
In practice Throwable
s tend to just have a message and stack trace and be unlikely to be a vector for exploits. We can always continue to blacklist any individual class we suspect of being problematic.
}); | ||
} | ||
|
||
private static final Pattern CLASSES_JAR = Pattern.compile("(file:/.+/)WEB-INF/lib/classes[.]jar"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NIT: code conventions is static fields are declared before non static fields.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted to keep this close to its sole usage.
/** | ||
* Determine whether a class should be permitted by {@link ClassFilter#isBlacklisted(Class)} of {@link ClassFilter#DEFAULT}. | ||
* @param c the class | ||
* @return true to permit it when it would normally be rejected (for example due to having a custom serialization method and being from a third-party library); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NIT: Boolean.TRUE not true. etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, sure, but autoboxing makes that pretty transparent anyway.
org.acegisecurity.userdetails.User | ||
org.apache.commons.fileupload.disk.DiskFileItem | ||
org.apache.commons.fileupload.util.FileItemHeadersImpl | ||
org.eclipse.jgit.lib.ObjectId |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why is this defined here and not in the git-client plugin?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could be, of course; ditto a few others classes coming from job-dsl
, maven-plugin
, and workflow-support
. Logistically I just wanted to make sure I was producing a jenkins.war
that did not introduce regressions to popular plugins, without requiring people to apply recent plugin updates. TBD.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My proposal would be to exclude whitelist to a plugin and to mark it as a detached one. In such case we will be able to quickly deliver patches to whitelists if something goes south.... If XStream manages to startup from config.xml... So I am +1 for keeping what we have here
@@ -148,15 +148,15 @@ private String jsonRequest(JenkinsRule.WebClient wc, String path) throws Excepti | |||
|
|||
private static final class CustomUpdateSite extends UpdateSite { | |||
|
|||
private final TemporaryFolder tmpdir; | |||
private final File tmpdir; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
where does this now get cleaned up?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The @Rule
at the top of the class.
@Test | ||
public void whitelistSanity() throws Exception { | ||
try (InputStream is = ClassFilterImpl.class.getResourceAsStream("whitelisted-classes.txt")) { | ||
List<String> lines = IOUtils.readLines(is); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
readLines(InputStream)
uses the platform default charset and not UTF-8
. so this test will be platform dependant
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, will fix.
try { | ||
Class.forName(line); | ||
} catch (ClassNotFoundException x) { | ||
System.err.println("skipping checks of unknown class " + line); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this code seems to be just wasting cycles - please add an assert if you expect all classes to be covered, or move this outside of a test (if you want to manually check)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The whole test case takes about 1s, and this line helps identify classes contributed by plugins (as in discussion above).
@@ -254,6 +254,7 @@ public void checkRoles(RoleChecker checker) throws SecurityException { | |||
} | |||
}); | |||
} catch (Exception ex) { | |||
ex.printStackTrace(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks like this will dump out stack traces even for a successful test (which is bad) as stack traces for OK tests look scary when running and set of triggers in human brains.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally agree. In this case it is a security test and if you are running it interactively (i.e., -Dtest=…
) you should be aware that an exception is wanted here. I specifically added this line because I had trouble diagnosing a problem in the test previously, and this made things much clearer.
…nkinsci#3120 which I have asked for help from @stephenc diagnosing.
…e for purposes of whitelisting. <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-jar-plugin</artifactId> <configuration> <archive> <manifestEntries> <Jenkins-ClassFilter-Whitelisted>true</Jenkins-ClassFilter-Whitelisted> </manifestEntries> </archive> </configuration> </plugin>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I'd guess that's it for this weekly
@@ -76,6 +80,11 @@ public static void register() { | |||
return; | |||
} | |||
ClassFilter.setDefault(new ClassFilterImpl()); | |||
if (SUPPRESS_ALL) { | |||
LOGGER.warning("All class filtering suppressed. Your Jenkins installation is at risk from known attacks. See https://jenkins.io/redirect/class-filter/"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That blog post does not describe the blacklist concerns, but we can update the link later
Thanks @oleg-nenashev for mentioning us. To confirm, the blacklist/whitelist only applies to the following scenarios:
Right? |
@ArieShout Yes, it's correct. You can find some guidelines here: https://jenkins.io/blog/2018/01/13/jep-200/#for-plugin-developers and |
Sorry, correct DEV ML link: https://groups.google.com/forum/#!topic/jenkinsci-dev/EALjDtS4riU |
We have applied the fix to the Azure plugins (azure-vm-agents specifically) and It seems the Thanks, |
* Slave.JnlpJar.getURL did not work in some modes when core had a snapshot dependency on Remoting. * Starting to implement Channel.Listener.read/write. * Now obtaining response timing statistics. * For now, avoiding timestamped snapshots, as it caused problems for #3120 which I have asked for help from @stephenc diagnosing. * Simplified logging a bit. * onResponse * hudson.FilePath$Mkdirs is a lot more readable than hudson.FilePath$13. * Specific snapshot. * onJar * LoggingChannelListener * remoting.version=3.17 * Making a few test assertions more lenient to adapt to jenkinsci/remoting#247.
java.lang.reflect.Proxy | ||
java.net.URI | ||
java.net.URL | ||
java.security.KeyRep |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you remember what the use case for commit e876849 was?
Sorry, no. Probably there was a test failure somewhere, in which case there is no need to worry (it would show up if this is really a problem on 17).
XStream trying to serialize/deserialize these types
More likely in Remoting.
See JENKINS-47736 and JEP 200.
Downstream of jenkinsci/remoting#208.
Proposed changelog entries
@reviewbybees @jenkinsci/code-reviewers