CVE-2022-1471 - A new vulnerability in SnakeYaml 1.30+

[albertwangnz]

CVE-2022-1471 has been reported against the SnakeYaml project 1.30+. More information can be found in the google/security-research project security post.

At this stage, SnakeYaml has no patch to fix it. A new issue has been created on SnakeYaml's Bitbucket project.

The description says We recommend using SnakeYaml's SafeConsturctor when parsing untrusted content to restrict deserialization.

Spring Boot uses SnakeYaml so potentially could be impacted. Can somebody (@bclozel) help with checking how Spring Boot uses SnakeYaml since Spring Boot may not be impacted by the vulnerability?

Thank you.

[philwebb]

Thanks for the information.

Spring Boot already uses SafeConstructor internally so I don't think there are any changes we need to make. Furthermore, typically Spring Boot application only use SnakeYaml to parse application.yaml files, which should be trusted already.

Users that use SnakeYaml directly to parse data from untrusted sources should implement their own mitigation strategies.

[albertwangnz]

@philwebb Thanks a lot. Those are the information I am looking for.

[bisvo01]

Is Spring Boot 2.7.x still supported? The unsafe Constructor is still used there.

[bclozel]

@bisvo01 Spring Boot 2.7.x is currently supported, see our support timeline page. We'll do another pass in our codebase to ensure that we're using the safe constructor variant - but in general, Spring Boot is only parsing yaml from trusted sources. Using SafeConstructor is especially useful when you're parsing untrusted content.

[philwebb]

@bisvo01 I just double checked YamlJsonParser in 2.7 and I don't think it's susceptible to the CVE since it already limits the types that can be created.

[AmigaBlitter]

@bisvo01 I just double checked YamlJsonParser in 2.7 and I don't think it's susceptible to the CVE since it already limits the types that can be created.

Thank you for the analysis.

Is Spring Boot 2.5.x susceptible to the CVE?
Thank you in advance.

[bclozel]

@AmigaBlitter it's not, unless your application is using SnakeYaml to deserialize untrusted input. I think the biggest security risk right now is being in production with a Spring Boot version that's not supported anymore (unless you've got commercial support).

[AmigaBlitter]

Thank you for the reply.

[jpcmonster]

@philwebb does the statement regarding SafeConstructur also cover https://github.com/springdoc/springdoc-openapi ?
I am guessing no, but I am asking for completeness - thanks!

[scottfrederick]

@jpcmonster springdoc-openapi is not a Spring Framework project (despite having "spring" in the name). It is maintained by a completely separate group. Any questions about that project should be asked in its repository.

[jpcmonster]

@jpcmonster springdoc-openapi is not a Spring Framework project (despite having "spring" in the name). It is maintained by a completely separate group. Any questions about that project should be asked in its repository.

thanks for your reply; I suspected so and have followed up there.

[sreekanth-tf]

@philwebb @bclozel Is it safe to exclude the snakeyaml dependency if we are using the application.properties instead of application.yml?

[philwebb]

@sreekanth-tf Yes, it should be fine as long as you don't have any .yml files. If you do, this exception will be thrown.

[sreekanth-tf]

thank you @philwebb!

[fabionoth]

Thanks : )

[bclozel]

We are aware that SnakeYaml 2.0 has been released, fixing this CVE. The team is working on an upgrade strategy. Also see spring-projects/spring-framework#30048.

[dlipofsky]

@wilkinsona, I would be referring to having SpringBoot 2.7.x use snakeyaml 2.0. I can see that spring-boot-starter 2.7.10 pom pulls in snakeyaml 1.30. I scanned the ticket you refer to, it sounds like "one person tried it and it didn't break". I suppose I could try it. It also sounds like there might be some jackson compatibility issues that would burn me anyway unless I also upgrade jackson.

[wilkinsona]

I would be referring to having SpringBoot 2.7.x use snakeyaml 2.0

The issue to which I already linked answer this.

I scanned the ticket you refer to, it sounds like "one person tried it and it didn't break". I suppose I could try it.

The commit that closed that issue to which I already linked adds a test that verifies that it works for loading application.yaml.

there might be some jackson compatibility issues

Correct. Compatibility of code that the Spring Boot team does not maintain is out of the Spring Boot team's control.

[pexa-slee]

in your POM add in
<snakeyaml.version>2.0</snakeyaml.version>

[swiss-chris]

We're using Spring Boot 3.1.5 in many projects. If I look at the spring-boot-dependencies artifact for this version, I still see <snakeyaml.version>1.33</snakeyaml.version>

when are you planning to change this to 2.0, so that we don't have to temporarily patch this maven property in all our projects (and then remember to remove it again in the future) ?

[bclozel]

@swiss-chris Spring Boot 3.2.0, see #37331

[swiss-chris]

@bclozel The PR you linked has a commit which upgrades snakeyaml 2.1 to library("SnakeYAML", "2.2"). My problem seems to be a different one. I would like <snakeyaml.version>2.0</snakeyaml.version> inside spring-boot-dependencies of Spring Boot 3.x.

[bclozel]

@swiss-chris we've upgraded to the latest SnakeYaml minor version (2.2) in Spring Boot 3.2. You can check the dependencies POM here. The issue I've pointed you to does just that, upgrading the SnakeYaml version in our dependency management.

[swiss-chris]

@bclozel thanks for the clarification. As Spring Boot 3.2 is already in RC2, I assume it will be in GA soon ... (?).

[bclozel]

Yes, it will be out soon. You can check our release dates on the milestone page and on our public release calendar.

[swiss-chris]

Awesome!