Stored-Velocity-SSTI zu RCE über ConceptReferenceRange

Concept Reference Ranges in OpenMRS führen einen criteria-String mit, damit ein Bereich bedingt gelten kann, etwa nur für Erwachsene oder nur in einem bestimmten klinischen Zustand. Dieser Kriterien-String liegt in der Datenbank und wird als Apache-Velocity-Template ausgewertet. Die auswertende Engine wird pro Aufruf neu erzeugt und ausschließlich mit Logging-Properties initialisiert.

VelocityContext velocityContext = new VelocityContext();
velocityContext.put("fn", this);
velocityContext.put("obs", obs);
velocityContext.put("patient", obs.getPerson());

VelocityEngine velocityEngine = new VelocityEngine();
try {
	Properties props = new Properties();
	props.put("runtime.log.logsystem.class", Log4JLogChute.class.getName());
	props.put("runtime.log.logsystem.log4j.category", "velocity");
	props.put("runtime.log.logsystem.log4j.logger", "velocity");
	velocityEngine.init(props);
}
catch (Exception e) {
	throw new APIException("Failed to create the velocity engine: " + e.getMessage(), e);
}

StringWriter writer = new StringWriter();
String wrappedCriteria = "#set( $criteria = " + criteria + " )$criteria";

try {
	velocityEngine.evaluate(velocityContext, writer, ConceptReferenceRangeUtility.class.getName(), wrappedCriteria);
	return Boolean.parseBoolean(writer.toString());
}

Die Property-Liste enthält keinen Eintrag introspector.uberspect.class, Velocity fällt also auf seine Standardimplementierung UberspectImpl zurück. Diese filtert die Introspection nicht: Die Sperrlisten des SecureUberspector, die Template-Ausdrücke von java.lang.Class, java.lang.Runtime und java.lang.ProcessBuilder fernhalten, greifen nicht. Jedes in den Kontext gelegte Objekt ist damit für beliebige Methodenaufrufe erreichbar, getClass() eingeschlossen, und von einem Class-Handle aus erreicht ein Template-Ausdruck über Reflection den Rest der JVM. Der Kriterien-String wird unverändert in das Template einkonkateniert, der gespeicherte Wert ist also der Ausdruck.

Reflection ist der Weg zur Codeausführung, für den Abfluss von Patientendaten ist sie aber nicht nötig. Bereits die Kontextobjekte legen den Datensatz unmittelbar offen:

Ausgelöst wird die Auswertung nicht von der Person, die die Kriterien hinterlegt hat. Sie läuft bei der Validierung einer Observation, also bei derjenigen Person oder Integration, die als Nächste eine Observation gegen das betroffene Concept erfasst.

ConceptReferenceRangeUtility referenceRangeUtility = new ConceptReferenceRangeUtility();
List<ConceptReferenceRange> validRanges = new ArrayList<>();

for (ConceptReferenceRange referenceRange : referenceRanges) {
	if (referenceRangeUtility.evaluateCriteria(StringEscapeUtils.unescapeHtml4(referenceRange.getCriteria()), obs)) {

Der gespeicherte String läuft auf dem Weg zur Auswertung durch StringEscapeUtils.unescapeHtml4(), eine beim Speichern angewandte HTML-Entity-Kodierung wird also wieder rückgängig gemacht. Jede Eingabefilterung, die sich auf die escapte Form verlässt, übersteht diesen Umlauf nicht. In 2.8.5 ist die Aufrufstelle von ObsValidator nach ConceptServiceImpl gewandert; die Sink-Stelle und die fehlende Introspection-Policy sind unverändert.

Beschrieben wird das Kriterien-Feld über das Concept-Formular der Legacy-UI unter /dictionary/concept.form, die übliche Oberfläche für die Pflege des Concept-Dictionary und auf praktisch jedem Deployment vorhanden. ConceptFormValidator prüft die numerischen Grenzen einer Reference Range und sieht sich den Inhalt der Kriterien überhaupt nicht an, der String erreicht die Datenbank also so, wie er getippt wurde. Erforderlich ist die Berechtigung Manage Concepts, die der OpenMRS Implementers' Guide den Rollen Data Assistant, Data Manager und Informatics Manager zuweist. Es ist eine Content-Management-Berechtigung von Datenerfassungs- und Aufsichtspersonal, keine administrative: kein Superuser, kein System Developer.

Wir haben die vollständige Kette auf OpenMRS Core 2.8.4 mit webservices.rest 2.50.0 und legacyui 2.0.0 bestätigt. Der Test legt eine Rolle mit Manage Concepts und den zugehörigen Leseberechtigungen an, erzeugt eine Person in dieser Rolle, hinterlegt als diese Person über das Concept-Formular einen Kriterien-Payload und erfasst anschließend als anderer Nutzer über die REST-API eine Observation gegen das Concept. Die Ausführung wird durch eine ausgehende Anfrage des Serverprozesses an einen lokalen Listener bestätigt.

[*] Phase 1: Creating low-privilege user (as admin)
[+] Role created: PoC Clerk
    Privileges: Get Concept Datatypes, Manage Concepts, ...
[+] User created: clerk<id>

[*] Phase 2: Planting criteria as 'clerk<id>'
[+] Authenticated as 'clerk<id>'
[+] Concept created: <uuid>

[*] Phase 3: Recording an observation
    LISTEN 0.0.0.0:9999
    POST /openmrs/ws/rest/v1/obs

  Code execution confirmed via HTTP callback
    FROM: concept dictionary editor (data clerk)
    TO:   arbitrary code execution (Tomcat process)

Der Payload verbleibt in der Tabelle concept_reference_range und läuft bei jeder weiteren Observation gegen dieses Concept erneut, für jede Person und jeden API-Client, über Neustarts hinweg. Im Datensatz der Observation weist nichts darauf hin, dass eine Auswertung stattgefunden hat.

OpenMRS hat nicht den von uns vorgeschlagenen SecureUberspector ergänzt. Velocity wurde aus diesem Pfad vollständig entfernt und durch eine Spring-SpEL-Auswertung ersetzt, die ein SimpleEvaluationContext beschränkt.

private static final SimpleEvaluationContext EVAL_CONTEXT = SimpleEvaluationContext
        .forPropertyAccessors(new MapAccessor(), DataBindingPropertyAccessor.forReadOnlyAccess())
        .withMethodResolvers(DataBindingMethodResolver.forInstanceMethodInvocation()).build();

SimpleEvaluationContext ist Springs bewusst reduzierter Kontext: keine Bean-Referenzen, keine Typ-Referenzen und damit kein Weg von einem Ausdruck zu Class oder zu beliebigen Konstruktoren. Der Property-Zugriff ist read-only, und Methodenaufrufe sind auf Instanzmethoden der tatsächlich gebundenen Objekte beschränkt. Die zuvor als $fn bereitgestellten Hilfsfunktionen wurden zudem aus der Utility-Klasse in eine eigene Klasse CriteriaFunctions verschoben, mit einem Kommentar zur Begründung: So ist evaluateCriteria selbst aus einem Ausdruck heraus nicht mehr aufrufbar. Die Änderung ging als Commit 0801023b am 08.04.2026 ein und erschien am 10.04.2026 in 2.8.6, drei Wochen vor Veröffentlichung des Advisories.