[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 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
