CVE-2022-41854 is still exploitable on latest version of SnakeYAML (when explicitly enabled)

[Yair Mizrahi]

Hi @Andrey Somov ,

I'd like to report that the latest version of SnakeYAML is still vulnerable to CVE-2022-41854 (v1.33 from 2022-09-26).

Original OSS-Fuzz report: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=50355
Original SnakeYAML report: https://bitbucket.org/snakeyaml/snakeyaml/issues/543

The vulnerability is listed as fixed in SnakeYAML v1.32, but when using a non-default configuration, it’s still exploitable even on the latest version v1.33.
The test here checks the vulnerability only with the specific configuration (which is now the default from v1.32 and later):
options.setAllowRecursiveKeys(false);

But it fails to detect the vulnerability is still applicable when using a non-default configuration:
options.setAllowRecursiveKeys(true);

Also, the fuzzer in OSS-Fuzz here is only using the default configuration (which sets setAllowRecursiveKeys to false automatically).
The fixing commit that merged into v1.32 still allows recursive keys to be deeply nested, leading to infinite recursions and thus still causing stack exhaustion. 

We tried to contact the CVE’s CNA Google Security team via email a few times almost 2 months ago, but never got any reply from them.

[Andrey Somov]

@Yair Mizrahi please be aware that recursive keys are implemented intentionally. It is not a bug, it is a feature. If you explicitly allow it, what is the issue ?
(it is secure by default, but insecure when you explicitly allow it)

[Andrey Somov]

@Yair Mizrahi can the ticket be closed ?

[Jonathan Leitschuh]

But it fails to detect the vulnerability is still applicable when using a non-default configuration:
options.setAllowRecursiveKeys(true);

What’s the ask here? Is it to detect recursion that will cause StackOverflow exceptions preemptively, even when recursive keys are allowed by the library user?

The current state seems to be “secure by default”, correct?

Are you asking that the logic be rewritten to be iterative instead of recursive to prevent infinite recursion causing a StackOverflow exception, but instead would run forever? If not, what behaviour would you like to see instead?

[Yair Mizrahi]

Are you asking that the logic be rewritten to be iterative instead of recursive to prevent infinite recursion causing a StackOverflow exception, but instead would run forever? If not, what behaviour would you like to see instead?

I’m asking that the logic be rewritten to be iterative instead of recursive and stop iterating by throwing an error after X number of iterations (a number of iterations that is reasonable enough).

[Andrey Somov]

the last coment is unrelated to the ticket. I will close the ticket

[Andrey Somov]

as designed