Die große Gefahr der Log4Shell-Sicherheitslücke ergab sich aus der Kombination der Risikofaktoren. Betrachten wir die wichtigsten:
1. Java-Sicherheitslücke liegt in Logging-Bibliothek.
Eine Logging-Bibliothek wie Log4J erscheint zunächst relativ harmlos. Im Vergleich mit Bibliotheken für Authentifizierung oder Verschlüsselung dürfte eine Logging-Bibliothek weniger kritisch beäugt werden.
2. Java wird breitflächig eingesetzt.
Ein Alleinstellungsmerkmal von Java als Sprache und Umgebung ist, dass Java auf so gut wie allen Plattformen läuft. Die Log4Shell-Sicherheitslücke betrifft daher eine enorm große Vielfalt an Programmen und Diensten. Ferner ist Java z. T. in Embedded-Systemen wie Routern und Internet-of-Things-Geräten integriert. Dazu gehören z. B. private Kameras und Smart-Home-Geräte.
3. Ein Stapel von Technologien ist involviert.
Die sicherheitsrelevante Problematik ergibt sich durch die Verkettung mehrerer Technologien. Erst die Kombination aus Log4J, JNDI, LDAP und String Substitutions führt zur Sicherheitslücke und eröffnet Angriffen Tür und Tor.
4. Exploit sickert auf tiefere Ebenen durch.
Betrifft eine Sicherheitslücke nur das verwundbare System, bleibt der Schaden im besten Fall lokalisiert. Stellen wir uns jedoch vor, dass ein Exploit-String über eine Weboberfläche entgegengenommen und geloggt wird. Eventuell wird der Exploit-String an darunterliegende Systeme weitergereicht und erst bei dortiger Auswertung aktiv.
5. Exploit-Strings sind schwer zu entdecken.