В systemd нашли три уязвимости — разбираемся, в чем дело

    В начале месяца специалисты по ИБ из Qualys обнаружили сразу три уязвимости в systemd — подсистеме инициализации Linux — позволяющие злоумышленнику получить права суперпользователя. Рассказываем, в чем их суть и какие дистрибутивы им подвержены.


    / Flickr / David Goehring / CC BY / Фото изменено

    Старые новые уязвимости


    Все три уязвимости связаны с сервисом ведения журнала systemd — journald. В базе данных CVE им присвоили следующие идентификаторы: CVE-2018-16864, CVE-2018-16865 и CVE-2018-16866. Эти уязвимости дают злоумышленнику возможность заполучить root-права на атакуемой системе.

    Опасности подвержены все дистрибутивы без функции защиты пользовательского пространства (-fstack-check) — Debian, Ubuntu, Fedora, CentOS, Mageia и др. Среди исключений числятся SUSE Linux Enterprise 15 и openSUSE Leap 15.0, а также Fedora версий 28 и 29.

    Что интересно, всем трем уязвимостям уже несколько лет, просто о них ничего не было известно. CVE-2018-16864 возникла в 2013 году, но эксплуатировать её стало можно в 2016-м, когда systemd обновили до 230 версии. CVE-2018-16865 появилась в операционной системе в 2011-м, но стала критичной только через два года, после релиза systemd версии 201.

    Что касается третьей уязвимости (CVE-2018-16866), то она существует с 2015 года. Однако её случайно закрыли обновлением systemd v240 спустя несколько лет. Машины без этого патча находятся под угрозой до сих пор.

    В чем суть обнаруженных «дыр»


    Уязвимость CVE-2018-16864 позволяет злоумышленнику провести манипуляции с командной строкой и отправить множество аргументов (весом в несколько мегабайт) systemd-journald, тем самым вызывая падение процесса. Далее у хакера появляется возможность захватить контроль над расширенным указателем команд (EIP).

    Проблема с CVE-2018-16864 связана с записью большого сообщения в /run/systemd/journal/socket. В результате часть этого сообщения выходит за пределы стека и попадает в регион mmap. После злоумышленник может переписать сегмент read-write у libc и заменить указатель функции и запустить в системе любую желаемую цепочку программ.

    Что касается CVE-2018-16866, то она связана с ошибкой разбора строки. Если направить системе журналирования специальное сообщение (оканчивающееся символом двоеточия) в формате syslog, то система проигнорирует конец строки и запишет в лог следующую за ним часть стека.

    Вторая и третья уязвимость позволяют реализовать так называемую атаку возврата в библиотеку и запускать на машине жертвы любые функции. По словам специалистов из Qualys, им удалось создать эксплойт и получить права суперпользователя на компьютерах с архитектурой i386 и amd64 за 10 и 70 минут соответственно.

    «Эти уязвимости довольно серьезны, учитывая, что они позволяют повышать права доступа в системе. Авторы пока держат в тайне код своего эксплойта, поскольку «дыры» есть в большом количестве дистрибутивов, — комментирует начальник отдела развития IaaS-провайдера 1cloud.ru Сергей Белкин. — Они его опубликуют, когда уявзимости будут закрыты. Некоторые разработчики, например из Ubuntu и Red Hat, уже выложили необходимые патчи. Их можно найти в официальных репозиториях».


    / Flickr / bradleypjohnson / CC BY

    Какие еще уязвимости находили в systemd


    Последний раз уязвимость в systemd обнаружили в октябре 2018 года. DHCPv6-клиент менеджера служб автоматически запускался при получении сообщения от любого DHCP-сервера локальной сети или интернет-провайдера. С помощью этого сообщения в systemd можно было вызвать отказ памяти и получить контроль над компьютером.

    До этого несколько багов в коде менеджера служб нашли в 2017 году. Один из них позволял злоумышленникам использовать TCP-пакеты, чтобы выполнить любой код в системе. TCP-пакеты «заставляли» systemd выделять слишком маленький объём буфера для сообщения. Это позволяло писать произвольные данные за пределами буфера в основную память.

    Другая уязвимость 2017 года была связана с несанкционированным получением прав суперпользователя. В некоторых дистрибутивах, например CentOS и RHEL7, в systemd была возможность создать профиль с именем пользователя, которое начинается с цифры. Хотя обычно в Linux эта возможность не предусмотрена. Но если в системе появлялся такой пользователь, менеджер служб предоставлял ему права администратора.

    Все эти уязвимости были закрыты в короткие сроки. «Заплатки» для новых «дыр», обнаруженных в январе, тоже постепенно появляются. Можно ожидать, что скоро уязвимости закроют в большинстве дистрибутивов, и администраторам Linux-серверов и компьютеров останется только установить обновление системы.

    Посты из корпоративного блога 1cloud:

    1cloud.ru
    270,00
    IaaS, VPS, VDS, Частное и публичное облако, SSL
    Поделиться публикацией

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

      +8
      «Расширенным указателем команд (EIP)»
      Первый раз встречаю в тексте такое упоминание регистра EIP.
        –2
        Мда, вот вам и результат веры в RedHat. К сожалению, остальные системы инициализации уже проиграли, и теперь нам остается только надеяться, что инженеры из шапки будут затыкать дырки этого тонущего судна быстрее, чем оно тонет.
          +1

          Перед тем как поливать грязью Red Hat Inc попробуйте сделать для себя то, что у них не получилось сделать для вас. (Нас заинтересовал контекст безопасности, который RH как раз и сделала для таких случаев. Надеюсь вы теперь поймете почему господин Поттеринг называл не ошибкой systemd неправильно сконфигурированный сервис с присвоением ему привилегий UID=0. [Из старых ошибок.])


          Моё личное ИМХО, systemd без корректной таргетированой политики SELinux лучше не выгуливать в продакшн лишь по причине наличия такого рода уязвимостей пугающих ИБ'шников.

            –1

            Ага, давайте вообще все приложения запускать от UID 0, а ещё при старте системы выполнять chmod 777 -R /, а потом закрывать образовавшиеся дыры при помощи SELinux, bubblewrap, cgroups и firejail. Судя по тому, с какой скоростью добавляются функции в systemd, к этому всё и идёт. Может быть, я что-то не понимаю и это правильный путь.

              0
              большинство сервисов, поставляющихся с systemd, запускаются (если дистростроителями не определено обратное) от динамически создаваемых пользователей с ID вида 6####.
            +2
            Остальные системы инициализации тоже имеют свои дыры. У более старых систем файл, описывающий процесс, содержит шаблонный исполняемый код. Если в этом коде находили проблему, то её приписывали не системе инициализации, а командам, поддерживающим дистрибутивы или самим пакетам. Systemd проглотил в себя этот код, а вместе с ним и ответственность.
            +1
            эксплойта
              0
              чойта?

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

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