12.09.2019 07:01
BlancLoup 12 3200 Источник


Совсем недавно, в начале лета, появились массовые призывы к обновлению Exim до версии 4.92 из-за уязвимости CVE-2019-10149 (Срочно обновляйте exim до 4.92 — идёт активное заражение / Хабр). А на днях выяснилось, что вредонос Sustes решил воспользоваться этой уязвимостью.


Теперь все экстренно обновившиеся могут опять «порадоваться»: 21 июля 2019 г. исследователь Zerons обнаружил критическую уязвимость в Exim Mail Transfer agent (MTA) при использовании TLS для версий от 4.80 до 4.92.1 включительно, позволяющую удаленно выполнять код с привилегированными правами (CVE-2019-15846).


Уязвимость


Уязвимость присутствует при использовании библиотек как GnuTLS, так и OpenSSL при установке защищенного TLS-соединения.


По словам разработчика Heiko Schlittermann, файл конфигурации в Exim по умолчанию не использует TLS, однако многие дистрибутивы во время установки создают необходимые сертификаты и включают защищенное соединение. Также более новые версии Exim устанавливают опцию tls_advertise_hosts=* и генерируют необходимые сертификаты.


depends on the configuration. Most distros enable it by default, but Exim needs a certificate+key to work as a TLS server. Probably Distros create a Cert during setup. Newer Exims have the tls_advertise_hosts option defaulting to "*" and create a self signed certificate, if none is provided.

Сама же уязвимость заключается в некорректной обработке SNI (Server Name Indication, технология, введенная в 2003 в RFC 3546 для запроса клиентом корректного сертификата для доменного имени, Распространение стандарта TLS SNI / Блог компании WEBO Group / Хабр) в ходе TLS-рукопожатия. Злоумышленнику достаточно отправить SNI, оканчивающийся бэкслешем ("\") и нулл-символом ("\0").


Исследователи из компании Qualys обнаружили баг в функции string_printing(tls_in.sni), который заключается в некорректном экранировании "\". В результате происходит запись обратного слеша в неэкранированном виде в файл заголовков print spool. Далее этот файл с привилегированными правами считывается функцией spool_read_header(), что ведет к переполнению кучи (heap overflow).


Стоит отметить, что на данный момент разработчики Exim создали PoC уязвимости с выполнением команд на удаленном уязвимом сервере, но в публичном доступе он пока отсутствует. В силу простоты эксплуатации бага это всего лишь вопрос времени, причем довольно короткого.


С более детальным исследованием компании Qualys можно ознакомиться здесь.


Использование SNI в TLS


Использование SNI в TLS


Количество потенциально уязвимых публичных серверов


По статистике крупного хостинг-провайдера E-Soft Inc на 1 сентября, на арендованных серверах версия 4.92 используется в более чем 70% хостов.


Version Number of Servers Percent
4.92.1 6471 1.28%
4.92 376436 74.22%
4.91 58179 11.47%
4.9 5732 1.13%
4.89 10700 2.11%
4.87 14177 2.80%
4.84 9937 1.96%
Other versions 25568 5.04%

Статистика компании E-Soft Inc


Если обратиться к поисковой системе Shodan, то из 5,250,000 в базе серверов:


  • около 3,500,000 используют Exim 4.92 (около 1,380,000 с использованием SSL/TLS);
  • более 74,000 используют 4.92.1 (около 25,000 с использованием SSL/TLS).

Таким образом, публично известных и доступных Exim потенциально уязвимых серверов насчитывается порядка 1.5 млн.


Поиск Exim-серверов в Shodan


Поиск Exim-серверов в Shodan


Защита


  • Самый простой, но не рекомендуемый вариант — не использовать TLS, что приведет к пересылке почтовых сообщений в открытом виде.
  • Более предпочтительным для избежания эксплуатации уязвимости будет обновление до версии Exim Internet Mailer 4.92.2.
  • В случае невозможности обновления или установки пропатченной версии можно задать ACL в конфигурации Exim для опции acl_smtp_mail со следующими правилами:

    # to be prepended to your mail acl (the ACL referenced
# by the acl_smtp_mail main config option)
deny    condition = ${if eq{\\}{${substr{-1}{1}{$tls_in_sni}}}}
deny    condition = ${if eq{\\}{${substr{-1}{1}{$tls_in_peerdn}}}}

Комментарии (12)


  1. mikevmk
    12.09.2019 11:48
    #20614097
    +2

    К такой отличной заметке должен быть дурацкий оффтоп-комментарий ни о чём — вот он

    Никогда с Exim не мог сдружиться. Sendmail, затем QMail, потом Postfix — всё ОК. А с Exim все время косяк на косяке. Наверно собственные кривые руки виноваты


    1. lowtechomega
      12.09.2019 14:11
      #20614999
      +1

      Аналогично, коллега, поддерживаю.


    1. sebres
      12.09.2019 14:19
      #20615057
      +1

      Да не… Дело не в руках — там оно чуть не всё такое.
      Простейшие вещи нужно иногда через одно место делать… Вот например чтобы отловить "неправильные" Bounce и почту от всяких backscatter и ко (без BATV, ибо не надо) вместо пары простейших правил в системном фильтре чтобы например режектнуть их на входе (без того чтобы самому стать спамером отправляя bounce не туда куда надо), нужно делать кучу ненужных телодвижений.


      И главное потом еще и дебажить его на живую, потому что внезапно чтобы протестировать от рута (ибо только так всё, включая системные фильтры и т.д., можно проверить), т.е. "нельзя просто взять и сделать"© что-нибудь вида:


      echo "$msg" | exim -N -d+all+filter+... -f from@example.com -t to@example.com ...

      ибо вдруг по какой-то одному exim известной причине оно позаменяет from@example.com и envelope from и ко из сообщения на root@localhost (wtf) ну и вся проверка дальше коту под хвост...


      А поиск в известных поисковиках по howto "exim" "что-то чуть более сложнее чем ..." (как в прочем и для многих популярных продуктов) нередко тонет в бестолковой массе нерелевантных ответов на форумах/SO/SE и т.п. — т.е. найти то что действительно нужное практически нереально.
      Документация же (довольно большая кстати) или вики у exim местами откровенно хромают.
      Инфы-то вроде много, но как сделать "правильно" что-то конкретное (чуть сложнее чем хеловорлды) — можно искать часами, потому что вот этот параметр конфликтует с вот этим вот (а найти это удается чуть ли не в исходниках).
      Хотя с появлением wiki на github стало полегче, да…
      Осталось им еще там issues включить (чтобы можно было нормальный баг-трэкер юзать).


  1. sebres
    12.09.2019 16:48
    #20615889
    +2

    Хмм…
    А баг конечно эпичный:


    int
string_interpret_escape(const uschar **pp)
{
  const uschar *p = *pp;
  int ch = *(++p);
+ if (ch == '\0') return **pp;
  ...
  *pp = p; /* fail был здесь - возвращаем ptr на следующий (за границей NTS) байт. */
  return ch;
}

    Т.е. ранее (до фикса) возвращенный указатель в *pp "тупо" указывал на следующий после последнего '\\' символ (за '\0') в буфере и рутина вызывающая string_interpret_escape при проверке внутри циклов типа while (*p) {...} продолжала исполнение уже за границей строки пока не ловила следующий '\0' или собственно BO.


    Учитывая что string_interpret_escape пользуется почем зря (от фильтров до string expansion) мне вот совсем непонятно почему exim разрабы ограничились "BO с возможным RCE на SNI-data в процессе TLS-nego"… когда оно вот прямо само напрашивается.
    И если вернуть или выдернуть что-то дельное на стадии TLS-negotiation таким образом действительно вряд ли получится, то например сценарии вида "отправить в bounce атакующему кусок памяти exim" и подобные фишки выглядят вполне себе ничего… а развернуться в exim даже при дефолтных/стандартных конфигах есть где.


    Я не большой любитель теорий заговора, но как-то оно не очень выглядит...


  1. Temmokan
    12.09.2019 18:21
    #20616375

    Строго говоря, в понедельник уже выложили фикс (4.92.2), а на мой вопрос в список рассылки, ведутся ли штатные тестирования в т.ч. на уязвимости перед релизами, мне ответили «а что бы тебе самому не заняться?». Конкретно, на языке оригинала:

    Я: Just curious, whether Exim is regularly tested for vulnerabilities as it's developed?
    Jeremy Harris: Please feel free to volunteer your time and expertise.


    Всё ближе час, когда, думаю, таки начну поглядывать на Postfix — если не хватит духу заняться тем, на что намекнули.


    1. SergeyMax
      12.09.2019 19:30
      #20616639
      +2

      Можно подумать, разработчики Postfix вам ответят что-то другое)


      1. Temmokan
        13.09.2019 02:34
        #20617507
        +1

        Ну, если на пальцах, критических багов в Postfix публиковалось существенно реже.

        Но я прекрасно понимаю, что 1) это не означает, что в целом Postfix надёжнее, и 2).достаточно давно уже пользуюсь Exim, как-то привык уже.

        А так да, ответить могут ровно так же.


        1. katzen
          13.09.2019 11:13
          #20618593

          это не означает, что в целом Postfix надёжнее

          Он надёжнее не по этой причине. Люди (знающие, как мне кажется) намекают, что модульность построения постфикса, да и его разработка, изначально нацеленная на безопасность и устойчивость, была обусловлена как раз результатами эксплуатации сендмейла.


          1. Temmokan
            13.09.2019 11:28
            #20618675

            Спорить не буду, но не всегда можно просто взять и перейти.

            В целом же, трагических последствий при использовании Exim удавалось избегать. Хоть это и означает, что приходится иной раз обновляться в режиме аврала.


            1. sav1812
              13.09.2019 13:39
              #20619457

              приходится иной раз обновляться в режиме аврала

              Как и в случае с любым другим софтом…


    1. member0
      13.09.2019 00:32
      #20617365

      Ну, если так уж честно сказать, правильно и намекнули. Если есть знания и время потестить, поучаствуйте тоже, так сказать :) Он же на то и оперсоурс, чтобы быть открытым для любых добрых начинаний.

      В целом, если так грубо, Exim сейчас популярнее. Так что, если в результате которого по счету CVE бага, его «очередь пройдет» и все перейдут на Postfix, думаю, там обнаружится все тоже самое.

      Для меня между Exim/Postfix отличия слились, грубо говоря, в то, что Postfix модульная система :) Еще в Postfix конфиги лаконичнее и проще, но это субъективно.


      1. Temmokan
        13.09.2019 02:35
        #20617513

        Да я и не против поучаствовать — при всех прибабахах, Exim ведёт себя стабильно и дело своё делает.