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