guava-16.0.1 and guav-19.0 vulnerability CVE-2018-10237 #50395
Comments
|
Pinging @elastic/es-core-infra (:Core/Infra/Core) |
This commit upgrades the OWASP HTML sanitizer used by watcher to the latest version and also upgrades guava, which it depends on. The guava upgrade also requires the addition of a new dependency that guava itself requires as of version 27.0. Relates elastic#50395
|
I've been going through all the uses of guava. These are all indirect (we do not use guava directly in Elasticsearch). The following are uses of guava less than 24.1.1: repository-azure plugin repository-hdfs plugin watcher security |
|
i manually updated most of 7.4.2 to latest guava without issue and built my own version successfully. even if indirect they still show on security scans. Anything we can do to get that to not be a security scan result even if indirect is always best. Thanks for digging! |
|
regarding repository-hdfs plugin compatibility: Everything that I've seen has been centered around HDFS v3.x being backwards compatible with HDFS client v2, but not the other way around. If we were to upgrade the HDFS Client in repository-hdfs we would most likely need to increase the minimum supported HDFS version for the plugin. Hadoop and HDFS v3 has been out for a while now, but some Hadoop users are still bound to the version 2 line, and this would likely constitute a breaking change for that reason. |
|
I was able to override and bump guava without bumping hdfs without issue
…Sent from my iPhone
On Jan 13, 2020, at 9:38 AM, James Baiera ***@***.***> wrote:
regarding repository-hdfs plugin compatibility:
Everything that I've seen has been centered around HDFS v3.x being backwards compatible with HDFS client v2, but not the other way around. If we were to upgrade the HDFS Client in repository-hdfs we would most likely need to increase the minimum supported HDFS version for the plugin. Hadoop and HDFS v3 has been out for a while now, but some Hadoop users are still bound to the version 2 line, and this would likely constitute a breaking change for that reason.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
While it is great that it worked for you, the trickiness of bumping dependencies which were not developed against the newer version is there can be runtime issues that do not come up until a particular feature is used. While we may end up still bumping this as suggested, guava is particularly painful and error prone in this case, or at least was with older versions. Bumping this will need extensive testing. |
This commit upgrades the OWASP HTML sanitizer used by watcher to the
latest version and also upgrades guava, which it depends on. The guava
upgrade also requires the addition of a new dependency that guava
itself requires as of version 27.0. The sanitizer's behavior has changed to
re-write these templated values with a comment that results in this output
`{<!-- -->{ctx.metadata.name}}`. This would be an issue if we attempted to
sanitize the template, but the code that uses the sanitizer runs the rendered
string through the sanitizer, which means that the templated values have
been replaced already.
Relates #50395
This commit upgrades the OWASP HTML sanitizer used by watcher to the
latest version and also upgrades guava, which it depends on. The guava
upgrade also requires the addition of a new dependency that guava
itself requires as of version 27.0. The sanitizer's behavior has changed to
re-write these templated values with a comment that results in this output
`{<!-- -->{ctx.metadata.name}}`. This would be an issue if we attempted to
sanitize the template, but the code that uses the sanitizer runs the rendered
string through the sanitizer, which means that the templated values have
been replaced already.
Relates elastic#50395
This commit upgrades the OWASP HTML sanitizer used by watcher to the
latest version and also upgrades guava, which it depends on. The guava
upgrade also requires the addition of a new dependency that guava
itself requires as of version 27.0. The sanitizer's behavior has changed to
re-write these templated values with a comment that results in this output
`{<!-- -->{ctx.metadata.name}}`. This would be an issue if we attempted to
sanitize the template, but the code that uses the sanitizer runs the rendered
string through the sanitizer, which means that the templated values have
been replaced already.
Relates #50395
This commit upgrades the OWASP HTML sanitizer used by watcher to the
latest version and also upgrades guava, which it depends on. The guava
upgrade also requires the addition of a new dependency that guava
itself requires as of version 27.0. The sanitizer's behavior has changed to
re-write these templated values with a comment that results in this output
`{<!-- -->{ctx.metadata.name}}`. This would be an issue if we attempted to
sanitize the template, but the code that uses the sanitizer runs the rendered
string through the sanitizer, which means that the templated values have
been replaced already.
Relates elastic#50395
|
I've marked this issue as stalled. There are 3 remaining production uses, which are blocked on the following changes:
|
|
Checking in on the hdfs side of things - Upgrading from 11.0.2 to 24.1.1 is not going well. Additionally, The HDFS 3.x client is not backward compatible with HDFS 2.x services, which according to artifact download numbers on maven are still the most popular versions. We may have to wait on upgrading Hadoop for a bit. Taking a look at the CVE, the AtomicDoubleArray class does not seem to be used on the client side of things, but CompoundOrdering class may be used occasionally since it is so widely referenced through guava. Hadoop relies primarily on Protocol Buffers to handle serialization on the RPC interface. Since the vulnerability surfaces when using Java's built in serialization, these cases may have lower surface area for exploitation through the HDFS client. |
pgomulka
added
high hanging fruit
and removed
needs:triage
|
In the latest 7.x version, guava dependencies with vulnerabilities are reported in |
|
As at Elasticsearch 7.17 the only remaining use of Guava < 24 is the transitive dependency via OpenSAML. Unfortunately the situation with respect to OpenSAML + Guava + Elasticsearch is:
There is no supported combination of Java 8 + OpenSAML + Guava that we can use except to continue shipping an older version Guava (such as 19, or 20). We considered options to patch OpenSAML or Guava to avoid shipping a dependency with this CVE, however each option introduces additional risk. The CVE in question does not have any practical issue for Elasticsearch because it is a serialization attack, and ES does not use Java serialization in conjunction with Guava. In this case, we have upgraded OpenSAML to v4.0 in Elasticsearch 8.0 (because ES8 depends on Java 17, which removes the upgrade obstacle we had). Our commitment to our users is that we introduce new features and substantial changes in major or minor releases (x.y.0), and patch releases (x.y.1, x.y.2, etc) are for bug fixes and low risk changes. At this point in time, with the available information we have, our view is that attempting to replace or remove Guava 19 in a patch release of Elasticsearch 7.17 would introduced unwarranted risk that would outweigh the benefits of resolving this CVE. We have made this decision based on the published information about the CVE and the assessment that it is not exploitable in Elasticsearch. This issue is entirely resolved in the most recent releases of Elasticsearch 8. |
CVE-2018-10237
ElasticSearch guava version needs updated to 24.1.1 to resolve another CVE
https://nvd.nist.gov/vuln/detail/CVE-2018-10237
The text was updated successfully, but these errors were encountered: