You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by padmanabhan1616 <pa...@gmail.com> on 2018/03/15 12:40:52 UTC
Apache commons fileupload migration
Hi Team,We are using Apache SOLR-5.2.1 as index engine for our data analytics
application. As part of this SOLR uses commons-fileupload-1.2.1.jar for file
manipulation.There is security Vulnerability identified in
commons-fileupload library: *CVE-2016-1000031 Apache Commons FileUpload:
DiskFileItem file manipulation*As per official notice from apache software
foundations this issue has been addressed in commons-fileupload-1.3.3.jar
and available for all the dependency vendors.*Is this good toupgrade
commons-fileupload from 1.2.1 to 1.3.3 version directly?* Please suggest us
best way to handle this. Note - *Currently we don't have any requirements
to upgrade solr, So please suggest best way to handle this vulnarability
without upgrade entire SOLR.*Thanks,Padmanabhan
--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
Re: Apache commons fileupload migration
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Shawn,
On 3/20/18 9:13 AM, Shawn Heisey wrote:
> On 3/15/2018 6:40 AM, padmanabhan1616 wrote:
>> Hi Team,We are using Apache SOLR-5.2.1 as index engine for our data
>> analytics
>> application. As part of this SOLR uses commons-fileupload-1.2.1.jar
>> for file
>> manipulation.There is security Vulnerability identified in
>> commons-fileupload library: *CVE-2016-1000031 Apache Commons FileUpload:
>> DiskFileItem file manipulation*As per official notice from apache
>> software
>> foundations this issue has been addressed in commons-fileupload-1.3.3.jar
>> and available for all the dependency vendors.*Is this good toupgrade
>> commons-fileupload from 1.2.1 to 1.3.3 version directly?*
>
> Solr previously addressed two other vulnerabilites in
> commons-fileupload, both of them after the version you're running.
>
> https://issues.apache.org/jira/browse/SOLR-9819
> https://issues.apache.org/jira/browse/SOLR-9053
>
> One of these fixes just did a jar upgrade, but the other also included
> code changes. So it looks like just replacing the jar with 1.3.3 MIGHT
> cause problems. The commons-fileupload dependency is only used in one
> place in Solr -- the multipart request parser. I cannot tell what
> actually uses this functionality, though. I suspect that whatever it is
> is not something really common.
>
> Looking at the way that Solr uses DiskFileItem and related classes, I
> don't see any evidence that it actually uses serialization or
> deserialization, so I don't think Solr is vulnerable to the problem
> fixed in 1.3.3, but there are two other vulnerabilities that the version
> you're running has. I haven't assessed whether Solr is vulnerable to
> either of those problems.
I think you are misunderstanding the attack vector. It doesn't matter
how Solr uses DiskFileItem. It matters how a running JVM will behave if
it is tricked into deserializing such an object.
Let me give an example:
1. Solr is running on a system in read-only mode (by whatever
definition) and therefore is not firewalled or anything like that.
2. No "normal" users have access to Solr due to process/file permissions.
3. JMX is enabled on the Solr instance, but only for the 127.0.0.1
interface.
This environment might seem to be "secure" because of the isolation
provided by the OS for files and processes, and the restriction of JMX
to the localhost interface.
But JMX uses RMI which uses serialization to marshal objects over the
wire to the JMX server. So an attacker can construct a malicious
serialized object (say, an Object[] which contains a DiskFileItem
somewhere in there) and merely the presence of the vulnerable
commons-fileupload library can be used to trick the JVM into executing
arbitrary code.
The fact that Solr itself doesn't use DiskFileItem is irrelevant.
> FYI: If only trusted admins and applications can reach the Solr server,
> then any remote vulnerability Solr has cannot be exploited unless
> somebody first breaches the security on something else that DOES have
> access to Solr. If they manage to do that, they probably have access
> that's far more damaging than access to Solr would be.
This is absolutely true. But it's easy to overlook things that are
outside of the bounds of the application (like JMX/RMI) or in
little-used corners where deserialization is occurring for whatever
reason. It's those edge-cases that can get you into trouble.
The proper mitigation is to upgrade to the latest version of the
library. I suggested that the OP read the changelog because it describes
all the changes and whether or not they are backward-compatible.
-chris
Re: Apache commons fileupload migration
Posted by Shawn Heisey <ap...@elyograg.org>.
On 3/15/2018 6:40 AM, padmanabhan1616 wrote:
> Hi Team,We are using Apache SOLR-5.2.1 as index engine for our data analytics
> application. As part of this SOLR uses commons-fileupload-1.2.1.jar for file
> manipulation.There is security Vulnerability identified in
> commons-fileupload library: *CVE-2016-1000031 Apache Commons FileUpload:
> DiskFileItem file manipulation*As per official notice from apache software
> foundations this issue has been addressed in commons-fileupload-1.3.3.jar
> and available for all the dependency vendors.*Is this good toupgrade
> commons-fileupload from 1.2.1 to 1.3.3 version directly?*
Solr previously addressed two other vulnerabilites in
commons-fileupload, both of them after the version you're running.
https://issues.apache.org/jira/browse/SOLR-9819
https://issues.apache.org/jira/browse/SOLR-9053
One of these fixes just did a jar upgrade, but the other also included
code changes. So it looks like just replacing the jar with 1.3.3 MIGHT
cause problems. The commons-fileupload dependency is only used in one
place in Solr -- the multipart request parser. I cannot tell what
actually uses this functionality, though. I suspect that whatever it is
is not something really common.
Looking at the way that Solr uses DiskFileItem and related classes, I
don't see any evidence that it actually uses serialization or
deserialization, so I don't think Solr is vulnerable to the problem
fixed in 1.3.3, but there are two other vulnerabilities that the version
you're running has. I haven't assessed whether Solr is vulnerable to
either of those problems.
FYI: If only trusted admins and applications can reach the Solr server,
then any remote vulnerability Solr has cannot be exploited unless
somebody first breaches the security on something else that DOES have
access to Solr. If they manage to do that, they probably have access
that's far more damaging than access to Solr would be.
Thanks,
Shawn
Re: Apache commons fileupload migration
Posted by padmanabhan1616 <pa...@gmail.com>.
Yes I read the changelog 1.3.3. This release contains the security
vulnerability fix.
DiskDileItem can actually no longer be deserialized, *unless a system
property is set to true*. Fixes FILEUPLOAD-279.
We don't have security architecture for my product to decide weather it is
vulnerable or not. So, please kindly help us below
My concern here is,
Is this vulnerable for lower version of commons-fileupload or not? If yes
then upgrading directly in Apache solr-5.2.1 version is good idea or not?
--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
Re: Apache commons fileupload migration
Posted by Christopher Schultz <ch...@christopherschultz.net>.
To whom it may concern,
On 3/15/18 8:40 AM, padmanabhan1616 wrote:
> Hi Team,We are using Apache SOLR-5.2.1 as index engine for our data analytics
> application. As part of this SOLR uses commons-fileupload-1.2.1.jar for file
> manipulation.There is security Vulnerability identified in
> commons-fileupload library: *CVE-2016-1000031 Apache Commons FileUpload:
> DiskFileItem file manipulation*As per official notice from apache software
> foundations this issue has been addressed in commons-fileupload-1.3.3.jar
> and available for all the dependency vendors.*Is this good toupgrade
> commons-fileupload from 1.2.1 to 1.3.3 version directly?* Please suggest us
> best way to handle this. Note - *Currently we don't have any requirements
> to upgrade solr, So please suggest best way to handle this vulnarability
> without upgrade entire SOLR.*Thanks,Padmanabhan
Have you read the changelog?[1]
-chris
[1] https://commons.apache.org/proper/commons-fileupload/changes-report.html