VxRail: Obejście dla programu VxRail Manager eliminujące lukę w zabezpieczeniach Apache Log4Shell (CVE-2021-44228, CVE-2021-45046 i CVE-2021-4104)

Apache Software Foundation opublikowało informacje na temat krytycznego problemu z luką w zabezpieczeniach wykonania kodu zdalnego biblioteki Apache Log4j, znanego jako Log4Shell zgodnie z bazą danych poradnika GitHub (opisane również w CVE-2021-44228, CVE-2021-45046 i CVE-2021-4104). Program VxRail Manager jest narażony na problem przedstawiony w tej luce bezpieczeństwa.

Uwaga: Zgłoszono dwa dodatkowe CVE, CVE-2021-45046 i CVE-2021-4104, wskazujące, że pierwotne zalecenie rozwiązania problemu opisanego w CVE-2021-44228 (Log4j 2.x) nie jest kompletną poprawką.

Aby uzyskać więcej informacji na temat tych CVE, zapoznaj się z następującymi artykułami:

• Luki w zabezpieczeniach Apache Log4j
• CVE-2021-45046       (Log4j 2.15)
• CVE-2021-4104         (Log4j 1.2)

Uwaga: Skrypt w tym artykule został zaktualizowany do wersji 1.1.2, która zawiera działania naprawcze zalecane dla wszystkich trzech CVE, CVE-2021-44228, CVE-2021-45046 i CVE-2021-4104.

W poprzednim skrypcie wykryto dodatkowy problem, który może spowodować przywrócenie pliku w programie VxRail Manager z archiwum systemu. Ten problem został również rozwiązany w tej wersji.

Jeśli korzystasz z wcześniejszych skryptów dostarczonych z tym artykułem, pobierz najnowszy skrypt (1.1.2) i uruchom go w programie VxRail Manager, aby upewnić się, że masz pełną poprawkę.
 

Wymagania i zakres

Zakres działań naprawczych zawartych w tym artykule to:

• Ten artykuł dotyczy VxRail Manager w wersjach VxRail 4.5.x, 4.7.x i 7.0.x wraz z oprogramowaniem VxRail Manager w wersjach VCF 3.x i 4.x.
• Przedstawione czynności skryptu i działań naprawczych naprawiają lukę w zabezpieczeniach tylko w maszynie wirtualnej VxRail Manager.
• Inne komponenty poza VxRail Manager, takie jak vCenter Server Appliance (vCSA), NSX itd., muszą być naprawiane oddzielnie i nie są ujęte w tym skrypcie.
• Ponadto skrypt nie naprawia żadnych aplikacji ani usług działających wewnątrz maszyn wirtualnych, które mogą być narażone na lukę w zabezpieczeniach. Firma Dell EMC zaleca wszystkim klientom, aby sprawdzić u swoich dostawców aplikacji lub oprogramowania usługi uruchomione w maszynach wirtualnych, aby upewnić się, że problem ich nie dotyczy.

Łącza do dotkniętych problemem produktów VMware i potencjalnych obejść są opisane w następującym artykule VMware VMSA:

• Poradnik zabezpieczeń VMware VMSA-2021-0028

Firma VMware udostępnia skrypt automatyzujący działania naprawcze w urządzeniu vCenter Server Appliance w następującym artykule:

• Skrypt Python automatyzujący obejście problemu z luką w zabezpieczeniach VMSA-2021-0028 na vCenter Server Appliance (87088)

Do tego artykułu dołączono plik fixlog4j-CVE-2021-44228-CVE-2021-45046-v-1-1-2.zip, który zawiera skrypt wyłącznie dla VxRail Manager.
 

Wersje VxRail z dołączoną poprawką

Ten problem został rozwiązany w następujących wersjach oprogramowania VxRail:

• Oprogramowanie pakietu VxRail 7.0.320
• Oprogramowanie urządzenia VxRail w wersji 4.7.541
• Oprogramowanie urządzenia VxRail w wersji 4.5.471

Zaleca się uaktualnienie do wersji oprogramowania VxRail, które zawierają poprawkę.
Skrypt jest zalecany dla klientów, którzy nie mogą dokonać natychmiastowej aktualizacji.

Uwaga: Jeśli klaster VxRail w wersji 7.0.xxx jest zarządzany przez vCenter obsługiwane przez klienta, należy zapoznać się z następującym artykułem w celu uzyskania dodatkowych informacji, które mogą mieć zastosowanie:

• Dell EMC VxRail: Aktualizacja zewnętrznego vCenter do wersji 7.0 U3c lub nowszej kończy się niepowodzeniem podczas wstępnej kontroli, ponieważ hosty nie są aktualizowane w pierwszej kolejności.

 

Czynności naprawcze

W celu rozwiązania problemu należy wykonać następujące czynności:

