[Pulling this back to the Metron dev and security lists] I started poking around to see how someone may mitigate this prior to doing the 0.5.0 upgrade (since that effort is definitely non-trivial), and I came up with this <https://github.com/apache/metron/commit/ac05638160288b32535b986adbeb8f14e594e740#diff-01803a88163be8dce01cb48fbbcd141e> file change which *seems* to be the relevant change.
That being said, in order to mitigate an older version of Metron as an interim solution, is shutting down the Metron rest services in Ambari (breaking all of the things that depend on/use them) be sufficient, or is there a better interim solution? Also, has anyone discussed deploying a 0.4.3 that just has this patch on top of 0.4.2? Since the process to do an upgrade to 0.5.0 is such a big deal, I would be in favor of rolling out a patch, assuming it isn't more or nearly equal to the amount of effort of an upgrade to 0.5.0. Thanks, Jon On Tue, Jun 26, 2018 at 3:33 PM James Sirota <jsir...@apache.org> wrote: > > The following CVE was fixed in Metron 0.5.0: > > [CVEID]: CVE-2018-1273 > [PRODUCT]:Spring Data Commons > [VERSION]: versions prior to 1.13 to 1.13.10, 2.0 to 2.0.5, and older > [PROBLEMTYPE]:remote code execution attack > [REFERENCES]: https://pivotal.io/security/cve-2018-1273 > [DESCRIPTION]: > > Spring Data Commons, versions prior to 1.13 to 1.13.10, 2.0 to 2.0.5, and > older unsupported versions, contain a property binder vulnerability caused > by improper neutralization of special elements. An unauthenticated remote > malicious user (or attacker) can supply specially crafted request > parameters against Spring Data REST backed HTTP resources or using Spring > Data’s projection-based request payload binding hat can lead to a remote > code execution attack. > > -- Jon
