Suggest any mitigation for CVE-2022-38752

[Khusanjon Tuychiboev]

Hello group.

Could someone suggest any mitigation or workaround for CVE-2022-38752? Also please share any information about this CVE, like the planned release that fixed this issue.

Thanks.

[Uday Bhaskar Sarma Seetamraju]

FYI for all.

CVE-2022-38752 = https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-38752 

Description: Using snakeYAML to parse untrusted YAML files may be vulnerable to Denial of Service attacks (DOS). If the parser is running on user supplied input, an attacker may supply content that causes the parser to crash by stack-overflow.

IMPORTANT NOTE:

This CVE is **still** undergoing analysis (Ref: https://nvd.nist.gov/vuln/detail/CVE-2022-38752).

It was reported just a day ago.

So, no one is really sure whether this is a low-severity vulnerability or worse.  Google (who reported it) thinks this is a medium-severity vulnerability.

If you are hosting an API (ingesting YAML) on AWS, there's a simple strategy to mitigate = new Rule on AWS WAF.  In fact, I'd wait until the 1st DOS attack happens, to save on AWS WAF costs (a.k.a. security-thru-obscurity strategy).  If you are NOT ALREADY using API-GW to validate the Header-Tokens, you are going to get what you deserve.

I suppose, something similar on GCP and Azure will do the same.

That said, I am assuming this is a huge problem for those STILL hosting APIs on-premises.  Apologies, I can't help you at all.

--
You received this message because you are subscribed to the Google Groups "SnakeYAML" group.
To unsubscribe from this group and stop receiving emails from it, send an email to snakeyaml-cor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/snakeyaml-core/ebc1f722-5462-43db-83e2-5abf6fa8530bn%40googlegroups.com.

[Andrey Somov]

I hope it may clarify the topic:

https://bitbucket.org/snakeyaml/snakeyaml/wiki/CVE%20&%20NIST

To view this discussion on the web visit https://groups.google.com/d/msgid/snakeyaml-core/CACc6mrwmZMnigY8yHK1C_6mdsLecFTbSt%2Bd5BFCpuRM5Qkc4RA%40mail.gmail.com.

[Paul Wagland]

Hi Audrey,

Thanks for this page. A couple of suggestions:

Instead of "There is a number of vulnerability reports related to SnakeYAML in the NIST database.", I would recommend listing them explicitly, also in the page. Since otherwise it looks like a blanket statement created to say there are no issues in SnakeYAML, which might true today, but _could_ change in the future.

Also, in the section about how to deal with untrusted data, you mention to review the API that lets you deal with it, it might be handy to have a link to that API there, or explicit documentation about how to deal with untrusted data.

If I look through all of the "CVE-2022" issues from NIST, it looks to me like there were no changes to SnakeYAML itself, apart from formatting, the only changes that were added to "resolve" these issues were additional tests?

And from a product POV, so long as we can be sure that the only place YAML parsing is done is from local and/or controlled sources, then these issues don't affect us anyway.

Cheers,

Paul 

[Paul Wagland]

Sorry @Andrey, not Audrey.

[Andrey Somov]

Dear Paul,

it is sad that I could not explain the issue.

The NIST and CVE are almost innocent. The only problem with them is that they do not emphasize the context - but the context is everything.

The issue is about the low quality tooling, which is unable to detect and check the context and that is why they blindly complain about everything.

You came here NOT because of NIST, you came here because of a report from some software which is probably failing your build.

1. The list in NIST is irrelevant

2. We are aware of all these issues (they are normally reported to the maintainers before creating CVE)

3. There is NO single use case reported !!! No one blindly reads data from a socket. You you do not - you are safe

4. It is (and it was) possible to configure the parser to avoid most of the issues (when you still want to parse untrusted data)

SnakeYAML is more than 10 years old. Nothing changed. Why suddenly it became unsafe to use ???

Can you please come the tool which reports a problem in SnakeYAML and request the explanation ?

Cheers,

Andrey

To view this discussion on the web visit https://groups.google.com/d/msgid/snakeyaml-core/0abf9f79-76bd-4dab-9960-56f40a343da6n%40googlegroups.com.