Snakeyaml vulnerability in OpenSearch - autoclosed

[akhil-lm]

We use opensearch-x-content:2.0.0 and org.opensearch.client:opensearch-rest-high-level-client:2.0.0 jars in our application, which uses a vulnerable artifact snakeyaml. Even the most recent snakeyaml version v1.33 has a high vulnerability that can lead to remote code execution :- https://nvd.nist.gov/vuln/detail/CVE-2022-1471

Snakeyaml hasn't offered an updated safe version so far. Since we use Opensearch, snakeyaml library is transitively added as well.

Spring boot came up with their analysis on why their use-case of snakeyaml is not vulnerable, even though they use it :- spring-projects/spring-boot#33457

Is there a plan by Opensearch to address this challenge/vulnerability that comes with using Snakeyaml? Please let me know if there's any update.

[dreamer-89]

Thank you @akhil-lm for reporting this issue and tagging the relevant artifacts. I am looking into artifacts attached (also listed below) to learn more about the vulnerability and how it can be exploited in OpenSearch.

Also, I see CVE-2022-1471[3], security report[2] & repository [4] does not report any vulnerability in 1.32 (Opensearch version in main, 2.x and 1.x).

[1] https://bitbucket.org/snakeyaml/snakeyaml/issues/561/cve-2022-1471-vulnerability-in#comment-64581479
[2] GHSA-mjmj-j48q-9wg2
[3] https://nvd.nist.gov/vuln/detail/CVE-2022-1471
[4] https://mvnrepository.com/artifact/org.yaml/snakeyaml

[akhil-lm]

Hi @dreamer-89,
I see that the vulnerability associated with the SnakeYaml's Constructor() class has been addressed by Opensearch in this PR by using SafeConstructor() :- https://github.com/opensearch-project/security-analytics/pull/198/files

The latest Opensearch library available is v2.4.1. Would the change in the above PR be a part of the next version v2.4.2? If yes, then could you please let me know when can we expect the new version? Thanks so much.

[akhil-lm]

Hi @dreamer-89,
I observe that the change in the above PR has been done for the opensearch-security-analytics artifact.

In our application, we're getting the snakeyaml artifact through the 'opensearch-x-content' artifact. Additionally, we also use the 'opensearch' and the 'opensearch-rest-high-level-client' artifacts in our application.

Hence, we're interested to know whether these artifacts are affected or not due to the reported snakeyaml vulnerability. Request your inputs on the same.

[dreamer-89]

The latest Opensearch library available is v2.4.1. Would the change in the above PR be a part of the next version v2.4.2? If yes, then could you please let me know when can we expect the new version? Thanks so much.

Thanks @akhil-lm for checking on this. Based on release schedule, the fix should go in 2.5.0 on Jan 17, 2023. As this high severity risk, we are evaluating if 2.4.2 can be released with the fix. I will update once I have more info on this.

Hence, we're interested to know whether these artifacts are affected or not due to the reported snakeyaml vulnerability. Request your inputs on the same.

Inside OpenSearch, no code path was identified that can be exploited for the CVE-2022-1471 vulnerability.

[dreamer-89]

@akhil-lm: The fix in security-analytics plugin will go in 2.5.0 release on Jan 17, 2023. Closing this issue, please free to reopen if you have anymore questions.

[naveentatikonda]

@dreamer-89 I don't find an option to reopen the issue. But, opensearch-3.0.0-SNAPSHOT.jar is still under security vulnerability due to snakeyaml-1.32.jar. More details are available in the below issue
opensearch-project/geospatial#145

[dblock]

I'll reopen it.

[reta]

FYI, the Whitesource [1] caches that, along with bc-fips-1.0.2.3, for both there is no fix yet:

CVE	Severity	CVSS Score	Vulnerable Library	Suggested Fix	Issue
CVE-2022-1471	High	9.8	snakeyaml-1.33.jar		None
CVE-2022-45146	Medium	5.5	bc-fips-1.0.2.3.jar		None

[1] https://github.com/opensearch-project/OpenSearch/pull/5666/checks?check_run_id=10881469266

[andrross]

I believe all usages of SnakeYaml in OpenSearch are now using SafeConstructor() after #6205, per the recommendation in the CVE.

[mend-for-github-com]

✔️ This issue was automatically closed by Mend because the vulnerable library in the specific branch(es) was either marked as ignored or it is no longer part of the Mend inventory.