Taking a decision on remaining Jars in OFBiz
Locked
1234
1234
Re: Taking a decision on remaining Jars in OFBiz
 
Administrator
|
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 < > [hidden email]> 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 < >>> [hidden email]> 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 < >>>>>> [hidden email]> 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 < >>>>>>>> [hidden email]> >>>>>>>> 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" < >>>>>>>>> [hidden email]> >>>>>>>>> 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 < >>>>>>>>>>>> [hidden email]> 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/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> |
|
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 <[hidden email]> 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 < >> [hidden email]> 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 < >>>> [hidden email]> 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 < >>>>>>> [hidden email]> 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 < >>>>>>>>> [hidden email]> >>>>>>>>> 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" < >>>>>>>>>> [hidden email]> >>>>>>>>>> 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 < >>>>>>>>>>>>> [hidden email]> 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/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > |
Re: Taking a decision on remaining Jars in OFBiz
|
In reply to this post by Jacques Le Roux
On Thu, Sep 8, 2016 at 2:54 PM, Jacques Le Roux <
[hidden email]> wrote: > ... > How do you expect to warn users about deserialization driven attacks? I > mean people can have a such risk w/o using RMI, deserialization driven > attacks are not only about RMI. In my opinion a message in the OFBiz README file or in our download page would be more effective that the current content of tools/security/notsoserial. > > >> BTW, when you say "We could always bundle it in another release soon" do >>> you expect to freeze and release R16 very soon? >>> >> I am sorry but I don't get your question. >> > > Simpler question: when would expect to bundle it? > Maybe simpler, but still not very clear: anyway, if you are asking about my expectations for the creation of the release branch release16.09 and for its subsequent release, then they are based on the output of the thread with title "Creating a new release branch in preparation for the new release": please refer to it. But in short I hope to create the branch by the end of this week and then start the thread about how/when do the release. Jacopo > > Jacques > > >> Jacopo >> >> > |
Re: Taking a decision on remaining Jars in OFBiz
|
Administrator
|
In reply to this post by Jacopo Cappellato-5
Le 08/09/2016 à 07:17, Jacopo Cappellato a écrit :
> An important aspect of the discussion at #2 would be to research how other > ASF projects, based on Java, are doing about it: we could get some > inspiration and ideas from them. This is the only thread I'm aware of http://markmail.org/message/5g76algian2lhj2i It seems not much (euphemism) was done after the discussion. But the topic is still there, hackers have all their time, and they will bite again... Jacques |
Re: Taking a decision on remaining Jars in OFBiz
|
|
On Thu, Sep 8, 2016 at 5:01 PM, Jacques Le Roux <
[hidden email]> wrote: > But the topic is still there, hackers have all their time, and they will > bite again... Well, the above is too generic statement and I would prefer you to describe about specific attacks and weak points in OFBiz that need to be secured by notsoserial; and provide other examples of Java frameworks at the ASF and how they have dealt with them. Jacopo |
Re: Taking a decision on remaining Jars in OFBiz
|
Administrator
|
Le 08/09/2016 à 17:23, Jacopo Cappellato a écrit :
> On Thu, Sep 8, 2016 at 5:01 PM, Jacques Le Roux < > [hidden email]> wrote: > >> But the topic is still there, hackers have all their time, and they will >> bite again... > > Well, the above is too generic statement and I would prefer you to describe > about specific attacks and weak points in OFBiz that need to be secured by > notsoserial; and provide other examples of Java frameworks at the ASF and > how they have dealt with them. > > Jacopo > about that I think I already clearly explained the situation about OFBiz. https://cwiki.apache.org/confluence/display/OFBIZ/The+infamous+Java+serialization+vulnerability What can do notsoserial, if you use it rightly, is a bit like an antivirus, it protects you by advance. The principal difference is it knows exactly what to protect you against and it does it surely. Developers should always be on their guards about this hazard, why not using notsoserial? Jacques |
Re: Taking a decision on remaining Jars in OFBiz
|
Administrator
|
In reply to this post by taher
> Which classes are you worried about as a vulnerability?
You certainly know that we have no serialization vulnerabilities OOTB. Most of the external classes which were still a problem for us one year ago have been fixed. I documented that at https://cwiki.apache.org/confluence/display/OFBIZ/The+infamous+Java+serialization+vulnerability But still 6 months later: http://www.pcworld.com/article/3026678/paypal-is-the-latest-victim-of-java-deserialization-bugs-in-web-apps.html So it's only about warning users about deserialization attacks. They are maybe not totally aware of the issue. How to warn them efficiently? It seems to me that my proposition does that. > Perhaps give an example within this context of exactly what happens and how notsoserial prevents it. The article about Paypal above states "Security researchers warned at the time that thousands of Java-based Web applications, *including custom-made enterprise ones*, are likely vulnerable to this attack" "[snip] it's likely that this type of vulnerability exists in other libraries as well, waiting to be discovered." This is not FUD (PayPal!) and it's only 6 months old About RMI, JMX is using it http://engineering.pivotal.io/post/java-deserialization-jmx/ and if you want to dynamically monitor things, you will use JMX, won't you? About JNDI http://zerothoughts.tumblr.com/post/137831000514/spring-framework-deserialization-rce OK it's not about OFBiz, but those 2 are less than 6 months old. Who can think that the problems is definitely resolved? It's not, it can't be. So no, I have no examples to give you. But one thing I can say, is with notsoserial running in secure mode in the background you will be notified if any unexpected deserialization attempt happens. https://github.com/kantega/notsoserial#rejecting-deserialization-entirely I hope I have somehow answered your question. Can you answer mine? Also, I wonder why both you and Jacopo reject my proposed solution, any technical or other reasons? We decided to use notsoserial by default, I don't see why we should change now. I'd have a reassured mind if we committed my proposed change. I see no reasons to not do it. Jacques Le 08/09/2016 à 15:16, Taher Alkhateeb a écrit : > 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 <[hidden email]> > 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 < >>> [hidden email]> 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 < >>>>> [hidden email]> 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 < >>>>>>>> [hidden email]> 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 < >>>>>>>>>> [hidden email]> >>>>>>>>>> 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" < >>>>>>>>>>> [hidden email]> >>>>>>>>>>> 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 < >>>>>>>>>>>>>> [hidden email]> 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/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> |
Re: Taking a decision on remaining Jars in OFBiz
|
Administrator
|
In reply to this post by Jacopo Cappellato-5
Le 08/09/2016 à 15:24, Jacopo Cappellato a écrit :
> On Thu, Sep 8, 2016 at 2:54 PM, Jacques Le Roux < > [hidden email]> wrote: > >> ... >> How do you expect to warn users about deserialization driven attacks? I >> mean people can have a such risk w/o using RMI, deserialization driven >> attacks are not only about RMI. > > In my opinion a message in the OFBiz README file or in our download page > would be more effective that the current content of > tools/security/notsoserial. Why not explaining things better (how to, needs to be defined) in both OFBiz main README file (in root folder) and in our download page, while still using notsoserial with my proposition (no notsoserial jar bundled in the release, just compiled inline) > >> >>> BTW, when you say "We could always bundle it in another release soon" do >>>> you expect to freeze and release R16 very soon? >>>> >>> I am sorry but I don't get your question. >>> >> Simpler question: when would expect to bundle it? >> > Maybe simpler, but still not very clear: anyway, if you are asking about my > expectations for the creation of the release branch release16.09 and for > its subsequent release, then they are based on the output of the thread > with title "Creating a new release branch in preparation for the new > release": please refer to it. But in short I hope to create the branch by > the end of this week and then start the thread about how/when do the > release. Thanks, that indeed answers my question. Jacques > > Jacopo > > >> Jacques >> >> >>> Jacopo >>> >>> |
|
|
In reply to this post by Jacques Le Roux
In reply to your comments:
I did not see any point of the ones you mentioned specific to OFBiz. All that I saw is a reference to an article that PayPal was attacked and that using JMX and JNDI might get you exposed with nothing specific to our project and no concrete examples. You want to make a technical decision of having a library based on vague hypothetical grounds with references to some articles about dangers of Java deserialization. This is like saying I'm going to buy this lawn mower because it is great while you don't have any grass in your backyard! Also based on your feedback, the answer to your question "How do you expect to warn users about deserialization driven attacks?" is I don't! I try to avoid being repetitive but OFBiz suffers from overusing too many libraries. It is hardly a good reason to add more because MAYBE some users will develop software using some library that would expose THEIR system. Too hypothetical and does not treat all corner cases and definitely does not make the system more secure because anyone can simply ignore notsoserial, or might choose a different solution. Personally I would not use it because it does not even have a release and the code base is hardly maintained or touched, the proof of which is that the maintainer did not even reply to your email. So, in reference to your point "I wonder why both you and Jacopo reject my proposed solution, any technical or other reasons?" I will let Jacopo answer for his reasons, but mine are very simple. I think we should have less libraries, less bloat, less "stuff" in OFBiz because we have a problematic code base that needs a lot of pruning and refactoring. I think if you really want to focus on security then the _real work_ is in fixing code. Bad code is the biggest source of security problems, not environment or tools. To make our project more secure is to focus on the real critical issue... code! On Thu, Sep 8, 2016 at 8:48 PM, Jacques Le Roux < [hidden email]> wrote: > > Which classes are you worried about as a vulnerability? > > You certainly know that we have no serialization vulnerabilities OOTB. > Most of the external classes which were still a problem for us one year ago > have been fixed. > I documented that at https://cwiki.apache.org/confl > uence/display/OFBIZ/The+infamous+Java+serialization+vulnerability > > But still 6 months later: http://www.pcworld.com/article > /3026678/paypal-is-the-latest-victim-of-java-deserialization > -bugs-in-web-apps.html > So it's only about warning users about deserialization attacks. They are > maybe not totally aware of the issue. How to warn them efficiently? It > seems to me that my proposition does that. > > > Perhaps give an example within this context of exactly what happens and > how notsoserial prevents it. > The article about Paypal above states "Security researchers warned at the > time that thousands of Java-based Web applications, *including custom-made > enterprise ones*, are likely vulnerable to this attack" > "[snip] it's likely that this type of vulnerability exists in other > libraries as well, waiting to be discovered." > This is not FUD (PayPal!) and it's only 6 months old > > About RMI, JMX is using it http://engineering.pivotal.io/ > post/java-deserialization-jmx/ and if you want to dynamically monitor > things, you will use JMX, won't you? > About JNDI http://zerothoughts.tumblr.com/post/137831000514/spring-fram > ework-deserialization-rce > OK it's not about OFBiz, but those 2 are less than 6 months old. Who can > think that the problems is definitely resolved? It's not, it can't be. > > So no, I have no examples to give you. But one thing I can say, is with > notsoserial running in secure mode in the background you will be notified > if any unexpected deserialization attempt happens. > https://github.com/kantega/notsoserial#rejecting-deserialization-entirely > I hope I have somehow answered your question. Can you answer mine? > > Also, I wonder why both you and Jacopo reject my proposed solution, any > technical or other reasons? > > We decided to use notsoserial by default, I don't see why we should change > now. I'd have a reassured mind if we committed my proposed change. I see no > reasons to not do it. > > Jacques > > > Le 08/09/2016 à 15:16, Taher Alkhateeb a écrit : > >> 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 < >> [hidden email]> >> 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 < >>>> [hidden email]> 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 < >>>>>> [hidden email]> 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 < >>>>>>>>> [hidden email]> 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 < >>>>>>>>>>> [hidden email]> >>>>>>>>>>> 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" < >>>>>>>>>>>> [hidden email]> >>>>>>>>>>>> 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 < >>>>>>>>>>>>>>> [hidden email]> 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/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > |
Re: Taking a decision on remaining Jars in OFBiz
|
Administrator
|
OK At least I'd have try to convince you that proposing an OOTB solution to protect our users from dangers of Java deserialization is a good thing.
We can remove the whole thing, let's go Jacques Le 08/09/2016 à 21:37, Taher Alkhateeb a écrit : > In reply to your comments: > > I did not see any point of the ones you mentioned specific to OFBiz. All > that I saw is a reference to an article that PayPal was attacked and that > using JMX and JNDI might get you exposed with nothing specific to our > project and no concrete examples. You want to make a technical decision of > having a library based on vague hypothetical grounds with references to > some articles about dangers of Java deserialization. This is like saying > I'm going to buy this lawn mower because it is great while you don't have > any grass in your backyard! > > Also based on your feedback, the answer to your question "How do you expect > to warn users about deserialization driven attacks?" is I don't! I try to > avoid being repetitive but OFBiz suffers from overusing too many libraries. > It is hardly a good reason to add more because MAYBE some users will > develop software using some library that would expose THEIR system. Too > hypothetical and does not treat all corner cases and definitely does not > make the system more secure because anyone can simply ignore notsoserial, > or might choose a different solution. Personally I would not use it because > it does not even have a release and the code base is hardly maintained or > touched, the proof of which is that the maintainer did not even reply to > your email. > > So, in reference to your point "I wonder why both you and Jacopo reject my > proposed solution, any technical or other reasons?" I will let Jacopo > answer for his reasons, but mine are very simple. I think we should have > less libraries, less bloat, less "stuff" in OFBiz because we have a > problematic code base that needs a lot of pruning and refactoring. > > I think if you really want to focus on security then the _real work_ is in > fixing code. Bad code is the biggest source of security problems, not > environment or tools. To make our project more secure is to focus on the > real critical issue... code! > > > On Thu, Sep 8, 2016 at 8:48 PM, Jacques Le Roux < > [hidden email]> wrote: > >>> Which classes are you worried about as a vulnerability? >> You certainly know that we have no serialization vulnerabilities OOTB. >> Most of the external classes which were still a problem for us one year ago >> have been fixed. >> I documented that at https://cwiki.apache.org/confl >> uence/display/OFBIZ/The+infamous+Java+serialization+vulnerability >> >> But still 6 months later: http://www.pcworld.com/article >> /3026678/paypal-is-the-latest-victim-of-java-deserialization >> -bugs-in-web-apps.html >> So it's only about warning users about deserialization attacks. They are >> maybe not totally aware of the issue. How to warn them efficiently? It >> seems to me that my proposition does that. >> >>> Perhaps give an example within this context of exactly what happens and >> how notsoserial prevents it. >> The article about Paypal above states "Security researchers warned at the >> time that thousands of Java-based Web applications, *including custom-made >> enterprise ones*, are likely vulnerable to this attack" >> "[snip] it's likely that this type of vulnerability exists in other >> libraries as well, waiting to be discovered." >> This is not FUD (PayPal!) and it's only 6 months old >> >> About RMI, JMX is using it http://engineering.pivotal.io/ >> post/java-deserialization-jmx/ and if you want to dynamically monitor >> things, you will use JMX, won't you? >> About JNDI http://zerothoughts.tumblr.com/post/137831000514/spring-fram >> ework-deserialization-rce >> OK it's not about OFBiz, but those 2 are less than 6 months old. Who can >> think that the problems is definitely resolved? It's not, it can't be. >> >> So no, I have no examples to give you. But one thing I can say, is with >> notsoserial running in secure mode in the background you will be notified >> if any unexpected deserialization attempt happens. >> https://github.com/kantega/notsoserial#rejecting-deserialization-entirely >> I hope I have somehow answered your question. Can you answer mine? >> >> Also, I wonder why both you and Jacopo reject my proposed solution, any >> technical or other reasons? >> >> We decided to use notsoserial by default, I don't see why we should change >> now. I'd have a reassured mind if we committed my proposed change. I see no >> reasons to not do it. >> >> Jacques >> >> >> Le 08/09/2016 à 15:16, Taher Alkhateeb a écrit : >> >>> 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 < >>> [hidden email]> >>> 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 < >>>>> [hidden email]> 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 < >>>>>>> [hidden email]> 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 < >>>>>>>>>> [hidden email]> 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 < >>>>>>>>>>>> [hidden email]> >>>>>>>>>>>> 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" < >>>>>>>>>>>>> [hidden email]> >>>>>>>>>>>>> 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 < >>>>>>>>>>>>>>>> [hidden email]> 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/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> |
|
|
Yes I agree with you completely that we should provide solutions to help
our users in their security issues. The only difference in our views is "methodology". To me I think better documentation (wiki, JavaDoc, etc) and cleaning code is a better approach than introducing a library that people might or might not use and that does not have clear technical benefits laid out. Security is a big topic and there are many areas to improve. Security issues like deserialization, XSS, SQL injection and others usually reveal themselves in certain parts of the code under certain conditions within a certain context. So it is always the "details" that matter and why code is the absolute most important aspect of security. What's the use of having a firewall for example if the only open port has a vulnerability because of bad code? So .. a good approach in my opinion is to have a wiki page up which discusses among other things: - How to introduce new libraries - Explanation of java deserialization (and other security risks) and how to mitigate it. - Perhaps we can have a section on tools like notsoserial and others with some code snippets showing when and how to use and for what reasons. - best practices on securing ofbiz - and any thing related to security you think is useful In addition to that wiki page, we need to dig into the critical components of the code base and refactor it and clean it up. Good clean code goes hand-in-hand with secure code. So it is a win-win situation and the reason why I was pushing hard for code refactoring. WDYT? If you agree then we can work on a good well documented page all about security and get help from everyone to have good well documented material. Taher Alkhateeb On Sep 9, 2016 7:08 AM, "Jacques Le Roux" <[hidden email]> wrote: > OK At least I'd have try to convince you that proposing an OOTB solution > to protect our users from dangers of Java deserialization is a good thing. > We can remove the whole thing, let's go > > Jacques > > > Le 08/09/2016 à 21:37, Taher Alkhateeb a écrit : > >> In reply to your comments: >> >> I did not see any point of the ones you mentioned specific to OFBiz. All >> that I saw is a reference to an article that PayPal was attacked and that >> using JMX and JNDI might get you exposed with nothing specific to our >> project and no concrete examples. You want to make a technical decision of >> having a library based on vague hypothetical grounds with references to >> some articles about dangers of Java deserialization. This is like saying >> I'm going to buy this lawn mower because it is great while you don't have >> any grass in your backyard! >> >> Also based on your feedback, the answer to your question "How do you >> expect >> to warn users about deserialization driven attacks?" is I don't! I try to >> avoid being repetitive but OFBiz suffers from overusing too many >> libraries. >> It is hardly a good reason to add more because MAYBE some users will >> develop software using some library that would expose THEIR system. Too >> hypothetical and does not treat all corner cases and definitely does not >> make the system more secure because anyone can simply ignore notsoserial, >> or might choose a different solution. Personally I would not use it >> because >> it does not even have a release and the code base is hardly maintained or >> touched, the proof of which is that the maintainer did not even reply to >> your email. >> >> So, in reference to your point "I wonder why both you and Jacopo reject my >> proposed solution, any technical or other reasons?" I will let Jacopo >> answer for his reasons, but mine are very simple. I think we should have >> less libraries, less bloat, less "stuff" in OFBiz because we have a >> problematic code base that needs a lot of pruning and refactoring. >> >> I think if you really want to focus on security then the _real work_ is in >> fixing code. Bad code is the biggest source of security problems, not >> environment or tools. To make our project more secure is to focus on the >> real critical issue... code! >> >> >> On Thu, Sep 8, 2016 at 8:48 PM, Jacques Le Roux < >> [hidden email]> wrote: >> >> Which classes are you worried about as a vulnerability? >>>> >>> You certainly know that we have no serialization vulnerabilities OOTB. >>> Most of the external classes which were still a problem for us one year >>> ago >>> have been fixed. >>> I documented that at https://cwiki.apache.org/confl >>> uence/display/OFBIZ/The+infamous+Java+serialization+vulnerability >>> >>> But still 6 months later: http://www.pcworld.com/article >>> /3026678/paypal-is-the-latest-victim-of-java-deserialization >>> -bugs-in-web-apps.html >>> So it's only about warning users about deserialization attacks. They are >>> maybe not totally aware of the issue. How to warn them efficiently? It >>> seems to me that my proposition does that. >>> >>> Perhaps give an example within this context of exactly what happens and >>>> >>> how notsoserial prevents it. >>> The article about Paypal above states "Security researchers warned at the >>> time that thousands of Java-based Web applications, *including >>> custom-made >>> enterprise ones*, are likely vulnerable to this attack" >>> "[snip] it's likely that this type of vulnerability exists in other >>> libraries as well, waiting to be discovered." >>> This is not FUD (PayPal!) and it's only 6 months old >>> >>> About RMI, JMX is using it http://engineering.pivotal.io/ >>> post/java-deserialization-jmx/ and if you want to dynamically monitor >>> things, you will use JMX, won't you? >>> About JNDI http://zerothoughts.tumblr.com/post/137831000514/spring-fram >>> ework-deserialization-rce >>> OK it's not about OFBiz, but those 2 are less than 6 months old. Who can >>> think that the problems is definitely resolved? It's not, it can't be. >>> >>> So no, I have no examples to give you. But one thing I can say, is with >>> notsoserial running in secure mode in the background you will be notified >>> if any unexpected deserialization attempt happens. >>> https://github.com/kantega/notsoserial#rejecting-deserializa >>> tion-entirely >>> I hope I have somehow answered your question. Can you answer mine? >>> >>> Also, I wonder why both you and Jacopo reject my proposed solution, any >>> technical or other reasons? >>> >>> We decided to use notsoserial by default, I don't see why we should >>> change >>> now. I'd have a reassured mind if we committed my proposed change. I see >>> no >>> reasons to not do it. >>> >>> Jacques >>> >>> >>> Le 08/09/2016 à 15:16, Taher Alkhateeb a écrit : >>> >>> 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 < >>>> [hidden email]> >>>> 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 < >>>>>> [hidden email]> 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 < >>>>>>>> [hidden email]> 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 < >>>>>>>>>>> [hidden email]> 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 < >>>>>>>>>>>>> [hidden email]> >>>>>>>>>>>>> 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" < >>>>>>>>>>>>>> [hidden email]> >>>>>>>>>>>>>> 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 < >>>>>>>>>>>>>>>>> [hidden email]> 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/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > |
Re: Taking a decision on remaining Jars in OFBiz
|
Administrator
|
I'm not against this way and what proposed Jacopo earlier. I started here: https://cwiki.apache.org/confluence/display/OFBIZ/Keeping+OFBiz+secure
Feel free to contribute Jacques Le 09/09/2016 à 08:17, Taher Alkhateeb a écrit : > Yes I agree with you completely that we should provide solutions to help > our users in their security issues. > > The only difference in our views is "methodology". To me I think better > documentation (wiki, JavaDoc, etc) and cleaning code is a better approach > than introducing a library that people might or might not use and that does > not have clear technical benefits laid out. Security is a big topic and > there are many areas to improve. Security issues like deserialization, XSS, > SQL injection and others usually reveal themselves in certain parts of the > code under certain conditions within a certain context. So it is always the > "details" that matter and why code is the absolute most important aspect of > security. What's the use of having a firewall for example if the only open > port has a vulnerability because of bad code? > > So .. a good approach in my opinion is to have a wiki page up which > discusses among other things: > - How to introduce new libraries > - Explanation of java deserialization (and other security risks) and how to > mitigate it. > - Perhaps we can have a section on tools like notsoserial and others with > some code snippets showing when and how to use and for what reasons. > - best practices on securing ofbiz > - and any thing related to security you think is useful > > In addition to that wiki page, we need to dig into the critical components > of the code base and refactor it and clean it up. Good clean code goes > hand-in-hand with secure code. So it is a win-win situation and the reason > why I was pushing hard for code refactoring. > > WDYT? If you agree then we can work on a good well documented page all > about security and get help from everyone to have good well documented > material. > > Taher Alkhateeb > > On Sep 9, 2016 7:08 AM, "Jacques Le Roux" <[hidden email]> > wrote: > >> OK At least I'd have try to convince you that proposing an OOTB solution >> to protect our users from dangers of Java deserialization is a good thing. >> We can remove the whole thing, let's go >> >> Jacques >> >> >> Le 08/09/2016 à 21:37, Taher Alkhateeb a écrit : >> >>> In reply to your comments: >>> >>> I did not see any point of the ones you mentioned specific to OFBiz. All >>> that I saw is a reference to an article that PayPal was attacked and that >>> using JMX and JNDI might get you exposed with nothing specific to our >>> project and no concrete examples. You want to make a technical decision of >>> having a library based on vague hypothetical grounds with references to >>> some articles about dangers of Java deserialization. This is like saying >>> I'm going to buy this lawn mower because it is great while you don't have >>> any grass in your backyard! >>> >>> Also based on your feedback, the answer to your question "How do you >>> expect >>> to warn users about deserialization driven attacks?" is I don't! I try to >>> avoid being repetitive but OFBiz suffers from overusing too many >>> libraries. >>> It is hardly a good reason to add more because MAYBE some users will >>> develop software using some library that would expose THEIR system. Too >>> hypothetical and does not treat all corner cases and definitely does not >>> make the system more secure because anyone can simply ignore notsoserial, >>> or might choose a different solution. Personally I would not use it >>> because >>> it does not even have a release and the code base is hardly maintained or >>> touched, the proof of which is that the maintainer did not even reply to >>> your email. >>> >>> So, in reference to your point "I wonder why both you and Jacopo reject my >>> proposed solution, any technical or other reasons?" I will let Jacopo >>> answer for his reasons, but mine are very simple. I think we should have >>> less libraries, less bloat, less "stuff" in OFBiz because we have a >>> problematic code base that needs a lot of pruning and refactoring. >>> >>> I think if you really want to focus on security then the _real work_ is in >>> fixing code. Bad code is the biggest source of security problems, not >>> environment or tools. To make our project more secure is to focus on the >>> real critical issue... code! >>> >>> >>> On Thu, Sep 8, 2016 at 8:48 PM, Jacques Le Roux < >>> [hidden email]> wrote: >>> >>> Which classes are you worried about as a vulnerability? >>>> You certainly know that we have no serialization vulnerabilities OOTB. >>>> Most of the external classes which were still a problem for us one year >>>> ago >>>> have been fixed. >>>> I documented that at https://cwiki.apache.org/confl >>>> uence/display/OFBIZ/The+infamous+Java+serialization+vulnerability >>>> >>>> But still 6 months later: http://www.pcworld.com/article >>>> /3026678/paypal-is-the-latest-victim-of-java-deserialization >>>> -bugs-in-web-apps.html >>>> So it's only about warning users about deserialization attacks. They are >>>> maybe not totally aware of the issue. How to warn them efficiently? It >>>> seems to me that my proposition does that. >>>> >>>> Perhaps give an example within this context of exactly what happens and >>>> how notsoserial prevents it. >>>> The article about Paypal above states "Security researchers warned at the >>>> time that thousands of Java-based Web applications, *including >>>> custom-made >>>> enterprise ones*, are likely vulnerable to this attack" >>>> "[snip] it's likely that this type of vulnerability exists in other >>>> libraries as well, waiting to be discovered." >>>> This is not FUD (PayPal!) and it's only 6 months old >>>> >>>> About RMI, JMX is using it http://engineering.pivotal.io/ >>>> post/java-deserialization-jmx/ and if you want to dynamically monitor >>>> things, you will use JMX, won't you? >>>> About JNDI http://zerothoughts.tumblr.com/post/137831000514/spring-fram >>>> ework-deserialization-rce >>>> OK it's not about OFBiz, but those 2 are less than 6 months old. Who can >>>> think that the problems is definitely resolved? It's not, it can't be. >>>> >>>> So no, I have no examples to give you. But one thing I can say, is with >>>> notsoserial running in secure mode in the background you will be notified >>>> if any unexpected deserialization attempt happens. >>>> https://github.com/kantega/notsoserial#rejecting-deserializa >>>> tion-entirely >>>> I hope I have somehow answered your question. Can you answer mine? >>>> >>>> Also, I wonder why both you and Jacopo reject my proposed solution, any >>>> technical or other reasons? >>>> >>>> We decided to use notsoserial by default, I don't see why we should >>>> change >>>> now. I'd have a reassured mind if we committed my proposed change. I see >>>> no >>>> reasons to not do it. >>>> >>>> Jacques >>>> >>>> >>>> Le 08/09/2016 à 15:16, Taher Alkhateeb a écrit : >>>> >>>> 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 < >>>>> [hidden email]> >>>>> 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 < >>>>>>> [hidden email]> 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 < >>>>>>>>> [hidden email]> 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 < >>>>>>>>>>>> [hidden email]> 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 < >>>>>>>>>>>>>> [hidden email]> >>>>>>>>>>>>>> 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" < >>>>>>>>>>>>>>> [hidden email]> >>>>>>>>>>>>>>> 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 < >>>>>>>>>>>>>>>>>> [hidden email]> 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/ >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |