VxRail: Обхідний шлях VxRail Manager для усунення вразливості Apache Log4Shell (CVE-2021-44228, CVE-2021-45046 і CVE-2021-4104)

Apache Software Foundation опублікував інформацію про критичну проблему віддаленого виконання коду бібліотеки Apache Log4j, яка відома як Log4Shell відповідно до консультативної бази даних GitHub (також детально описана в CVE-2021-44228, CVE-2021-45046 і CVE-2021-4104). VxRail Manager стикається з проблемою, описаною в вразливості.

Примітка: Повідомляється про два додаткові CVE, CVE-2021-45046 і CVE-2021-4104, які вказують на те, що початкова рекомендація щодо усунення проблеми, описаної в CVE-2021-44228 (Log4j 2.x), не є повним виправленням.

Щоб дізнатися більше про ці CVE, перегляньте наступні статті:

• Уразливості безпеки Apache Log4j
• CVE-2021-45046 (протокол Log4j 2.15)
• CVE-2021-4104 (протокол Log4j 1.2)

Примітка: Сценарій у цій статті оновлено до версії 1.1.2, яка включає виправлення, рекомендовані для всіх трьох CVE: CVE-2021-44228, CVE-2021-45046 і CVE-2021-4104.

У попередньому сценарії було виявлено додаткову проблему, яка може призвести до відновлення пошкодженого файлу в VxRail Manager із системного архіву. Цю проблему також було вирішено в цьому випуску.

Якщо ви використовували будь-які попередні сценарії, які були надані разом із цією статтею, завантажте останній сценарій (1.1.2) і запустіть його в VxRail Manager, щоб переконатися, що у вас є повне виправлення.
 

Вимоги та сфера застосування

Цей обсяг того, що охоплюються етапами виправлення ситуації в цій статті:

• Ця стаття застосовується до VxRail Manager у випусках VxRail 4.5.x, 4.7.x і 7.0.x, а також VxRail Manager у випусках VCF 3.x і 4.x.
• Наданий сценарій і кроки виправлення усувають вразливість лише у віртуальній машині пристрою VxRail Manager.
• Інші компоненти за межами VxRail Manager, такі як vCenter Server Appliance (vCSA), NSX тощо, повинні бути пом'якшені окремо, і їх немає в цьому сценарії.
• Крім того, скрипт не виправляє жодних програм або служб, запущених у віртуальних машинах, які можуть бути схильні до вразливості. Dell EMC рекомендує всім клієнтам звертатися до постачальників програм або програмного забезпечення щодо послуг, що працюють у віртуальних машинах, щоб переконатися, що це не вплине на них.

Посилання на постраждалі продукти VMware та потенційні обхідні шляхи детально описані в наступній статті VMware VMSA:

• Рекомендації з безпеки VMware VMSA-2021-0028

VMware надає скрипт для автоматизації виправлення в vCenter Server Appliance в наступній статті:

• Скрипт Python для автоматизації етапів обходу вразливості VMSA-2021-0028 на vCenter Server Appliance (87088)

До цієї статті додається файл fixlog4j-CVE-2021-44228-CVE-2021-45046-v-1-1-2.zip , який містить скрипт лише для VxRail Manager.
 

Релізи VxRail з виправленням у комплекті

Цю проблему вирішено в наступних випусках програмного забезпечення VxRail:

• Пакетне програмне забезпечення VxRail 7.0.320
• Програмне забезпечення для приладу VxRail 4.7.541
• Програмне забезпечення пристрою VxRail 4.5.471

Рекомендується оновитися до випуску програмного забезпечення VxRail, який включає виправлення.
Скрипт рекомендується для клієнтів, які не можуть оновитися відразу.

Примітка: Якщо вашим кластером VxRail 7.0.xxx керує віртуальний центр, який керує клієнтом, перегляньте наступну статтю для додаткових міркувань, які можуть застосовуватися:

• Dell EMC VxRail: Оновити зовнішній vCenter до 7.0 U3c або вище не вдається під час попередньої перевірки через те, що хости не оновлюються першими.

 

Етапи виправлення

Для усунення проблеми виконуються наступні дії:

1. Завантажте файл fixlog4j-CVE-2021-44228-CVE-2021-45046-v-1-1-2.zip, який додається до цієї статті.
2. Завантажте файл .zip у VxRail Manager, використовуючи mystic user over SCP (WinSCP є прикладом клієнта SCP, який можна використовувати).
3. Увійдіть у VxRail Manager, консоль віртуальної машини або SSH за допомогою mystic користувача. 
4. Змініть каталог на той, куди ви завантажили файл .zip, і розпакуйте його за допомогою команди 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. Зробіть скрипт виконуваним за допомогою команди chmod :

   mystic@vxrm:~> chmod +x fixlog4j-CVE-2021-44228-CVE-2021-45046.sh

6. Увійдіть як користувач root VxRail Manager за допомогою команди su :

   mystic@vxrm:~> su -
   Password:

7. Переконайтеся, що ви перебуваєте в тому ж каталозі, куди ви розпакували пакет script:

   vxrm:~ # cd /home/mystic
   vxrm:/home/mystic #

8. Запустіть скрипт:

   vxrm:/home/mystic # ./fixlog4j-CVE-2021-44228-CVE-2021-45046.sh

   Приклад виведення сценарію:

   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

    

Примітка: Може знадобитися від 5 до 10 хвилин для виправлення всіх файлів і запуску служб VxRail Manager.