1. Pobierz plik fixlog4j-CVE-2021-44228-CVE-2021-45046-v-1-1-2.zip załączony do tego artykułu.
2. Prześlij plik .zip do programu VxRail Manager przy użyciu użytkownika mystic przez SCP (WinSCP jest przykładem klienta SCP, który można wykorzystać).
3. Zaloguj się do konsoli maszyny wirtualnej VxRail Manager lub nawiąż połączenie SSH z kontem mystic. 
4. Przejdź do katalogu, do którego przesłano plik .zip, i rozpakuj go przy użyciu polecenia unzip:
   mystic@vxrm:~> unzip fixlog4j-CVE-2021-44228-CVE-2021-45046-v-1-1-2.zip
   Archive:  fixlog4j-CVE-2021-44228-CVE-2021-45046-v-1-1-2.zip
     inflating: fixlog4j-CVE-2021-44228-CVE-2021-45046.sh
5. Ustaw skrypt jako wykonywalny przy użyciu polecenia chmod:
   mystic@vxrm:~> chmod +x fixlog4j-CVE-2021-44228-CVE-2021-45046.sh
6. Zaloguj się jako użytkownik root VxRail Manager za pomocą polecenia su:
   mystic@vxrm:~> su -
   Password:
7. Upewnij się, że znajdujesz się w tym samym katalogu, w którym rozpakowano skrypt z pakietu:
   vxrm:~ # cd /home/mystic
   vxrm:/home/mystic #
8. Uruchom skrypt:
   vxrm:/home/mystic # ./fixlog4j-CVE-2021-44228-CVE-2021-45046.sh

   Przykładowy wynik skryptu:
   Stop MARVIN and runjars service before patching the system
   
   /mystic/connectors/eservice/lib/log4j-core-2.13.0.jar is affected by CVE-2021-44228 and CVE-2021-45046, need to apply patch
   patching /mystic/connectors/eservice/lib/log4j-core-2.13.0.jar
   Successfully patched /mystic/connectors/eservice/lib/log4j-core-2.13.0.jar
   
   /mystic/connectors/cluster/lib/log4j-core-2.13.0.jar is affected by CVE-2021-44228 and CVE-2021-45046, need to apply patch
   patching /mystic/connectors/cluster/lib/log4j-core-2.13.0.jar
   Successfully patched /mystic/connectors/cluster/lib/log4j-core-2.13.0.jar
   
   To ensure there is no reload behavior, we need to pack the .war file as well.
   looks like /usr/lib/vmware-marvin/marvind/webapps/ROOT.war contains the bad log4j-core library WEB-INF/lib/log4j-core-2.13.0.jar
   Archive:  /usr/lib/vmware-marvin/marvind/webapps/ROOT.war
     inflating: WEB-INF/lib/log4j-core-2.13.0.jar
   Patching WEB-INF/lib/log4j-core-2.13.0.jar in /usr/lib/vmware-marvin/marvind/webapps/ROOT.war
   Repack /usr/lib/vmware-marvin/marvind/webapps/ROOT.war
   updating: WEB-INF/lib/log4j-core-2.13.0.jar (deflated 11%)
   Clean up the ROOT folder...
   
   Always apply a reboot of MARVIN and runjars services
   restart MARVIN
   MARVIN restart successfully
   restart runjars
   runjars restart successfully

Uwaga: Naprawa wszystkich plików i uruchomienie usług VxRail Manager może zająć od 5 do 10 minut.

Odczekaj co najmniej 10 minut, jeśli planujesz wykonać któryś z poniższych kroków weryfikacji ręcznej.

W zależności od wersji VxRail Manager istnieje kilka różnych wersji biblioteki lib4j-core.

Skrypt został opracowany tak, aby poprawnie korygował VxRail Manager, niezależnie od wersji lib4j-core, która jest dołączona do tej wersji programu VxRail Manager.

Powyższe dane wyjściowe po uruchomieniu skryptu mogą zawierać różne aktualizowane pliki w zależności od dołączonej wersji lib4j-core.

Uwaga: W przypadku wykonania uaktualnienia VxRail do innej kompilacji VxRail, która nie zawiera poprawki, skrypt musi zostać uruchomiony po raz drugi, aby ponownie zastosować rozwiązanie.
 

 UWAGA: Pełna korekta działania VxRail wymaga zarówno obejścia vCenter Server Appliance (vCSA) od firmy VMware, jak i korekty programu VxRail Manager, która jest realizowana przez omawiany skrypt.

Łącza do artykułów VMware omawiających obejścia problemów z ich produktami i poprawkami znajdują się w VxRail: Informacje na temat środowisk Log4Shell (CVE-2021-44228) i VxRail.
 

Czynności sprawdzające

W celu rozwiązania problemu skrypt usuwa plik JndiLookup.class z plików jar lib4j-core-*.

Plik jar to format pakietu Java, zawierający wiele klas, metadanych i innych programów Java w jednym pliku. Działa na zasadzie podobnej do pliku .zip i jest oparty na formacie .zip. Wykonanie skryptu sprawdza, czy każdy plik jar został pomyślnie zaktualizowany.

