Cleaned up version of #14 #20
Conversation
…ded xalan implementation.
Add controlled instantiation constructor utility.
Remove missed copyright notices.
Add remote classloading test harness.
Add ability to provide a custom deserializer (needed for setting up the faces context)
…s are called (to fix the fileupload test and also to prevent exploiting yourself, also may be useful for finalizer based gadgets)
…ring which seemingly is different across JDK versions.
|
I'll have to take a closer look, but so far this looks great. Thanks a ton for putting in the extra work. Regarding the licenses: AFAIK it should just inherit the license of the project as a whole as long as there's no other licenses (or "All rights reserved") attached. Make sure your name is somewhere in any code you want to be credited with (gadgets/chains and/or exploits). Regarding the maven profile stuff: This is probably as good as it will get without a larger overhaul of how this is handled (as per #10), which is at the top of my list to sort out ASAP. Suggestions definitely welcome as usual. We should also make sure that any exploitable stuff has been reported to the project team before we release it here, and ideally reference a CVE in the exploit code if one exists. The test stuff you added actually looks great and is very similar to what I had in mind. I'll probably have a few questions/comments on the commits in the PR, but other than that this looks great. Thanks again. |
| @@ -0,0 +1,17 @@ | |||
| /** | |||
| * © 2016 AgNO3 Gmbh & Co. KG | |||
| * All right reserved. | |||
There was a problem hiding this comment.
Looks like one more slipped in ;-)
| * @author mbechler | ||
| * | ||
| */ | ||
| public class JenkinsCLI { |
There was a problem hiding this comment.
A description of how this works would be ideal here, especially if/how it interoperates with other ysoserial components. Is this part of CVE-2016-0788 or something separate?
|
Some short descriptions/notes on how the new |
|
Added some docs for the tooling. That exploit package isn't new, is it? ;) Figured that would be the correct place for tooling delivering playloads. With regards to JBoss/Wildfly: |
|
/cc @frohoff Here is a POC that separate each gadget in modules and would allow simple libraries isolation. Gradle will bring two main advantages to the projet
The POC only illustrate the intended structure and packaging. Some code would be needed to dynamically Let me know if you have questions. |
Add exploit and test code for JRMP reverse connect remote classloading.
|
Thanks again for the contribution and sorry it took so long. Going to try to accept a couple other PRs and do some cleanup before releasing. |
|
Seeing some intermittent flakiness with the PayloadsTest for JRMPClient failing intermittently and was hoping you could take a look if/when you get a chance. It failed a couples times for me locally but now it seems to be passing consistently, though it's still failing on travis-ci intermittently. Race condition? |
|
So far haven't been able to reproduce locally. One potential issue I can think of is that, depending on test execution order, the java.rmi.server.useCodebaseOnly property (currently set in Gadgets) is not always set before sun.rmi.server.MarshalInputStream is loaded. Would probably be better to set this directly on the test VM in the pom (also it's not needed otherwise). |
Took the time and cleaned that stuff up quite a bit.
With regards to the issues raised
With regards to #10, maybe an solution could also allow doing that switch at runtime and bundling multiple alternatives.
I'd probably go with the reflection based approach - in cases where it turns out to be necessary - (like I did in the hibernate payload) as I don't think that build time conflicts will be actually that common and a multi module variant might lead to some duplication.