[BUG] Spring RCEs (CVE-2022-22965)

[sandervandegeijn]

Describe the bug
On the opensearch website, newest version: 1.3.1
Docker hub: 1.3.1
!! Github 1.3.0

Can't find the release notes, is this release because of the Spring RCE bugs? The ambiguous communicatie combined with the impact of the vulnerabilities makes me unsure if I should upgrade asap or if the release is about something else.

Expected behavior
Versions are consistent on website, github, docker, etc and there are changenotes and a news item on the website on the focus of the release.

[sandervandegeijn]

Trivy report, reports more vulns:

[sandervandegeijn]

Trivy on 1.3.1, it's not happy, not sure if it's false positive:

[dblock]

Looks like we've tagged all repos with 1.3.1 correctly, but didn't make a "release" on GitHub, for now I've commented in opensearch-project/opensearch-build#1805 (comment), but it is likely a new issue with our release process. Either way it shouldn't be a big problem in itself.

Editing this issue to be RCE-related only.

Release notes in https://github.com/opensearch-project/opensearch-build/blob/main/release-notes/opensearch-release-notes-1.3.1.md, but no mention of spring RCE.

[sandervandegeijn]

Can we confirm that Opensearch is not affected by the vulns found by Trivy and that those are indeed false positive?

[dblock]

Can we confirm that Opensearch is not affected by the vulns found by Trivy and that those are indeed false positive?

Will have someone take a look ASAP.

[dblock]

For jackson-databind I see #2599 that went into 2.0 (#2597), but it wasn't backported into 1.x/1.3, let's get a definitive statement on whether that vulnerability affects OpenSearch or not.

[sandervandegeijn]

yes, already did, see 3rd post, second screenshot :)

[dblock]

yes, already did, see 3rd post, second screenshot :)

Yes, I saw that and deleted my comment. Thx

[mch2]

OpenSearch does not meet the requirements as outlined here. We don't depend on spring directly, particularly the spring-webmvc or spring-webflux packages.

As for plugins,
Our data-prepper plugin does have a packaged example app with a controller using parameter binding & spring-boot here, but not in the package itself.

Sql also has spring dependencies, but is used for DI with no controllers.

[dblock]

@ict-one-nl looks like we can say "not vulnerable" given @mch2's comment. I'll close this, but please do reopen if you feel otherwise.

Note that we did upgrade the dependency in 2.0. If you want to backport #2599 into 1.x and 1.3 branches by hand (auto-backport seems to have failed) we can take it and if there were to be a 1.3.2 it can be included in it.

[sandervandegeijn]

Thanks for the investigation! :) 1.3.1 is still missing on github releases page btw.

[dblock]

Thanks for the investigation! :) 1.3.1 is still missing on github releases page btw.

Yes, I reopened and commented on opensearch-project/opensearch-build#1805 (comment)

[sandervandegeijn]

Cool thanks :)

[dblock]

Note @reta has backported the fixes to 1.3/1.x (thank you!), but at this point there's no plan to release that version.

#2706

[mch2]

OpenSearch does not meet the requirements as outlined here. We don't depend on spring directly, particularly the spring-webmvc or spring-webflux packages.

As for plugins, Our data-prepper plugin does have a packaged example app with a controller using parameter binding & spring-boot here, but not in the package itself.

Sql also has spring dependencies, but is used for DI with no controllers.

To add more here. The Data-prepper plugin is also not part of the shipped OpenSearch bundle.

Sql does have "Controllers" but they are implemented with OpenSearch's RestHandler's that do not use spring controllers. So Sql's use of Spring does not include request parameter binding.

[nobletrout]

hey guys, this is really buried here. I emailed AWS, following through your guidance on "how to report a security issue". I got a form letter telling me that AWS was safe, but not any specific comment about this opensource project, which was my main concern. Could you tag this issue with the CVE? (CVE-2022-22965) please?

[CEHENKLE]

@nobletrout hmmmm...okay, that's odd. If you're comfortable, please feel free to share with me on email (henkle(at)amazon.com) the response you got, because I'm super curious.

In the meantime, good suggestion -- I've updated the title with the CVE number to make it easier to find.