Aby wykonać ręczną weryfikację poprawnego działania skryptu można sprawdzić, czy pliki jar log4j-core-*, obecne w programie VxRail Manager, nadal zawierają problematyczny plik JndiLookup.class. Jeśli to zadziałało, nie powinny pojawić się żadne dane wyjściowe po wykonaniu poniższych poleceń, co potwierdza, że problematyczny plik JndiLookup.class nie jest już obecny w pliku jar.
 

Weryfikacja za pomocą polecenia zautomatyzowanego

W programie VxRail Manager można uruchomić następujące polecenie, aby przeskanować wszystkie pliki log4j-core-xxxx.jar obecne w VxRail Manager i sprawdzić czy zawierają problematyczny plik JndiLookup.class :

vxrm:/home/mystic # for myfile in `find / -name log4j-core*jar -print |grep -v log4jbak`; do echo $myfile; unzip -l $myfile | grep JndiLookup.class; done

Przykładowy wynik polecenia (system zaktualizowany):
/mystic/connectors/eservice/lib/log4j-core-2.13.0.jar
/mystic/connectors/cluster/lib/log4j-core-2.13.0.jar
/usr/lib/vmware-marvin/marvind/webapps/ROOT/WEB-INF/lib/log4j-core-2.13.0.jar

W powyższym przykładzie plik JndiLookup.class nie jest obecny w pliku jar, więc skrypt zadziałał i weryfikacja przebiegła pomyślnie.

Poniżej znajduje się wynik z problematycznego systemu, który należy zaktualizować:
/mystic/connectors/eservice/lib/log4j-core-2.13.3.jar
     2892  2020-05-10 12:08   org/apache/logging/log4j/core/lookup/JndiLookup.class
/mystic/connectors/cluster/lib/log4j-core-2.13.3.jar
     2892  2020-05-10 12:08   org/apache/logging/log4j/core/lookup/JndiLookup.class
/usr/lib/vmware-marvin/marvind/webapps/ROOT/WEB-INF/lib/log4j-core-2.13.3.jar
     2892  2020-05-10 12:08   org/apache/logging/log4j/core/lookup/JndiLookup.class

W przykładzue powyżej, problematyczny plikJndiLookup.class jest nadal obecny w pliku log4j-core-2.13.3.jar.
 

Weryfikacja z ręcznym sprawdzaniem każdego pliku

Aby szybko wyszukać wszystkie pliki log4j-core-xxxx.jar obecne w VxRail Manager, uruchom polecenie (formatuje ono również dane wyjściowe w postaci przydatnego polecenia):
vxrm:/home/mystic # find / -name log4j-core*jar -print |grep -v log4jbak | awk '{print("unzip -l " $1 "|grep JndiLookup.class")}'

Przykładowy wynik:
unzip -l /mystic/connectors/eservice/lib/log4j-core-2.13.0.jar|grep JndiLookup.class
unzip -l /mystic/connectors/cluster/lib/log4j-core-2.13.0.jar|grep JndiLookup.class
unzip -l /usr/lib/vmware-marvin/marvind/webapps/ROOT/WEB-INF/lib/log4j-core-2.13.0.jar|grep JndiLookup.class

Uruchom każdą komendę widoczną w przykładowym rezultacie powyżej, aby ręcznie sprawdzić czy wykryją one problematyczny plik JndiLookup.class:
vxrm:/home/mystic # unzip -l /mystic/connectors/eservice/lib/log4j-core-2.13.0.jar|grep JndiLookup.class
vxrm:/home/mystic #

vxrm:/home/mystic # unzip -l /mystic/connectors/cluster/lib/log4j-core-2.13.0.jar|grep JndiLookup.class
vxrm:/home/mystic #

vxrm:/home/mystic # unzip -l /usr/lib/vmware-marvin/marvind/webapps/ROOT/WEB-INF/lib/log4j-core-2.13.0.jar|grep JndiLookup.class
vxrm:/home/mystic #

W przykładzie powyżej plikJndiLookup.class nie jest obecny w pliku jar, więc skrypt zadziałał, a weryfikacja została pomyślnie zakończona.

Uwaga: Nazwy plików jar z powyższych przykładowych danych wyjściowych mogą się różnić w zależności od wersji programu VxRail Manager. Użyj przykładowego wyniku otrzymanego z powyższego polecenia find. 

Przykład wyniku dla pliku jar, który nadal jest zagrożony i zawiera problematyczny plik JndiLookup.class:

vxrm:/home/mystic # unzip -l /mystic/connectors/cluster/lib/log4j-core-2.4.1.jar |grep JndiLookup.class
2576 2015-10-08 17:50 org/apache/logging/log4j/core/lookup/JndiLookup.class

W powyższym przykładzie problematyczny plik JndiLookup.classjest nadal obecny w pliku jar log4j-core-2.4.1.jar.

 

 UWAGA: Kolejne przypomnienie, że pełna korekta działania VxRail wymaga zarówno obejścia vCenter Server Appliance (vCSA) od firmy VMware, jak i korekty programu VxRail Manager, realizowanej przez omawiany skrypt.