- PVSM.RU - https://www.pvsm.ru -

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

image
В конце марта 2019 года американская компания Trustwave, занимающаяся кибербезопасностью и сервисами по защите от угроз, опубликовала сообщение [1] об уязвимости в СУБД PostgreSQL, которая присутствует во всех версиях, начиная с версии PostgreSQL 9.3 по версию 11.2. Эта уязвимость была зарегистрирована в базе данных уязвимостей информационной безопасности CVE (Common Vulnerabilities and Exposures ) под номером CVE-2019-9193 [2]. Это сообщение вызвало большой переполох, так как по системе оценок уязвимостей 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, эта команда позволяет выполнять произвольный код в контексте пользователя операционной системы. Однако именно так и было задумано разработчиками! По этому поводу было официальное сообщение [3] PostgreSQL Global Development Group (PGDG), а также переписка в мейл-листе pgsql-general (CVE-2019-9193 about COPY FROM/TO PROGRAM [4]) и комментарии ведущих разработчиков, например Magnus Hagander в своем блоге [5].

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

Кроме того, в документации написано, что выполнять команду 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 приведены в блоге [6] 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 [7] и PostgreSQL Security Technical Implementation Guide (STIG) [8].
  • Использовать сертифицированные продукты, для которых подтверждено соответствие функциональным требованиям по защите информации и уровень доверия к средствам обеспечения информационной безопасности.

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

Автор: Валерий Попов

Источник [10]


Сайт-источник PVSM.RU: https://www.pvsm.ru

Путь до страницы источника: https://www.pvsm.ru/postgresql/315576

Ссылки в тексте:

[1] сообщение: https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/authenticated-arbitrary-command-execution-on-postgresql-9-3/

[2] CVE-2019-9193: https://www.cvedetails.com/cve/CVE-2019-9193/

[3] официальное сообщение: https://www.postgresql.org/about/news/1935/

[4] (CVE-2019-9193 about COPY FROM/TO PROGRAM: https://postgrespro.ru/list/id/e6251b54-78f4-4ec0-8e22-8c4179f0e817@manitou-mail.org

[5] блоге: https://blog.hagander.net/when-a-vulnerability-is-not-a-vulnerability-244/

[6] блоге: https://paquier.xyz/postgresql-2/postgres-9-3-feature-highlight-copy-tofrom-program/

[7] CIS PostgreSQL Benchmark: https://www.cisecurity.org/benchmark/postgresql/

[8] PostgreSQL Security Technical Implementation Guide (STIG): https://www.crunchydata.com/postgres-stig/PGSQL-STIG-9.5+.pdf

[9] корректирующих выявленные уязвимости: https://www.postgresql.org/support/security/

[10] Источник: https://habr.com/ru/post/448750/?utm_source=habrahabr&utm_medium=rss&utm_campaign=448750