Пропатчил Exim — пропатчь еще раз. Свежее Remote Command Execution в Exim 4.92 в один запрос


    Совсем недавно, в начале лета, появились массовые призывы к обновлению 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}}}}
    Инфосистемы Джет
    411,38
    Системный интегратор
    Поделиться публикацией

    Похожие публикации

    Комментарии 13

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

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

          Да не… Дело не в руках — там оно чуть не всё такое.
          Простейшие вещи нужно иногда через одно место делать… Вот например чтобы отловить "неправильные" 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 включить (чтобы можно было нормальный баг-трэкер юзать).

          +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 даже при дефолтных/стандартных конфигах есть где.


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

            0
            Строго говоря, в понедельник уже выложили фикс (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 — если не хватит духу заняться тем, на что намекнули.
              +2
              Можно подумать, разработчики Postfix вам ответят что-то другое)
                +1
                Ну, если на пальцах, критических багов в Postfix публиковалось существенно реже.

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

                А так да, ответить могут ровно так же.
                  –1
                  это не означает, что в целом Postfix надёжнее

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

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

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

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

                Для меня между Exim/Postfix отличия слились, грубо говоря, в то, что Postfix модульная система :) Еще в Postfix конфиги лаконичнее и проще, но это субъективно.
                  0
                  Да я и не против поучаствовать — при всех прибабахах, Exim ведёт себя стабильно и дело своё делает.
                +1
                Спасибо Вам за подробную статью, лучше сказать это поздно чем никогда.

                Спешу однако обрадовать — 4.92.2 уже устарела / Хабр

                Теперь опять Ваша очередь :)

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое