Spring Sicherheitslücke

[Raphael_]

Hallo,
Ich habe mir vor ca einer Woche diese Dependency geholt:

<plugin>
                <groupId>org.owasp</groupId>
                <artifactId>dependency-check-maven</artifactId>
                <version>8.2.1</version>
                <configuration>
                    <failBuildOnCVSS>8</failBuildOnCVSS>
                </configuration>
                <executions>
                    <execution>
                        <goals>
                            <goal>check</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>

Damit wollte ich checken, ob ich irgendwelche Bibliotheken verwende, die Anfällig sind. Ich habe direkt diese hier angezeigt bekommen: snakeyaml-1.33.jar: CVE-2022-1471(9.8)

Dann habe ich festgestellt, dass diese Sicherheitslücke direkt von Spring kommt. (Ich nutze 3.0.6) Jetzt stelle ich mir natürlich die Frage, wie kann das sein, dass da seit weit über einer Woche eine Sicherheitslücke von einem Score von 9.8 drinnen ist??? Warum wird das nicht gefixt und ist das normal???

 

[LimDul]

Weil es für Spring keine Lücke ist.

Man muss leider bei so was oft tief reindrillen um es zu verstehen:

Hi,

I know I’m late to the party and I wanted to put my 2 cents in, since it appears there is a lot of confusion regarding this CVE and I hope to understand both sides. I also apologize in advance if I slightly miss the mark.

The root of the issue is probably the misinterpretation that “it is safe by default”, while the sankeyaml advocates to use SafeConstructor for user provided input and the “poor CVE tooling” cannot distinguisish how the lib is exactly used, reporting “false positives”. It’s a perfect triangle where everyone is neither completely right nor wrong at the same time.

It's what it is now. Even if Spring and co. use this library correctly and are not vulnerable, CVE detection tools simply cannot distinguish usage. It’s not a trivial task either.

Perhaps if the Constructor was called PriviledgedConstructor in contrast to the SafeConstructor, and “deserialize/instaciate any class” was opt-in in yaml rather than the default, all of this would probably have been avoided. ...I think that's what triggered it all, the "default out-of-the-box usage", not how it's used "safely".

It is very nice to hear that a version 2.0 which reverses this default is planned.

Lastly, thank you very much for your time and effort in maintaining this software.

snakeyaml / snakeyaml / issues / #561 - CVE-2022-1471 (vulnerability in deserialization) — Bitbucket

bitbucket.org

Kurzum, so wie Spring snakeyaml nutzt, gibt es kein Problem. Der Fix ist auch erst in snakeyaml 2 drin - Aber das ist ein Major Upgrade:

Spring Boot 2.7.x (since 2.7.10) and 3.0.x (since 3.0.5) releases are compatible with SnakeYAML 2.0 but do not use it by default. They do not use 2.0 by default for backwards compatibility. SnakeYAML 2.0 was released after Spring Boot 2.7.0 and 3.0.0 were released and Spring Boot does not upgrade to new major versions of dependencies in its maintenance releases as doing so could be a breaking change depending on how an application itself and other dependencies are using SnakeYAML.

Is snakeyaml 2.0 added in the new Spring boot versions?

I see there is reference to snakeyaml 2.0 in the bugfixes of the new SPringBoot release 3.10-M2 & the older version, but when we look at the source code, we see that the snakeyaml library versi...

stackoverflow.com

Ich hab im letzten Projekt sehr viel Spaß mit diesen automatischen Dependency Checks gehabt - Die sind leider selten genau und man muss stark hinschauen, ob es wirklich ein Problem ist oder nicht. Der Score ist da nur ein Kriterium.

 

[khmarbaise]

Ich würde mal einfach versuchen die entsprechende Version von SnakeYAML zu definieren und dann mal schauen ob schwierigkeiten auftreten oder nicht...Ich vermute nein...