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
signature.asc
Description: OpenPGP digital signature
