In order to answer your question we have to qualify it. What is your definition within OFBiz of a deserialization attack. Perhaps give an example within this context of exactly what happens and how notsoserial prevents it. Which classes are you worried about as a vulnerability?
On Thursday, 8 September 2016, Jacques Le Roux <[email protected]> wrote: > It's no only about RMI, deserialization driven attacks can be done on > vulnerable classes. > > I think by exposing notsoserial (ie by creating the deserialize-trace.txt > and is-deserialized.txt files in tools\security\notsoserial) we offer a > good chance to users to we warned about the possible risks of > deserialization driven attacks. > > It's else difficult for inexperienced users in the security domain to > understand they are at risk and how to cope with it. This is actually the > purpose of the tools\security\notsoserial folder and its content. > > I ask you the same question than I asked to Jacopo: "How do you expect to > warn users about deserialization driven attacks?" > > Jacques > > > Le 08/09/2016 à 12:12, Taher Alkhateeb a écrit : > >> I have a question. How many "naive" users will default to using RMI with >> OFBiz? >> >> I think it was agreed long ago that RMI is a bad idea, and things like >> DCOM, CORBA and others died for a good reason. If someone is introducing >> RMI, they should handle the serialization vulnerabilities according to >> their own implementation, it's a choice. I really don't see a big need for >> this to be integrated into OFBiz OOTB. Even if you expose notsoserial, >> people still need to understand how it works and what to put into the >> configured text files. In fact, the knowledge needed to execute >> notsoserial >> correctly is rather high because you need to know which Java files are >> serializable and then which one of those are exposed in your >> implementation. >> >> So I recommend making this just an optional feature with good >> documentation >> in the Wiki where people can use it if they choose to adopt RMI, and we >> get >> this Jar out of the framework. >> >> On Thu, Sep 8, 2016 at 1:04 PM, Jacques Le Roux < >> [email protected]> wrote: >> >> Jacopo, >>> >>> I agree about releasing more often. Then we need to prepare things >>> better. >>> Just few words, I have no ideas how to yet. >>> >>> You suggest "to implement the best solution". As I said below I see only >>> 2. I don't expect Kantega will take the burden of pushing their jar to >>> jcenter, even less on each modification, even if I now expect very few, >>> if >>> any. They even did not care to answer me! >>> >>> I don't like much the idea of maintaining a fork, who would do it? I >>> prefer to automate it, and Gradle with JitPackIt can. My last proposition >>> (answer to Taher) resolves the notsoserial problem. >>> >>> If we remove the jar and all the rest, I fear the notsoserial effort will >>> be definitely thrown away, exposing our "naive" users at the risk of >>> using >>> RMI or a vulnerable external classes. >>> >>> BTW, when you say "We could always bundle it in another release soon" do >>> you expect to freeze and release R16 very soon? >>> >>> Jacques >>> >>> >>> >>> Le 08/09/2016 à 08:47, Jacopo Cappellato a écrit : >>> >>> I would feel more comfortable in releasing without it, and then work on >>>> the >>>> proposed solutions with more time in order to implement the best >>>> solution. >>>> We could always bundle it in another release soon: in fact with all the >>>> activity in the project, we should consider releasing more often. >>>> >>>> Jacopo >>>> >>>> >>>> >>>> On Thu, Sep 8, 2016 at 8:23 AM, Jacques Le Roux < >>>> [email protected]> wrote: >>>> >>>> OK wait! I think we skipped a step: access the jar from an accessible >>>> >>>>> repo. >>>>> >>>>> I see 2 solutions: >>>>> >>>>> 1. Push ourselves the notsoserial jar in jcenter => updating a fork now >>>>> and then, though notsoserial will not need much changes now >>>>> 2. Use https://jitpack.io/ >>>>> >>>>> I prefer 2, though I have still to >>>>> >>>>> * resolve the notsoserial.jar path in my hasty proposition below >>>>> * use|master-SNAPSHOT| instead of last hash (to not break on >>>>> changes) >>>>> which may need to refresh dependencies (did not investigate yet: >>>>> https://jitpack.io/docs/#snapshots) >>>>> >>>>> Index: build.gradle >>>>> =================================================================== >>>>> --- build.gradle (revision 1759557) >>>>> +++ build.gradle (working copy) >>>>> @@ -32,7 +32,7 @@ >>>>> >>>>> // java settings >>>>> def jvmArguments = ['-Xms128M', '-Xmx1024M', >>>>> - "-javaagent:${rootDir}/tools/security/notsoserial/notsoseria >>>>> l-1.0-SNAPSHOT.jar", >>>>> + "-javaagent:C:/Users/Jacques/.gradle/caches/modules-2/files- >>>>> 2.1/com.github.kantega/notsoserial/f2baaaa/3646e12f5ce4713f9 >>>>> ad2aa027e3fec81097fcd93/notsoserial-f2baaaa.jar", >>>>> "-Dnotsoserial.whitelist=${rootDir}/tools/security/notsoseri >>>>> al/empty.txt", >>>>> "-Dnotsoserial.dryrun=${rootDir}/tools/security/notsoserial/ >>>>> is-deserialized.txt", >>>>> "-Dnotsoserial.trace=${rootDir}/tools/security/notsoserial/ >>>>> deserialize-trace.txt"] >>>>> @@ -52,6 +52,7 @@ >>>>> allprojects { >>>>> repositories{ >>>>> jcenter() >>>>> + maven { url "https://jitpack.io"; } >>>>> } >>>>> } >>>>> >>>>> @@ -119,6 +120,7 @@ >>>>> compile 'org.zapodot:jackson-databind-java-optional:2.4.2' >>>>> compile 'oro:oro:2.0.8' >>>>> compile 'wsdl4j:wsdl4j:1.6.2' >>>>> + compile 'com.github.kantega:notsoserial:f2baaaa' >>>>> >>>>> // general framework runtime libs >>>>> runtime 'de.odysseus.juel:juel-spi:2.2.7' >>>>> >>>>> I think you get the idea, it works w/o any other modifications, what to >>>>> you think? >>>>> >>>>> Jacques >>>>> >>>>> >>>>> >>>>> Le 07/09/2016 à 22:37, Jacques Le Roux a écrit : >>>>> >>>>> OK, since we have no issues OOTB that can be done. >>>>> >>>>>> But IMO documenting the whole thing in our nososerial readme.txt is >>>>>> not >>>>>> enough. We need to make that more prominent. Not sure how yet... >>>>>> >>>>>> Jacques >>>>>> >>>>>> >>>>>> Le 07/09/2016 à 20:09, Taher Alkhateeb a écrit : >>>>>> >>>>>> Scratch that, actually only the -D arguments are ignored, we must >>>>>> remove >>>>>> >>>>>>> the -javaagent argument because it's not a classpath argument and >>>>>>> would >>>>>>> crash the VM >>>>>>> >>>>>>> But for consistency's sake, let's remove them all for now. So simply >>>>>>> we >>>>>>> apply: >>>>>>> >>>>>>> Index: build.gradle >>>>>>> =================================================================== >>>>>>> --- build.gradle (revision 1759596) >>>>>>> +++ build.gradle (working copy) >>>>>>> @@ -31,11 +31,7 @@ >>>>>>> ext.os = System.getProperty('os.name').toLowerCase() >>>>>>> >>>>>>> // java settings >>>>>>> -def jvmArguments = ['-Xms128M', '-Xmx1024M', >>>>>>> - >>>>>>> "-javaagent:${rootDir}/tools/security/notsoserial/notsoseria >>>>>>> l-1.0-SNAPSHOT.jar", >>>>>>> - >>>>>>> "-Dnotsoserial.whitelist=${rootDir}/tools/security/notsoseri >>>>>>> al/empty.txt", >>>>>>> - >>>>>>> "-Dnotsoserial.dryrun=${rootDir}/tools/security/notsoserial/ >>>>>>> is-deserialized.txt", >>>>>>> - >>>>>>> "-Dnotsoserial.trace=${rootDir}/tools/security/notsoserial/ >>>>>>> deserialize-trace.txt"] >>>>>>> +def jvmArguments = ['-Xms128M', '-Xmx1024M'] >>>>>>> ext.ofbizMainClass = 'org.apache.ofbiz.base.start.Start' >>>>>>> javadoc.failOnError = false >>>>>>> sourceCompatibility = '1.8' >>>>>>> >>>>>>> On Wed, Sep 7, 2016 at 9:04 PM, Jacques Le Roux < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>> OK Cool, if the JVM arguments are simply ignored, then I will proceed >>>>>>> >>>>>>> with >>>>>>>> an addition in the readme and remove the jar, simple >>>>>>>> >>>>>>>> Jacques >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Le 07/09/2016 à 17:16, Jacopo Cappellato a écrit : >>>>>>>> >>>>>>>> Thank you Jacques and Taher. >>>>>>>> >>>>>>>> So it seems we can move on and temporarily remove the jar. >>>>>>>>> >>>>>>>>> Jacopo >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Sep 7, 2016 at 5:11 PM, Taher Alkhateeb < >>>>>>>>> [email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi Jacques, >>>>>>>>> >>>>>>>>> First of all the ofbizSecure task is gone instead everything calls >>>>>>>>> >>>>>>>>>> the >>>>>>>>>> correct jvm arguments by default to fetch notsoserial. >>>>>>>>>> >>>>>>>>>> The work to remove notsoserial is almost nothing. You just to >>>>>>>>>> remove a >>>>>>>>>> few >>>>>>>>>> jvm args and that's it. Even if you don't remove the jvm args >>>>>>>>>> nothing >>>>>>>>>> happens because it will just ignore it as missing from the >>>>>>>>>> classpath. >>>>>>>>>> >>>>>>>>>> Taher Alkhateeb >>>>>>>>>> >>>>>>>>>> On Sep 7, 2016 5:48 PM, "Jacques Le Roux" < >>>>>>>>>> [email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Huho, I was too fast on this. Currently the Gradle "ofbizSecure" >>>>>>>>>> tasks >>>>>>>>>> >>>>>>>>>> depends on the notsoserial-1.0-SNAPSHOT.jar >>>>>>>>>> >>>>>>>>>>> So this would need more work and w/o answers from them I suspect >>>>>>>>>>> they >>>>>>>>>>> >>>>>>>>>>> will >>>>>>>>>>> >>>>>>>>>>> not publish the jar. >>>>>>>>>> >>>>>>>>>> Now it's a serious security but not OOTB. So I see 2 >>>>>>>>>>> possibilities. >>>>>>>>>>> >>>>>>>>>>> 1. Ask the ASF for a derogation (after all it's a Java issue not >>>>>>>>>>> an >>>>>>>>>>> OFBiz >>>>>>>>>>> one) >>>>>>>>>>> 2. Do what I said before AND change the Gradle "ofbizSecure" >>>>>>>>>>> tasks >>>>>>>>>>> >>>>>>>>>>> Opinions? >>>>>>>>>>> >>>>>>>>>>> Jacques >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Le 07/09/2016 à 14:01, Jacques Le Roux a écrit : >>>>>>>>>>> >>>>>>>>>>> Yes I see no problems with that. I just need to add directions >>>>>>>>>>> for >>>>>>>>>>> users >>>>>>>>>>> >>>>>>>>>>> before. I'll then remove the jars... very soon... >>>>>>>>>>> >>>>>>>>>>>> Jacques >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Le 07/09/2016 à 13:09, Jacopo Cappellato a écrit : >>>>>>>>>>>> >>>>>>>>>>>> Jacques, any news from notsoserial? >>>>>>>>>>>> >>>>>>>>>>>> If not, I think we can proceed by (temporarily) removing the >>>>>>>>>>>> jars >>>>>>>>>>>> >>>>>>>>>>>>> until >>>>>>>>>>>>> they will publish the jar. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> >>>>>>>>>>>>> Jacopo >>>>>>>>>>>>> >>>>>>>>>>>>> On Sat, Aug 20, 2016 at 11:12 AM, Jacques Le Roux < >>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Yes that's what I proposed also, I will try that before the >>>>>>>>>>>>> worse >>>>>>>>>>>>> >>>>>>>>>>>>> solution >>>>>>>>>>>>> >>>>>>>>>>>>> as Taher called them, would you help? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Jacques >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Le 20/08/2016 à 08:32, Pierre Smits a écrit : >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Jacques, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Why not try to convince the people behind notsoserial to have >>>>>>>>>>>>>> them >>>>>>>>>>>>>> >>>>>>>>>>>>>> push >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> the >>>>>>>>>>>>>> >>>>>>>>>>>>> library to maven central and/or jpublish? In stead of this >>>>>>>>>>>> community >>>>>>>>>>>> >>>>>>>>>>>> doing >>>>>>>>>>>>> >>>>>>>>>>>>>> the work? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Pierre Smits >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ORRTIZ.COM <http://www.orrtiz.com> >>>>>>>>>>>>>>> OFBiz based solutions & services >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> OFBiz Extensions Marketplace >>>>>>>>>>>>>>> http://oem.ofbizci.net/oci-2/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >
