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+infamous+Java+serialization+vulnerability I recommend to reject deserialization entirely (ie
"just use an empty whitelist") https://github.com/kantega/notsoserial#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
