OGNL: Umgehung der Blockliste für strengere Methodenaufrufe über java.lang.reflect Reflection-Proxys

Zusammenfassung

Der optionale Modus für strengere Methodenaufrufe (stricter invocation) in OGNL führt eine Blockliste, die verhindert, dass Ausdrücke direkt Methoden auf gefährlichen Klassen wie Runtime, ProcessBuilder und ClassLoader aufrufen. Diese Blockliste filtert nach der deklarierenden Klasse der von OGNL aufgerufenen Methode. Da java.lang.reflect.Method (sowie Constructor/Field) nicht auf dieser Liste standen, kann ein Ausdruck Reflection als Proxy nutzen – beispielsweise someMethod.invoke(target, args) –, um eine blockierte Methode zu erreichen. Der tatsächliche Aufruf (z. B. ProcessBuilder.start()) wird anschließend innerhalb der Reflection-Mechanismen des JDK ausgeführt und durchläuft nicht erneut die OGNL-Methode invokeMethod, wodurch die Blockliste umgangen wird.

Machbarkeitsnachweis (Proof of Concept)

Im Standard-OGNL-Kontext (Zugriff nur auf öffentliche Member, Modus für strengere Aufrufe aktiviert) erstellt der folgende Ausdruck eine Datei, obwohl ein direkter Aufruf von new ProcessBuilder(...).start() blockiert ist:

(#pb=new java.lang.ProcessBuilder({"/usr/bin/touch","rce-proof.txt"}),
 #methods=@java.lang.ProcessBuilder@class.getMethods(),
 #names=#methods.{ #this.getName() },
 #startIdx=#names.indexOf("start"),
 #methods[#startIdx].invoke(#pb, null))

Auswirkungen und Umfang

Hierbei handelt es sich um eine Härtung einer nachgelagerten Verteidigungsebene (Defense-in-Depth) und nicht um einen Bruch der primären Sicherheitsgrenze von OGNL.

In OGNL stellt die Blockliste für strengere Aufrufe eine sekundäre Schutzmaßnahme dar. Die primäre Zugriffskontrolle ist die Implementierung von MemberAccess, die vom einbindenden Framework oder der Anwendung bereitgestellt und von OGNL bei jedem Konstruktor- und Methodenaufruf abgefragt wird. Frameworks, die nicht vertrauenswürdige Ausdrücke auswerten, sollten ein restriktives MemberAccess einrichten – wie etwa das SecurityMemberAccess von Apache Struts, das gefährliche Klassen sowie das Paket java.lang.reflect ausschließt. Bei Verwendung eines solchen MemberAccess wird dieser Proof of Concept bereits beim ersten Schritt (dem Konstruktor von new ProcessBuilder(...)) blockiert, noch bevor Reflection erreichbar ist.

Der mit OGNL ausgelieferte Standardkontext erlaubt standardmäßig alle öffentlichen Member und ist nicht dafür ausgelegt, nicht vertrauenswürdige Eingaben in einer Sandbox zu isolieren. Eine Anwendung, die vom Angreifer kontrollierte Ausdrücke mit diesen freizügigen Standardeinstellungen auswertet, bietet bereits zahlreiche Wege zur Codeausführung; dieses Verfahren ist dafür nicht zwingend erforderlich.

Eine Betroffenheit liegt nur vor, wenn alle folgenden Bedingungen erfüllt sind:

1. Die Anwendung wertet nicht vertrauenswürdige bzw. angreifergesteuerte OGNL-Ausdrücke aus (1).
2. Sie verwendet die standardmäßige, permissive MemberAccess-Implementierung von OGNL oder eine ähnlich freizügige Konfiguration, die java.lang.reflect erlaubt (2).
3. Sie verlässt sich auf die Blockliste für strengere Aufrufe als Sandbox-Mechanismus (3).

Ordnungsgemäß konfigurierte Systeme – einschließlich Apache Struts mit dessen SecurityMemberAccess – sind nicht betroffen. Der eigentliche Schutz bei der Verarbeitung nicht vertrauenswürdiger Ausdrücke bleibt ein korrekt konfiguriertes MemberAccess; die Blockliste sollte nicht als eigenständige Sandbox betrachtet werden.

Behebung

java.lang.reflect.Method, java.lang.reflect.Constructor und java.lang.reflect.Field wurden zur Blockliste für strengere Aufrufe hinzugefügt, sodass Reflection-Objekte im Modus für strengere Aufrufe nicht mehr als Aufruf-Proxys missbraucht werden können. Der Pfad über java.lang.invoke.MethodHandle erwies sich als nicht ausnutzbar (die signatur-polymorphen Methoden invoke/invokeExact schlagen über OGNLs reflexionsbasierte Aufrufe fehl), weshalb keine weiteren Klassen ergänzt werden mussten.

Danksagung

Verantwortungsvoll über Tidelift gemeldet von 毛锐 (youyi.mr@alibaba-inc.com).