OGNL: Obejście listy blokowanych trybu rygorystycznego wywoływania przez proxy refleksji java.lang.reflect

Podsumowanie

Opcjonalny tryb bardziej rygorystycznego wywoływania (stricter invocation) w OGNL utrzymuje listę blokowanych, która zapobiega bezpośredniemu wywoływaniu przez wyrażenia metod na niebezpiecznych klasach, takich jak Runtime, ProcessBuilder oraz ClassLoader. Lista blokowanych filtruje operacje na podstawie klasy deklarującej metodę wywoływaną przez OGNL. Ponieważ klasa java.lang.reflect.Method (oraz Constructor/Field) nie znajdowały się na tej liście, wyrażenie może użyć mechanizmu refleksji jako proxy — someMethod.invoke(target, args) — aby dotrzeć do zablokowanej metody. Rzeczywiste wywołanie (np. ProcessBuilder.start()) wykonuje się wówczas wewnątrz mechanizmów refleksji JDK i nie przechodzi ponownie przez metodę invokeMethod biblioteki OGNL, przez co lista blokowanych go nie wychwytuje.

Dowód koncepcji (PoC)

W domyślnym kontekście OGNL (dostęp wyłącznie do składowych publicznych, włączony tryb bardziej rygorystycznego wywoływania) poniższe wyrażenie tworzy plik, mimo że bezpośrednie wywołanie new ProcessBuilder(...).start() jest zablokowane:

(#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))

Wpływ i zakres — ważne informacje

Poprawka ta stanowi wzmocnienie pomocniczej warstwy wielopoziomowej ochrony (defense-in-depth), a nie naruszenie głównej granicy bezpieczeństwa OGNL.

W OGNL lista blokowanych trybu rygorystycznego wywoływania jest zabezpieczeniem drugorzędnym. Główną barierą kontroli dostępu jest implementacja MemberAccess dostarczana przez integrujący framework lub aplikację, którą OGNL odpytuje przy każdym wywołaniu konstruktora i metody. Frameworki oceniające niezaufane wyrażenia powinny konfigurować restrykcyjny MemberAccess — na przykład implementację SecurityMemberAccess w Apache Struts, która wyklucza niebezpieczne klasy oraz pakiet java.lang.reflect. Przy takim MemberAccess powyższy PoC jest blokowany już na pierwszym etapie (konstruktor new ProcessBuilder(...)), zanim refleksja w ogóle stanie się dostępna.

Domyślny kontekst dostarczany z OGNL celowo zezwala na dostęp do wszystkich publicznych elementów składowych i nie został zaprojektowany jako piaskownica (sandbox) dla niezaufanych danych wejściowych. Aplikacja, która przetwarza wyrażenia kontrolowane przez atakującego przy takich domyślnych, liberalnych uprawnieniach, posiada już wiele innych dróg do wykonania kodu, a niniejsza technika nie jest niezbędna do osiągnięcia tego celu.

Problem dotyczy aplikacji tylko wtedy, gdy spełnione są wszystkie poniższe warunki:

1. Aplikacja przetwarza niezaufane wyrażenia OGNL kontrolowane przez atakującego (1).
2. Używa domyślnej, liberalnej implementacji MemberAccess OGNL (lub równoważnie permisywnej, która dopuszcza java.lang.reflect) (2).
3. Polega wyłącznie na liście blokowanych trybu rygorystycznego wywoływania jako na mechanizmie piaskownicy (3).

Prawidłowo skonfigurowane wdrożenia — w tym Apache Struts z mechanizmem SecurityMemberAccess — nie są narażone. Właściwą ochroną w scenariuszach z niezaufanymi wyrażeniami pozostaje poprawnie skonfigurowany MemberAccess; lista blokowanych nie powinna być traktowana jako sandbox.

Rozwiązanie

Klasy java.lang.reflect.Method, java.lang.reflect.Constructor i java.lang.reflect.Field zostały dodane do listy blokowanych w trybie rygorystycznym, dzięki czemu obiekty refleksji nie mogą być już wykorzystywane jako proxy do wywołań w tym trybie. Zweryfikowano, że ścieżka z użyciem java.lang.invoke.MethodHandle nie podlega wykorzystaniu (jej polimorficzne pod względem sygnatury metody invoke/invokeExact kończą się błędem w wywołaniach opartych na refleksji w OGNL), w związku z czym dodawanie kolejnych klas nie było konieczne.

Podziękowania

Zgłoszone w ramach odpowiedzialnego ujawniania przez Tidelift przez: 毛锐 (youyi.mr@alibaba-inc.com).