Уязвимости Exim и последствия

kick

Предвестник
Administrator
За веру и верность форуму
Отец-основатель
Сообщения
6 972
Розыгрыши
22
Решения
1
Репутация
6 046
Реакции
6 831
Баллы
2 688
Предыстория, про уязвимость в Exim стало известно ещё 5-6 июня ( , ), там же прилагаются и патчи для исправления данной уязвимости.
Чуть позже исправленная версия появилась и в репозиториях OC и для обновления Exim достаточно выполнить пару команд взависимости от OC.

Для самостоятельного обновления в CentOS, по ssh выполните:
Bash:
yum update exim -y
service exim restart
Для самостоятельного обновления в Debian/Ubuntu, по ssh выполните:

Bash:
apt-get update
apt install exim4 -y
service exim4 restart
Так вот кто занимается самостоятельно администрированием и следит за всем, уже заранее обновились и привели в актуальное состояние софт, но есть и те, кто просто устанавливают и беззаботно работают, даже не подозревая, что могут быть последствия.

А теперь о последствиях, вчера днём ко мне обратился человек с на первый взгляд простой проблемой, ошибки в админке свидетельствовали, что проблемой может быть простое переполнение временного каталога.
Но, при детальном рассмотрении, места было предостаточно, однако была выявлена аномальная нагрузка на процессор и подозрительные процессы при просмотре в htop.
26160
Так как с таким я столкнулся впервые, пришлось воспользоваться поиском и это дало свои результаты, как оказалось это разновидность майнера, похожие случаи и способы лечения была найдены на китайских сайтах, но в нашем случае это оказалась уже модифицированная версия и распространяется по новому принципу и способом.
Что же, пришлось уделить время и проанализировать ситуацию, по прошествии какого-то времени и результату анализа был написал bash скрипт и проблему удалось решить самостоятельно.
Конечно же Вы скажете, что здесь должно быть описание, что как делалось и на основании чего, но я решил не делать этого, так как заглянув утром на Хабр, увидел - , что проблема - более глобальная и было затронуто достаточно серверов.
Так же кто захочет и не поленится почитать это всё, может найти там скрипты как для обновления, так и для решения самой проблемы с удалением майнера, но надеюсь Вас не затронет данная проблема, если Вы вовремя обновляетесь или следите за безопасностью своего сервера.
На этом я вынужден завершить свой маленький пост, добра всем и не попадать в такие ситуации, как человек выше, хотя никто не застрахован.
 

Ну значит dovecot + postfix
 
docker решает такие проблемы
 
Каким образом он решает проблемы? Если сервер уже скомпрометирован и проблема тут самого по
 
Таким образом, что каждый элемент будь то почтовый сервер, базы с данными, веб сервера можно изолировать друг от друга. Если уязвимый пакет будет только внутри одного контейнера, то будет скомпрометирован только этот контейнер. Docker не решит проблему совсем, но поможет сократить ущерб.
 
Прятать exim в доГер маразм. Пусть тема и старая но эта уязвимость херня по факту. По факту нормально настроенный EXIM не давал работать данной уязвимости. А уж если на то пошло почему все молчат про порты 5353
 
Прятать exim в доГер маразм. Пусть тема и старая но эта уязвимость херня по факту. По факту нормально настроенный EXIM не давал работать данной уязвимости. А уж если на то пошло почему все молчат про порты 5353
Я вижу эксперты подъехали). Ага херня, просто так мало было воздействий и просто так потом с горячей жопой побежали разработчики фиксить.
 
Я вижу эксперты подъехали). Ага херня, просто так мало было воздействий и просто так потом с горячей жопой побежали разработчики фиксить.
Много из вас используют TLS?
 
Обратите внимание, что данный пользователь заблокирован! Не совершайте с ним никаких сделок! Перейдите в его профиль, чтобы узнать причину блокировки.
проще сидеть на астре и юзать рубиконы
 
выпуск почтового сервера с устранением (CVE-2020-28007-CVE-2020-28026, CVE-2021-27216), которые компанией Qualys и представлены под кодовым именем 21Nails. 10 проблем могут быть эксплуатированы удалённо (в том числе для выполнения кода с правами root), через манипуляции с SMTP-командами при взаимодействии с сервером.

Проблемам подвержены все версии Exim, история которых отслеживается в Git с 2004 года. Для 4 локальных уязвимостей и 3 удалённых проблем подготовлены рабочие прототипы эксплоитов. Эксплоиты для локальных уязвимостей (CVE-2020-28007, CVE-2020-28008, CVE-2020-28015, CVE-2020-28012) позволяют поднять свои привилегии до пользователя root. Две удалённые проблемы (CVE-2020-28020, CVE-2020-28018) позволяют без аутентификации выполнить код с правами пользователя exim (затем можно получить доступ root, эксплуатировав одну из локальных уязвимостей).

Уязвимость CVE-2020-28021 позволяет сразу удалённо выполнить код с правами root, но требует аутентифицированного доступа (пользователь должен установить аутентифицированный сеанс, после чего может эксплуатировать уязвимость через манипуляции с параметром AUTH в команде MAIL FROM). Проблема вызвана тем, что атакующий может добиться подстановки строки в заголовок spool-файла из-за записи значения authenticated_sender без должного экранирования спецсимволов (например, передав команду "MAIL FROM:<> AUTH=Raven+0AReyes").

Дополнительно отмечается, что ещё одна удалённая уязвимость CVE-2020-28017 пригодна для эксплуатации для выполнения кода с правами пользователя "exim" без аутентификации, но требует наличия более 25 ГБ памяти. Для остальных 13 уязвимостей потенциально также могут быть подготовлены эксплоиты, но работа в этом направлении пока не проводилась.

Разработчики Exim были уведомлены о проблемах ещё в октябре прошлого года и потратили более 6 месяцев на разработку исправлений. Всем администраторам рекомендовано срочно обновить Exim на своих почтовых серверах до версии 4.94.2 (напомним, что Exim примерно на 59% почтовых серверов). Все версии Exim до выпуска 4.94.2 объявлены устаревшими (obsolete). Публикация новой версии была скоординирована с дистрибутивами, которые одновременно опубликовали обновления пакетов: , , , , и . RHEL и CentOS проблеме не подвержены, так как Exim не входит в их штатный репозиторий пакетов (в обновление пока ).

Удалённые уязвимости:

  • CVE-2020-28017: Целочисленное переполнение в функции receive_add_recipient();
  • CVE-2020-28020: Целочисленное переполнение в функции receive_msg();
  • CVE-2020-28023: Чтение из области вне выделенного буфера в функции smtp_setup_msg();
  • CVE-2020-28021: Подстановка новой строки в заголовок спул-файла;
  • CVE-2020-28022: Запись и чтение в области вне выделенного буфера в функции extract_option();
  • CVE-2020-28026: Усечение и подстановка строки в функции spool_read_header();
  • CVE-2020-28019: Сбой при сбросе указателя на функцию после возникновения ошибки BDAT;
  • CVE-2020-28024: Переполнения через нижнюю границу буфера в функции smtp_ungetc();
  • CVE-2020-28018: Обращение к буферу после его освобождения (use-after-free) в tls-openssl.c
  • CVE-2020-28025: Чтение из области вне выделенного буфера в функции pdkim_finish_bodyhash().
Локальные уязвимости:

  • CVE-2020-28007: Атака через символическую ссылку в каталоге с логом Exim;
  • CVE-2020-28008: Атаки на каталог со спулом;
  • CVE-2020-28014: Создание произвольного файла;
  • CVE-2021-27216: Удаление произвольного файла;
  • CVE-2020-28011: Переполнение буфера в функции queue_run();
  • CVE-2020-28010: Запись за границу буфера в функции main();
  • CVE-2020-28013: Переполнение буфера в функции parse_fix_phrase();
  • CVE-2020-28016: Запись за границу буфера в функции parse_fix_phrase();
  • CVE-2020-28015: Подстановка новой строки в заголовок спул-файла;
  • CVE-2020-28012: Отсутствие флага close-on-exec для привилегированного неименованного канала;
  • CVE-2020-28009: Целочисленное переполнение в функции get_stdinput().
 
Последнее редактирование:
exim уже обогнал sendmail по поличеству уязвимостей или нет?
 
Назад
Сверху Снизу