Hi jacques, Okay great thank you for the thorough explanation. So based on your feedback I think that it does not make any difference whether we keep or delete the ofbizSecure and ofbizBackgroundSecure because the work has to be done either way to ensure that the OOTB whitelist is satisfied and whether notsoserial is default or not does not affect anyone during development or production. So I think we can safely remove these tasks and default them into the other tasks, the completion of the whitelist is another task for another day.
Can I go ahead with the task or are you currently working on intersecting work? Would you mind helping out in switching buildbot to ofbiz instead of ofbizSecure? Taher Alkhateeb On Fri, Aug 12, 2016 at 11:22 PM, Jacques Le Roux < [email protected]> wrote: > Le 12/08/2016 à 20:51, Taher Alkhateeb a écrit : > >> Hi Jacques, >> >> Ok so I'm a little confused now. If the whitelist is incomplete and we did >> not exhaust the investigation, then why are we running the demo on >> ofbizSecure? >> > > The main reason is we have no known deserialization issues OOTB. > Initially we had issues and I planned to complete the list. But then > thought that anyway, since we run it only during a day, it will never be > complete and I gave up. > > Or actually, let me ask you in another why ... When should we prefer _not_ >> to have ofbizSecure and why? >> > > When you are sure to not have any deserialization issues. For instance, as > soon as you introduce RMI you are at risk. Notsoserial has a list of know > issues https://github.com/kantega/notsoserial#which-classes-are-rejected > Note that we don't have these issues in OFBiz: see OFBIZ-6726, OFBIZ-6568 > and OFBIZ-6942 as explained at https://cwiki.apache.org/confl > uence/display/OFBIZ/The+infamous+Java+serialization+vulnerability > > Jacques > > > > >> Taher Alkhateeb >> >> On Fri, Aug 12, 2016 at 9:42 PM, Jacques Le Roux < >> [email protected]> wrote: >> >> I conceived the Ant secure target with demo in mind, thinking users would >>> adapt it to their needs. >>> On trunk demo we use an empty whitelist, and trace deserialization. And >>> because it must run w/o manual intervention we don't reject >>> deserialization, we trace them. >>> At https://cwiki.apache.org/confluence/display/OFBIZ/The+infamo >>> us+Java+serialization+vulnerability I recommend to reject >>> deserialization >>> entirely (ie "just use an empty whitelist") >>> https://github.com/kantega/not >>> soserial#rejecting-deserialization-entirely >>> This is why I picked notsoserial over all other solutions. If you use >>> this option you are safe! The idea is to test your code before production >>> and to add libs in the whitelist if needed. >>> >>> It's difficult to set a whitelist OOTB because it depends on so many >>> things, so far today we hit those on trunk demo (most of the time I saw >>> only that) >>> java.util.HashMap >>> java.lang.Boolean >>> java.lang.Integer >>> java.lang.Number >>> org.apache.derby.iapi.services.io.FormatIdInputStream.readObject >>> >>> So if we remove ofbizSecure and ofbizBackgroundSecure by including them >>> by >>> default we indeed need to create an as far as possible complete OOTB >>> whitelist >>> This needs some work I can't do, even if the trunk demo could be used >>> appropriately by reporting each day the deserializations done. >>> >>> If we want to complete the list using the trunk demo we would still need >>> a >>> mean to trace the deserializations there. I see 2 options >>> 1) a specific Gradle task using the notsoserial tracing and report about >>> it. It's easier but defeats the purpose of removing ofbizSecure and >>> ofbizBackgroundSecure >>> 2) simply using the daily logs and look for "|Deserialization not allowed >>> for class"|. It's not that more work, in both cases we need to fetch the >>> info and parse. Most of the time, this should have a limited impact on >>> the >>> demo usability. >>> ||| >>> |We could also decide to neglect this aspect, create an OOTB reputed to >>> be >>> incomplete whitelist and benefit from adopters researches to complete it. >>> Then we need to carefully document what we are doing for adopters to >>> easily >>> be safe. >>> >>> Jacques >>> >>> Le 07/08/2016 à 11:44, Taher Alkhateeb a écrit : >>> >>> Hi Scott, >>>> >>>> Yeah agreed. I think logging for failed serialization might be a bit >>>> heavy because you might need to use reflections or custom class loaders >>>> to >>>> dig around and provide useful messages. If a runtime exceptions bubbles >>>> up >>>> to main then it will show up in the console and I think this could >>>> be enough for developers to investigate. >>>> >>>> On Sunday, 7 August 2016, Scott Gray<[email protected]> >>>> wrote: >>>> >>>> I would suggest enabling the whitelist by default, adding whatever >>>> classes >>>> >>>>> OFBiz needs OOTB and then having a clear failure message in the logs >>>>> when a >>>>> custom class fails serialization. Would that work? >>>>> >>>>> Regards >>>>> Scott >>>>> >>>>> On 6/08/2016 23:13, "Jacques Le Roux" <[email protected] >>>>> <javascript:;>> wrote: >>>>> >>>>> I'd not be against but we need to be clear while documenting that it's >>>>> not >>>>> >>>>> enough for security (when needed, users need to refer to the wiki >>>>>> page), >>>>>> >>>>>> a >>>>> >>>>> white list is necessary (again only when needed, not OOTB) >>>>>> >>>>>> I guess (at least I hope for them) most sysadmin, devops are aware of >>>>>> the >>>>>> possible issue, but simpler users need to be warned... >>>>>> >>>>>> Jacques >>>>>> >>>>>> Le 06/08/2016 à 12:49, Taher Alkhateeb a écrit : >>>>>> >>>>>> Hi Jacques, >>>>>> >>>>>>> As I referred to earlier I suggest the following: >>>>>>> >>>>>>> - remove ofbizSecure and ofbizBackgroundSecure >>>>>>> - make all other server tasks secure by default (i.e. loading >>>>>>> >>>>>>> notsoserial >>>>>> and all other jvm args which are currently used in ofbizSecure). This >>>>>> >>>>>>> means >>>>>>> ofbiz, ofbizBackground and ofbizDebug >>>>>>> - update the documentation so that users need not worry about calling >>>>>>> >>>>>>> any >>>>>> secure tasks. So they only need to do custom work such as the >>>>>> whitelist, >>>>>> >>>>>>> etc ... >>>>>>> >>>>>>> I am not sure but I think there is no performance penalty right? That >>>>>>> is >>>>>>> why I suggest lumping them together. >>>>>>> >>>>>>> Taher Alkhateeb >>>>>>> >>>>>>> On Aug 6, 2016 11:40 AM, "Jacques Le Roux" < >>>>>>> >>>>>>> [email protected] <javascript:;>> >>>>>> >>>>> wrote: >>>>> >>>>>> Le 06/08/2016 à 11:43, Taher Alkhateeb a écrit : >>>>>>> >>>>>>> Hi Jacques, >>>>>>>> >>>>>>>> I think that filling the white list ,etc ... might be something to >>>>>>>>> >>>>>>>>> keep >>>>>>>> >>>>>>> in >>>>>> >>>>>>> the page on securing OFBiz (documentation). >>>>>>>>> >>>>>>>>> I prefer to have a direct link to notsoserial documentation to be >>>>>>>>> sure >>>>>>>>> >>>>>>>>> it's up to date. That's what I did on the related wiki page >>>>>>>> >>>>>>>> I understand your point about >>>>>>>> >>>>>>>> making it more "explicit" which makes sense, it has, however, the >>>>>>>> >>>>>>>>> downside >>>>>>>>> of making the users aware that there are different tasks to run, >>>>>>>>> and >>>>>>>>> also >>>>>>>>> the rc scripts need to be modified to production and might be >>>>>>>>> >>>>>>>>> confusing >>>>>>>> >>>>>>> (ofbiz, ofbizBackground, ofbizBackgroundSecure, ofbizSecure) might be >>>>>> >>>>>>> too >>>>>>>>> many options to choose from in a production environment. >>>>>>>>> >>>>>>>>> No strong opinion, but I am suggesting to make it a little easier >>>>>>>>> for >>>>>>>>> people with a less-is-more kind of approach. >>>>>>>>> >>>>>>>>> What would you suggest? It seems to me that removing these options >>>>>>>>> >>>>>>>>> would >>>>>>>> >>>>>>> degrade the information about rare but possible vulnerabilities >>>>>> >>>>>>> Jacques >>>>>>>> >>>>>>>> >>>>>>>> Taher Alkhateeb >>>>>>>> >>>>>>>> On Sat, Aug 6, 2016 at 11:44 AM, Jacques Le Roux < >>>>>>>>> [email protected] <javascript:;>> wrote: >>>>>>>>> >>>>>>>>> The idea is that by default the task does not do much. You have to >>>>>>>>> follow >>>>>>>>> >>>>>>>>> the advices they give to make it really effective (filling a white >>>>>>>>> list >>>>>>>>> >>>>>>>> is >>>>>> >>>>>>> the better way) >>>>>>>>>> >>>>>>>>>> That's why I separated it from the rest to make it more obvious >>>>>>>>>> for >>>>>>>>>> users. >>>>>>>>>> >>>>>>>>>> Currently "gradlew tasks" gives you this information >>>>>>>>>> >>>>>>>>>> Pattern: ofbizSecure <Commands>: Execute OFBiz startup commands >>>>>>>>>> pre-loading the notsoserial Java agent >>>>>>>>>> Pattern: ofbizBackgroundSecure <Commands>: Execute OFBiz startup >>>>>>>>>> commands >>>>>>>>>> in background (secure mode) and output to console.log >>>>>>>>>> >>>>>>>>>> Jacques >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Le 06/08/2016 à 03:33, Scott Gray a écrit : >>>>>>>>>> >>>>>>>>>> Why isn't whatever functionality 'ofbizSecure' provides, just >>>>>>>>>> >>>>>>>>>> included >>>>>>>>> >>>>>>>> as >>>>>> >>>>>>> part of the regular 'ofbiz' task? >>>>>>>>>> >>>>>>>>>>> On 5 August 2016 at 21:35, Jacques Le Roux < >>>>>>>>>>> [email protected] <javascript:;>> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Le 05/08/2016 à 11:21, Taher Alkhateeb a écrit : >>>>>>>>>>> >>>>>>>>>>> +1 makes sense >>>>>>>>>>> >>>>>>>>>>> Should we also remove the tasks ofbizSecure and >>>>>>>>>>>> >>>>>>>>>>>> ofbizBackgroundSecure >>>>>>>>>>> >>>>>>>>>> and >>>>>> >>>>>>> replace them with some scripts in /tools if people are not using >>>>>>>>>>>>> them? >>>>>>>>>>>>> (I >>>>>>>>>>>>> assume we only use them with demos?) >>>>>>>>>>>>> >>>>>>>>>>>>> On Aug 5, 2016 10:07 AM, "Jacques Le >>>>>>>>>>>>> >>>>>>>>>>>>> Roux"<jacques.le.roux@les7arts >>>>>>>>>>>> >>>>>>>>>>> .com >>>>>> >>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Nope, those are intended to be used in production if ever you >>>>>>>>>>>>> need >>>>>>>>>>>>> it. >>>>>>>>>>>>> >>>>>>>>>>>>> See the warning therehttps://cwiki.apache.org/confl >>>>>>>>>>>>> >>>>>>>>>>>>> uence/display/OFBIZ/Keeping+OFBiz+secure for details >>>>>>>>>>>> >>>>>>>>>>>> Jacques >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >
