Postgres Professional corporate blog
PostgreSQL
April 23

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

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
7.2k 23
Comments 7