_{Shortlink zu dieser Seite: https://tra.fo/spring4shell}

Am 30.03. wurde eine Lücke im Spring Framework bekannt (Spring4Shell). Auf dem Blog "CyberKendra" wurde erstmals darüber berichtet, eine weitere Quelle ist das Blog von "LunaSec". Zum aktuellen Zeitpunkt existieren noch recht wenige Informationen und auch keine Fehlerbehebung auf Seiten des Spring Frameworks. Es wird jedoch bereits von aktiven Angriffen auf vulnerable Systeme berichtet, insofern ist Vorsicht geboten.

CVEs

CVE-2022-22965 (31.03.2022)

Welche Voraussetzungen müssen für die Ausnutzbarkeit der Lücke erfüllt sein?

• Einsatz von JDK >= 9.x
• Einsatz von Spring Core, insbesondere die Verwendung der spring-beans-*.jar -Bibliothek.

• Verwendung von Spring-Beans Parameter-Binding für nicht-triviale Typen in Spring-WebMVC- oder Rest-Controllern. Beispiel:

  ...	
  	@RequestMapping("/rapid7")
  	public void vulnerable(HelloWorld model) {
  	}
  ...

Die Lücke kann sowohl kundeneigenen Integrationscode als auch durch levigo bereitgestellten Code betreffen. Eine Analyse hinsichtlich der einzelnen Produkte finden Sie im Folgenden.

Was kann gegenwärtig zur Beseitigung der Bedrohung getan werden?

Derzeit existiert noch kein offizieller Patch für die Lücke. Es ist jedoch davon auszugehen, dass dieser in den kommenden Stunden verfügbar sein wird. Einstweilen sollten folgende Maßnahmen ergriffen werden:

• Betroffene Anwendungen können ggf. als kurzfristige Maßnahme gepatcht werden, indem folgende Klasse der Anwendung hinzugefügt wird:

   Quelle erweitern

  import org.springframework.core.Ordered;
  import org.springframework.core.annotation.Order;
  import org.springframework.web.bind.WebDataBinder;
  import org.springframework.web.bind.annotation.ControllerAdvice;
  import org.springframework.web.bind.annotation.InitBinder;
  
  @ControllerAdvice
  @Order(10000)
  public class BinderControllerAdvice {
      @InitBinder
      public void setAllowedFields(WebDataBinder dataBinder) {
          // This code protects Spring Core from a "Remote Code Execution" attack (dubbed "Spring4Shell").
          // By applying this mitigation, you prevent the "Class Loader Manipulation" attack vector from firing.
          // For more details, see this post: https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
          String[] denylist = new String[]{"class.*", "Class.*", "*.class.*", "*.Class.*"};
          dataBinder.setDisallowedFields(denylist);
      }
  }

  Die Klasse muss dabei in einem package-Pfad liegen, der von Spring für das automatische Scanning aktiviert wurde. In unseren Beispielen könnte dies z.B. der Pfad sein, in dem bereits andere Spring-Konfigurationen wie SecurityConfig  usw. liegen.
  Sollte die betreffende Anwendung bereits anderweitig @InitBinder verwenden, was bei unseren Produkten standardmäßig nicht der Fall ist, so muss die Konfiguration der disallowedFields an allen Stellen erfolgen.

Welche weiteren Maßnahmen sollten ergriffen werden?

• Gründliche Analyse der vorhandenen Infrastruktur auf Systeme, die die Voraussetzungen für die Angreifbarkeit erfüllen.
• Dies betrifft insbesondere solche Systeme, die öffentlich erreichbar sind und/oder deren Endpoints ohne Authentisierung aufgerufen werden können.

Was bedeutet das für die einzelnen jadice- und neverpile-Produkte?

jadice web toolkit

Die problematische Dependency spring-beans kommt durch die Verwendung von spring-context in die Anwendung. Wir gehen daher davon aus, das potenziell alle Spring-basierten Integrationen zumindest die betroffene Dependency im Classpath haben. Parameter-Binding wird jedoch von den jadice-Klassen nicht verwendet.

Bitte prüfen Sie, ob Ihr Integrationscode eine Logik ähnlich dem oben genannten Beispiel verwendet. 

jadice document platform und jadice Swing-viewer

Nicht betroffen.

jadice server

Soweit wir es bis jetzt einschätzen, ist der jadice server 5 nicht unmittelbar von den Sicherheitslücken betroffen. Die Schnittstellen bauen nicht auf Spring MVC bzw. Spring Webflux auf, sondern auf JAX-WS bzw. JAX-RS. Zusätzlich wird die Applikation auch nicht als WAR verpackt in der Distribution ausgeliefert, sondern als Sammlung von JARs, die mittels eines Service-Wrappers ausgeführt werden. Auch bei den Sicherheitslücken, die unter "Spring4Shell" subsummiert werden, ist aktuell keine Sicherheitslücke im Server bekannt.

Folgende Bedingungen für eine Ausnutzung von CVE-2022-22965 sind bekannt, die nach aktuellem Kenntnisstand ALLE gleichzeitig gegeben sein müssen: JDK 9 oder höher Apache Tomcat als Servlet Container Packetiert als WAR (trifft nicht zu) spring-webmvc oder spring-webflux als Abhängigkeiten (trifft beim jadice server 5 nicht zu) Spring Framework Version 5.3.0 bis 5.3.17 bzw. 5.2.0 bis 5.2.19 und älter sind betroffen In unseren bisherigen Tests konnten wir die Sicherheitslücke CVE-2022-22965 nicht erfolgreich ausnutzen, das heißt aber nicht, dass nicht doch irgendeine Möglichkeit gefunden werden kann. Um hier sicherzugehen, haben wir gestern daher einen Sicherheitsupdate für den jadice server mit Version 5.12.7.1 veröffentlicht.

Wir behalten die Lage rund um das Thema CVE-2022-22965 und den anderen Themen unter dem Sammelbegriff "Spring4Shell" im Auge und werden auch hierzu wieder Updates auf dieser Knowledge Base Seite veröffentlichen.

Cloud-Variante: Erste Images sind hier bereits neu erstellt worden. Updates hierzu in Kürze (01.04.2022 - 09:29).

neverpile fusion

Neverpile fusion enthält Rest-Controller, die die vulnerable Funktionalität von Spring benutzen. Da fusion JDK >=11 voraussetzt, ist davon auszugehen, dass Installationen von der Lücke betroffen sind. Allerdings dürfte in den allermeisten Fällen fusion so konfiguriert sein, dass für den Zugriff auf die betroffenen Endpoints generell eine Authentisierung erforderlich ist, sodass eine Ausnutzbarkeit nur durch bereits erfolgreich authentisierte Benutzer gegeben ist.

Sobald eine Spring-Version verfügbar ist, die die Lücke behebt, werden wir aktualisierte Versionen von neverpile fusion zur Verfügung stellen.

neverpile eureka

Neverpile eureka enthält Rest-Controller, die die vulnerable Funktionalität von Spring benutzen. Da eureka JDK >=11 voraussetzt, ist davon auszugehen, dass Installationen von der Lücke betroffen sind. Allerdings dürfte in den allermeisten Fällen eureka so konfiguriert sein, dass für den Zugriff auf die betroffenen Endpoints generell eine Authentisierung erforderlich ist, sodass eine Ausnutzbarkeit nur durch bereits erfolgreich authentisierte Benutzer gegeben ist.

Sobald eine Spring-Version verfügbar ist, die die Lücke behebt, werden wir aktualisierte Versionen von neverpile eureka zur Verfügung stellen.