В конце марта 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 уязвимостью не является. Но расслабляться не стоит. Не пропускайте информацию об обновлениях и новых минорных выпусках, корректирующих выявленные уязвимости, без которых не обходится ни один большой проект.