Зачекайте принаймні 10 хвилин, якщо ви плануєте виконати будь-який із наведених нижче кроків ручної перевірки.

Існує кілька різних версій бібліотеки lib4j-core в залежності від релізу VxRail Manager.

Скрипт було розроблено для коректного виправлення VxRail Manager, незалежно від версії lib4j-ядра, яке входить до цієї версії VxRail Manager.

Наведений вище результат запуску скрипту може показувати оновлення різних файлів залежно від версії включеного ядра lib4j.

Примітка: Якщо ви виконуєте оновлення VxRail до іншої збірки VxRail, яка не містить виправлення, то цей сценарій потрібно запустити вдруге, щоб повторно застосувати виправлення.
 

 ПРИМІТКИ: Для повного пом'якшення наслідків для VxRail потрібно впровадити як обхідний шлях vCenter Server Appliance (vCSA) від VMware, так і виправлення в VxRail Manager, яке виконується цим сценарієм.

Посилання на статті VMware, що висвітлюють обхідні шляхи їхніх продуктів та виправлення, можна знайти в VxRail: Інформація про середовища Log4Shell (CVE-2021-44228) і VxRail.
 

Етапи перевірки

Щоб вирішити проблему, скрипт видаляє файл JndiLookup.class з jar-файлів

lib4j-core-*.Jar-файл — це формат упаковки Java для включення кількох класів, метаданих та інших програм Java в один файл. За своєю концепцією він схожий на файл .zip і базується на форматі .zip. Виконання скрипту перевіряє, що кожен jar-файл був успішно оновлений.

Щоб виконати ручну перевірку того, що скрипт спрацював, ви можете перевірити, чи файли jar log4j-core-* , присутні в VxRail Manager, все ще містять файл JndiLookup.class , який постраждав. Якщо це спрацювало, ви не повинні побачити виведення до наведених нижче команд, що підтверджує, що постраждалий файл JndiLookup.class більше не присутній у jar-файлі.

Примітка: Проблема з файлом JndiLookup.class вирішена в log4j-core-2.17.1.jar і більш пізніх версіях, тому спроба виконати кроки перевірки на цих jar-файлах показує, що файл JndiLookup.class присутній, але проблема не вирішена. Можна з упевненістю ігнорувати побачивши цей файл JndiLookup.class у фіксованих версіях log4j-core.
 

Перевірка за допомогою автоматизованої команди 

Наступну команду можна запустити в VxRail Manager, щоб просканувати всі log4j-core-xxxx.jar файли, присутні в VxRail Manager, і перевірити, чи містять вони файл 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

Вибірковий вихід (оновлена система):

/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

У наведеному вище прикладі файл JndiLookup.class відсутній в jar, тому скрипт спрацював, і перевірка пройшла успішно.

Нижче наведено приклад вихідних даних ураженої системи, який необхідно оновити:

/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

У наведеному вище прикладі файл JndiLookup.class , який зазнав впливу, все ще присутній у файлі jar log4j-core-2.13.3.jar.

Нижче наведено приклад виводу системи, яка має фіксовану або оновлену бібліотеку log4j-core, де перегляд файлу JndiLookup.class може бути проігнорований:

/usr/lib/vmware-marvin/marvind/webapps/ROOT/WEB-INF/lib/log4j-core-2.17.1.jar
     3158  2021-12-27 17:30   org/apache/logging/log4j/core/lookup/JndiLookup.class
/mystic/connectors/eservice/lib/log4j-core-2.17.1.jar
     3158  2021-12-27 17:30   org/apache/logging/log4j/core/lookup/JndiLookup.class
/mystic/connectors/cluster/lib/log4j-core-2.17.1.jar
     3158  2021-12-27 17:30   org/apache/logging/log4j/core/lookup/JndiLookup.class

У наведеному вище прикладі ви можете побачити файл JndiLookup.class у виводі, але вирішення проблеми знаходиться в log4j-core-2.17.1.jar.

 

Валідація з ручною перевіркою кожного файлу

Щоб швидко визначити будь-які log4j-core-xxxx.jar файли, присутні в VxRail Manager, запустіть наступну команду (вона також форматує вихідні дані в придатну для використання команду):

vxrm:/home/mystic # find / -name log4j-core*jar -print |grep -v log4jbak | awk '{print("unzip -l " $1 "|grep JndiLookup.class")}'

Приклад виходу:

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

З наведеного вище зразка виводу запустіть кожну команду вручну, щоб побачити, чи виявлять вони уражений файл 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 #

У наведеному вище прикладі файл JndiLookup.class відсутній в jar, тому скрипт спрацював, і перевірка пройшла успішно.

Примітка: Імена jar-файлів із наведеного вище зразка виводу можуть відрізнятися залежно від вашої версії VxRail Manager. Використовуйте зразок виводу, який ви отримуєте від наведеної вище команди пошуку . 

Приклад виводу для jar-файлу, який все ще зазнає впливу та містить уражений файл 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

У наведеному вище прикладі файл JndiLookup.class , який зазнав впливу, все ще присутній у файлі jar log4j-core-2.4.1.jar.

 

 ПРИМІТКИ: Ще одне нагадування про те, що для повного пом'якшення наслідків для VxRail потрібно реалізувати як обхідний шлях vCenter Server Appliance (vCSA) від VMware, так і виправлення в VxRail Manager, виконане цим сценарієм.