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/confluence/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
