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 <
jacques.le.r...@les7arts.com> 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 <
jacques.le.r...@les7arts.com> 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 <
jacques.le.r...@les7arts.com> 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 <
slidingfilame...@gmail.com>
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" <
jacques.le.r...@les7arts.com>
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 <
jacques.le.r...@les7arts.com> 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/
