Об одной уязвимости, которой нет

    image
    В конце марта 2019 года американская компания Trustwave, занимающаяся кибербезопасностью и сервисами по защите от угроз, опубликовала сообщение об уязвимости в СУБД PostgreSQL, которая присутствует во всех версиях, начиная с версии PostgreSQL 9.3 по версию 11.2. Эта уязвимость была зарегистрирована в базе данных уязвимостей информационной безопасности CVE (Common Vulnerabilities and Exposures ) под номером CVE-2019-9193. Это сообщение вызвало большой переполох, так как по системе оценок уязвимостей CVSS (Common Vulnerability Scoring System) данная уязвимость получила рейтинг 9.0 по 10-балльной шкале.


    При этом уязвимости были присвоены следующие характеристики:


    • Confidentiality Impact (влияние на конфиденциальность) – полное раскрытие информации, приводит к раскрытию всех системных файлов.
    • Integrity Impact (влияние на целостность ) – полная потеря защиты системы, в результате вся система становится скомпрометированной.
    • Availability Impact (влияние на доступность) – возможна полная недоступность ресурса.
    • Access Complexity (сложность доступа к уязвимости) – низкая. Для использования требуется очень мало знаний или навыков.
    • Authentication – требуется, чтобы злоумышленник вошел в систему, например, через командную строку или через сеанс рабочего стола или web-интерфейс.
    • Gained Access (получение доступа) – нет.
    • Vulnerability Type(s) (тип уязвимости) – выполнение кода.

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


    В 2013 году еще в PostgreSQL 9.3 был добавлен коммит, который по аналогии с метакомандой \copy в psql позволяет перемещать данные между таблицами PostgreSQL и обычными файлами в файловой системе. COPY TO копирует содержимое таблицы в файл, а COPY FROM — из файла в таблицу (добавляет данные к тем, что уже содержались в таблице). В отличие от метакоманды \copy, которая реализована на клиенте, команда COPY..TO/FROM реализована на стороне сервера. У команды COPY есть необязательный параметр PROGRAM ‘команда’, который позволяет серверу выполнить ‘команду’ и передать стандартный вывод команды серверу PostgreSQL или в обратном направлении. Именно этот параметр и явился причиной паники и сообщения об уязвимости, так как по мнению Trustwave, эта команда позволяет выполнять произвольный код в контексте пользователя операционной системы. Однако именно так и было задумано разработчиками! По этому поводу было официальное сообщение PostgreSQL Global Development Group (PGDG), а также переписка в мейл-листе pgsql-general (CVE-2019-9193 about COPY FROM/TO PROGRAM) и комментарии ведущих разработчиков, например Magnus Hagander в своем блоге.


    Но чтобы понять суть, важны детали. Вот что по этому поводу написано в документации: «Заметьте, что команда запускается через командную оболочку, так что если требуется передать этой команде какие-либо аргументы, поступающие из недоверенного источника, необходимо аккуратно избавиться от всех спецсимволов, имеющих особое значение в оболочке, либо экранировать их. По соображениям безопасности лучше ограничиться фиксированной строкой команды или как минимум не позволять пользователям вводить в неё произвольное содержимое».


    Кроме того, в документации написано, что выполнять команду COPY с указанием файла или внешней команды разрешено только суперпользователям базы данных либо (в 11 версии появились) членам встроенных ролей pg_read_server_files, pg_write_server_files или pg_execute_server_program, так как это позволяет читать/записывать любые файлы и запускать любые программы, к которым имеет доступ сервер. Выполнение команды в PROGRAM может быть ограничено и другими работающими в ОС механизмами контроля доступа, например SELinux.


    Конструктивно не существует границы безопасности между суперпользователем базы данных и пользователем операционной системы, от имени которого запущен серверный процесс сервера. Функции для COPY… PROGRAM, добавленные в PostgreSQL 9.3, не изменили ничего из вышеперечисленного, но добавили новую команду в тех же границах безопасности, которые уже существовали. Поэтому сервер PostgreSQL не может работать от суперпользователя операционной системы (например, root).


    Сама по себе функциональность COPY..TO/FROM… PROGRAM дает неограниченные возможности по манипулированию данными, постобработке данных, сжатии данных «на лету» и так далее. И запрещать использование такого полезного инструментария было бы неправильно. Примеры применения конструкции COPY..TO/FROM… PROGRAM приведены в блоге Michael Paquier.


    Важный вывод, который следует из этой истории, заключается в том, что при проектировании и создании баз данных необходимо помнить не только о функциональных характеристиках, но и об информационной безопасности и следовать следующим правилам:


    • При создании обычных пользователей в базе данных не давать им разрешений superuser, лишь только пользователю операционной системы postgres, от имени которого запускается сервер, действовать в базе данных в качестве суперпользователя. В этом случае вообще не происходит эскалации привилегий. Если же обычному пользователю базы данных дать разрешение superuser, это будет равносильно выдаче пользователю разрешений, которыми обладает пользователь postgres в операционной системе.
    • Использовать возможности pg_hba.conf, чтобы гарантировать, что ни один суперпользователь не сможет войти в систему удаленно.
      В случае отсутствия предшествующих строчек с “host” в файле pg_hba.conf, следующая запись запрещает подключение пользователю postgres к любой базе данных с любых адресов по протоколу tcp/ip.

      # TYPE  DATABASE        USER            ADDRESS                 METHOD
      host    all             postgres        0.0.0.0/0               reject
    • Использовать передовые методики информационной безопасности в PostgresSQL, такие, например, как CIS PostgreSQL Benchmark и PostgreSQL Security Technical Implementation Guide (STIG).
    • Использовать сертифицированные продукты, для которых подтверждено соответствие функциональным требованиям по защите информации и уровень доверия к средствам обеспечения информационной безопасности.

    Таким образом, мы разобрались, что CVE-2019-9193 уязвимостью не является. Но расслабляться не стоит. Не пропускайте информацию об обновлениях и новых минорных выпусках, корректирующих выявленные уязвимости, без которых не обходится ни один большой проект.

    • +23
    • 6,9k
    • 7
    Postgres Professional
    192,00
    Разработчик СУБД Postgres Pro
    Поделиться публикацией

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

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

      0

      Это не бага — это фича ;)

        0
        Я не специалист. По системе оценок CVSS проблема определённо получила почти наивысший класс 9/10. А в итоге Вы утверждаете, что это проблема кривого администрирования. При этом Вы говорите, что расплавляться не стоит и надо ждать исправлений. Помогите понять…
          +2
          Собственно, для этого статья и была написана. Эксперты, которые заявили «уязвимость» совершенно формально подошли к возможным последствиям, не разобравшись в сути фичи. В описании самой CVE написано, что она спорная. То есть при правильном администрировании угрозы нет. С тем же успехом пользователь с правами системного пользователя postgres может сделать все, что захочет.
          Последний абзац про «не расслабляться» относится в целом к тому, что нужно проверять наличие обновлений не только с точки зрения функциональных возможностей, но и информации об уязвимостях и возможностях их обхода, если не проводить обновление версии.
            0
            Значит я правильно понял. Ну а то, что надо держать руки на пульсе обновлений — безусловно.

            Блин, как же надоели эти выкрутасы. Мы часто слышим новости об уязвимостях на пример в IE от Майкрософт, которые сама компания не признает оными, но которыми так успешно пользуются специалисты. А тут наоборот, CVSS небрежно/непрофессионально признает ошибкой то, что по сути является этикетом администрирования. Мдеуж.
            +3
            Это уязвимость из серии «суперпользователь может стереть ВСЁ!», требующей локальных прав суперпользователя для эксплуатации. Так примерно.
            +2
            Новость слегка устарела. По вашей ссылке на сайте Trustwave написано:
            EDIT (9.April.2019): We have applied for a retraction of CVE-2019-9193 previously associated with this post. Upon further review and through discussions with the PostgreSQL community we do not believe this is a vulnerability in the sense that it is a security bug in the software. As such, it does not rise to the level of a CVE. However, we still believe that the «COPY TO/FROM PROGRAM» feature adds risk to many PostgreSQL environments, so we are leaving the rest of this content intact.

            То есть уже 2 недели назад они заявили об отзыве CVE-2019-9193. Перевод: «по дальнейшем рассмотрении и обсуждении с сообществом PostgreSQL мы не считаем, что это уязвимость в том смысле, что это security bug в ПО».

            И по ссылке на CVE-2019-9193 тоже написано, что эта уязвимость «DISPUTED» (оспариваемая), и что «представители третьей стороны заявляют что это не проблема, т.к. данная функциональность ведет себя как положено в соответствии с её назначением».
              +3
              Спасибо за замечание. Как раз об этом и статья. Возможно, инфоповод и устарел, но вопросов грамотного администрирования информационной безопасности не отменяет.
              Описание на CVE details пока не говорит, что уязвимость отозвана.

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

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