38807

Schweregrad: Mittel
Erstellungsdatum: 23. August 2024
CWE-290: Umgehung der Authentifizierung durch Spoofing
CWE-347: Unzulässige Überprüfung einer kryptografischen Signatur
Betrifft:^Spring® Boot-Versionen: alle Open-Source-Versionen unter 3.2.0, mit Ausnahme von 2.7.18.tuxcare.4+
CVSS:CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N

Dieses CVE wurde vom TuxCare-Team behoben und
ein Patch wurde für^Spring®- Benutzer an ELS geliefert.

Entdecken Sie ELS for^Spring®

Folgen Sie uns auf Social

Übersicht

^Spring® Boot ist ein auf dem^Spring® Framework aufbauendes Framework, das die Entwicklung eigenständiger, produktionsreifer^{Spring®-Anwendungen} vereinfacht. Es eliminiert einen Großteil der bei herkömmlichen^{Spring®-Anwendungen} erforderlichen Standardkonfigurationen, indem es automatische Konfiguration, festgelegte Standardeinstellungen und eingebettete Server bietet.

Der^Spring® Boot Loader ist eine Komponente von ^Spring® Boot, die für das Starten von^Spring® Boot-Anwendungen zuständig ist, die als ausführbare JAR- oder WAR-Dateien gepackt sind. Er ermöglicht Entwicklern, ihre Anwendungen mit java -jar auszuführen, ohne dass ein externer Anwendungsserver oder eine Classpath-Konfiguration erforderlich ist.

Authentication Bypass by Spoofing ist eine Schwachstelle, die durch falsch implementierte Authentifizierungsverfahren verursacht wird, die Spoofing-Angriffen ausgesetzt sind. Sie kann es einem Angreifer ermöglichen, auf Ressourcen zuzugreifen, die sonst ohne ordnungsgemäße Authentifizierung nicht zugänglich sind.

Eine unsachgemäße Überprüfung der kryptografischen Signatur findet statt, wenn das Produkt die kryptografische Signatur von Daten nicht oder nicht korrekt überprüft. Ein Angreifer könnte Zugang zu sensiblen Daten erhalten und möglicherweise nicht autorisierten Code ausführen.

CVE-2024-38807 ist eine Schwachstelle mittlerer Schwere, die in den Komponenten spring-boot-loader und spring-boot-loader-classic von^{Spring® Boot} identifiziert wurde. Insbesondere Anwendungen, die diese Komponenten verwenden und benutzerdefinierten Code für die Signaturprüfung von verschachtelten JAR-Dateien implementieren, können anfällig für Signaturfälschungen sein. Das bedeutet, dass Inhalte, die scheinbar von einer Entität signiert wurden, in Wirklichkeit von einer anderen Entität signiert worden sein könnten, wodurch potenziell bösartiger Code unter dem Deckmantel vertrauenswürdiger Inhalte ausgeführt werden könnte.

Dieses Problem betrifft mehrere Versionen von:

org.springframework.boot " spring-boot-loader-Paket,

org.springframework.boot " spring-boot-loader-classic Paket.

Dossier Schwachstellen
CVE-ID	38807
Schweregrad	Mittel: 6,3
CWE-ID und Name	CWE-290: Umgehung der Authentifizierung durch Spoofing CWE-347: Unzulässige Überprüfung einer kryptografischen Signatur
Betroffenes Projekt	^Spring® -Stiefel
Betroffene Pakete	spring-boot-loader spring-boot-loader-classic
Betroffene Versionen	<2.7.0;2.7.21>, <3.0.0;3.0.16>, <3.1.0;3.1.12>, <3.2.0;3.2.8>, <3.3.0;3.3.2>
NVD Veröffentlichungsdatum	23. August 2024
TuxCare Fixtermin	4. Februar 2025
TuxCare feste Version	2.7.18tuxcare.4

Detaillierte Untersuchung von38807

Betroffenes Produkt:^Spring® Boot
Betroffene Pakete:
- spring-boot-loader
- spring-boot-loader-classic
Betroffene Versionen:
- 2.7.0 – 2.7.21
- 3.0.0 – 3.0.16
- 3.1.0 – 3.1.12
- 3.2.0 – 3.2.8
- 3.3.0 – 3.3.2
GitHub-Repository: https://github.com/spring-projects/spring-boot
Veröffentlichte Pakete:

https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-loader

https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-loader-classic

Behoben in: ELS for^Spring® Boot v2.7.18.TuxCare.4, das auf der letzten Open-Source-Community-Version 2.7.18 als Basis basiert, auf die alle TuxCare-Patches angewendet wurden.

Informationen zur Schwachstelle

^Spring® Boot-Anwendungen, die mit dem ^Spring® Boot Loader gepackt sind, verwenden einen benutzerdefinierten Klassenlader, um Anwendungen aus einer „Fat JAR” (d. h. mit allen enthaltenen Abhängigkeiten) zu starten. Diese JAR enthält verschachtelte JARs innerhalb von /BOOT-INF/lib.

Die Schwachstelle liegt in der Art und Weise, wie Javas Signaturprüfungsmechanismus für diese verschachtelten JARs gehandhabt wird. Wenn eine Anwendung versucht, die digitale Signatur eines verschachtelten JAR mithilfe von Standard-JDK-APIs zu überprüfen, könnte die Überprüfung fälschlicherweise erfolgreich sein, selbst wenn das verschachtelte JAR:

nicht von der erwarteten Stelle unterzeichnet wurde, oder
nach seiner Unterzeichnung manipuliert wurde.

Dies liegt daran, dass der^Spring® Boot Loader beim Extrahieren und Laden verschachtelter JAR-Dateien den Verifizierungskontext der signierten JAR-Datei nicht vollständig beibehält.

Dies hat keine Auswirkungen auf die meisten^Spring® Boot-Benutzer, es sei denn, sie implementieren explizit eine benutzerdefinierte Validierungslogik für digitale Signaturen für verschachtelte JAR-Dateien.

Warum ist das ein Problem?

^Spring® Boot packt Anwendungen mithilfe von spring-boot-loader in eigenständige JAR-Dateien, darunter:

Anwendungsklassen(BOOT-INF/classes)
Abhängigkeiten(BOOT-INF/lib als verschachtelte JARs)

Wenn eine Organisation versucht, digitale Signaturen auf diesen verschachtelten JARs zu verifizieren (z.B. um auf Manipulationen zu prüfen oder das Vertrauen zu verifizieren), kann die Verifizierung stillschweigend passieren, selbst wenn:

Das verschachtelte JAR wurde geändert
Die Signatur wurde von einem unerwarteten oder böswilligen Unterzeichner erstellt

Und warum? Weil:

Das Java JAR-Signaturmodell wurde nicht für verschachtelte JARs entwickelt.
spring-boot-loader extrahiert und lädt JARs , ohne den ursprünglichen Signaturprüfungskontext zu erhalten

Auswirkungen auf die reale Welt

Aufschlüsselung des Vertrauens in der Lieferkette
- Sie denken, dass Sie nur vertrauenswürdige Abhängigkeiten laden (z. B. von Ihrem Anbieter signiert), aber ein Angreifer könnte ein JAR ersetzen, und die Anwendung könnte es fälschlicherweise als verifiziert melden.
Sicherheitstools können versagen
- Benutzerdefinierte Logik, Sicherheitsscanner oder Laufzeitüberprüfungen, die JarFile-APIs verwenden, können geänderte verschachtelte Inhalte falsch validieren.
Insider-Bedrohung oder Verteilungsrisiko
- Eine kompromittierte CI/CD-Pipeline könnte geänderte JARs einschleusen, ohne dass Sie dies durch Signaturprüfungen bemerken würden.

Beispiel-Szenario

Eine^Spring® Boot-App überprüft eine verschachtelte JAR-Datei (z. B. json-lib.jar) mithilfe von JarEntry.getCertificates() und erwartet dabei eine vertrauenswürdige Signatur.
Eine modifizierte oder bösartige Version von json-lib.jar wird gebündelt.
Da es über den benutzerdefinierten Klassenlader von^{Spring® Boot} geladen wird, geben die Signatur-APIs von Java eine erfolgreiche Überprüfung zurück.
Die Anwendung führt nicht vertrauenswürdigen Code aus und hält ihn für sicher.

Warum es subtil, aber gefährlich ist

Die meisten Anwendungen sind nicht betroffen, da sie keine JAR-Signaturen validieren.
In sicherheitssensiblen Umgebungen (z. B. im Bankwesen, im Verteidigungsbereich oder auf Händlermärkten) untergräbt dies jedoch die Integritätsprüfungen, was zu einer möglichen Codeausführung oder Datenkompromittierung führen kann.

Milderung

^Spring® Boot 2.7.x wird von der Open-Source-Community nicht mehr unterstützt, da sein End-of-Life-Datum am 30.06.2023 war. Das bedeutet lediglich, dass Versionen ab diesem Datum keine Updates mehr erhalten, um dieses Problem zu beheben.

‍Benutzer der betroffenen Komponenten sollten eine der folgenden Abhilfemaßnahmen anwenden:

Nutzen Sie den Endless Lifecycle Support von TuxCare, der den regulären EoL-Sicherheitssupport der Community erweitert, und spielen Sie dann einfach unsere Patches ein.
Aktualisieren Sie auf die Open-Source-Community-Version 3.3.3+ und nehmen Sie das Risiko in Kauf, ab dem 30. Juni 2025 keine weiteren Sicherheitsupdates mehr von der Community zu erhalten.
Alternativ können Sie ein Upgrade auf die neuesten, besten unterstützten Open-Source-Versionen^{des Spring®} Frameworks durchführen, die nicht betroffen sind, z. B. 3.4.x, und bis Ende 2025 Community-Support erhalten.
Verlassen Sie sich nicht auf die Signaturprüfung für verschachtelte JARs, es sei denn, Sie verwenden vertrauenswürdige Paketierungs- und Lademechanismen.
Verwenden Sie Sicherheitstools auf Betriebssystemebene oder externe Prüfer für die JAR-Integrität.

Benötigen Sie eine Lösung für diese Sicherheitslücke für eine andere^Spring® Framework-Version? Wenn ja, kontaktieren Sie uns bitte, wir helfen Ihnen gerne weiter!