Внимание!
Статья имеет ознакомительный характер и предназначена для специалистов по обеспечению информационной безопасности. Автор не несёт ответственности за любой вред, причиненный с применением изложенной информации. Помните, распространение вредоносных программ, нарушение работы систем и тайны переписки преследуются по закону.



В течение 2021 года в PostgereSQL были обнаружены уязвимости, наличие которых в системе может привести к нежелательным последствиям. Сказать, что их много нельзя, но, порой, в умелых руках, при стечении определенных обстоятельств, даже одна уязвимость превращается в большую проблему.

Поэтому в этой статье мы рассмотрим те, что имеют отношение к 11,12,13,14 – последним версиям ядра PostgereSQL, и соответственно ко всем продуктам, сделанным на основе этого кода. Всего, по мнению «https://www.postgresql.org/support/security/» их восемь.
Давайте внимательно, проанализируем каким образом они угрожают пользователям СУБД и как устранены. Будем изучать их, разбив на характерные группы уязвимостей по видам атак. Поехали!

Первая группа уязвимостей – MITM

MITM – «Атака посредника, или атака по типу «человек посередине» (англ. Man in the middle) вид атаки в криптографии и компьютерной безопасности, когда злоумышленник тайно ретранслирует и при необходимости изменяет связь между двумя сторонами, которые считают, что они непосредственно общаются друг с другом. Является методом компрометации канала связи, при котором взломщик, подключившись к каналу между контрагентами, осуществляет вмешательство в протокол передачи, удаляя или искажая информацию. Подробнее о таких видах атаках – здесь.
Уязвимости, позволяющие использовать данный вид атаки, обнаруженные в этом году.

1. CVE-2021-23222 – libpq processes unencrypted bytes from man-in-the-middle

Обнародована в ноябре 2021 года. Злоумышленник «посредник» (MITM) мог вводить ложные ответы на первые несколько запросов клиента, несмотря на использование проверки и шифрования SSL-сертификата. При некотором стечение обстоятельств, было возможным получить пароль или другие конфиденциальные данные пользователя, которые могут быть переданы в начале сеанса. Злоумышленник должен иметь способ обойти сервер клиента, чтобы получить данные для служебного пользования. Известной реализацией, обладающей этим свойством, является конфигурация PostgreSQL, уязвимая для CVE-2021-23214 (мы рассмотрим её ниже). Как и при любом использовании CVE-2021-23214, сервер должен использовать доверенную аутентификацию с запросом сертификата или использовать аутентификацию через него. Чтобы раскрыть пароль, у клиента он должен быть, что, порой, нетипично при использовании конфигурации аутентификации, уязвимой для CVE-2021-23214. У злоумышленника также должен быть доступ к серверу для получения данных (для этого достаточно действующей непривилегированной учетной записи для входа).

Что сделано для устранения (CVE-2021-23222)

Теперь libpq отклоняет посторонние данные после «рукопожатия» с шифрованием SSL или GSS. Данная уязвимость устранена в версиях ядра СУБД с номерами 14.1, 13.5, 12.9, 11.14. Проверьте, обновились ли вы до этих версий!

Дополнительно рекомендуется учитывать

При использовании SSL Session Encryption, GSSAPI Session Encryption фронтэнд должен разрабатываться с учетом того, что необходимо считывать ровно один байт из сокета, прежде чем передавать сокет в свою библиотеку SSL, либо рассматривать это как нарушение протокола, если будет обнаружено, что прочитали дополнительные байты.

Как только шифрование GSSAPI будет успешно установлено, используйте gss_wrap() для шифрования обычного StartupMessage и всех последующих данных, добавив длину результата gss_wrap() в виде целого числа в четыре байта в сетевом порядке байтов к фактической зашифрованной полезной нагрузке. Обратите внимание, что сервер будет принимать только зашифрованные пакеты от клиента, которые меньше 16 КБ, gss_wrap_size_limit() должен использоваться клиентом для определения размера незашифрованного сообщения, которое будет соответствовать этому пределу, и большие сообщения должны быть разбиты на несколько вызовов gss_wrap(). Типичные сегменты составляют чуть больше 8 КБ незашифрованных данных, в результате чего зашифрованные пакеты немного превышают 8 КБ, но не более 16 КБ. Сервер не должен отправлять клиенту зашифрованные пакеты размером более 16 КБ.

Отметим, хотя сам протокол не предоставляет серверу возможности принудительно использовать SSL-шифрование, администратор может настроить сервер так, чтобы он отклонял незашифрованные сеансы в качестве побочного продукта проверки подлинности.
Больше об этом можно узнать по ссылке.

2. CVE-2021-23214 – server processes unencrypted bytes from man-in-the-middle

Информация о ней также появилась в ноябре 2021 года. Если сервер настроен на доверенную аутентификацию с запросом сертификата или использует аутентификацию через сертификат, злоумышленник «посредник» (MITM) может вводить произвольные SQL-запросы при первом установлении соединения, несмотря на использование проверки и шифрования SSL-сертификата.

Что сделано для устранения (CVE-2021-23214)

Теперь libpq будет отклонять посторонние данные после «рукопожатия» с шифрованием SSL или GSS. Устранено в версиях ядра СУБД с номерами 14.1, 13.5, 12.9, 11.14.

Вторая группа уязвимостей – «Доступ к памяти»

Из этой группы имеются следующие примеры:

1. CVE-2021-32029 – Memory disclosure in partitioned-table UPDATE… RETURNING

Используя UPDATE… RETURNING к созданной секционированной таблице, злоумышленник мог прочитать информацию из памяти сервера. По умолчанию любой аутентифицированный пользователь базы данных может создавать необходимые объекты и атаковать таким способом. Пользователь, у которого отсутствуют права на CREATE и TEMPORARY привилегии для всех баз данных, а также права на CREATE для всех схем, не cможет этим воспользоваться. Возможна эксплуатация этой уязвимости для чтения памяти сервера и получения конфиденциальной информации. Эта проблема затронула только Ubuntu 20.04 LTS, Ubuntu 20.10 и Ubuntu 21.04. (CVE-2021-32029).

Что сделано для устранения (CVE-2021-32029)

Исправлена ошибка при возврате значений в данной операции. Эта уязвимость устранена в версиях ядра СУБД с номерами: 13.3, 12.7, 11.12.

2. CVE-2021-32028 – Memory disclosure in INSERT… ON CONFLICT… DO UPDATE

Используя INSERT… ON CONFLICT… DO UPDAT к таблице, возможно прочитать произвольные байты памяти сервера. В конфигурации по умолчанию любой аутентифицированный пользователь базы данных мог создавать необходимые объекты и использовать это в своих целях. Пользователь, у которого отсутствуют права на CREATE и TEMPORARY привилегии для всех баз данных, а также права на CREATE для всех схем, не мог этим воспользоваться.
Если говорить конкретнее, то если UPDATE содержит какие-либо подразделы с несколькими столбцами (которые приводят к появлению нежелательных столбцов в дополнение к результатам), в плане UPDATE будут храниться массивы, включающие значения этих столбцов. И кажется, что это ни на что не влияет, но если в таблицу добавлялись новые столбцы, то значения могли стать доступными, что в свою очередь могло привести к сбою, если они не соответствуют типам данных добавленных столбцов.

Кроме того, в версиях, поддерживающих cross-partition updates, имелась обратная проблема: ненужные столбцы были удалены из целевого списка, что также обычно приводило к немедленному сбою из-за сбоя механизма выбора нескольких столбцов.

Что сделано для устранения (CVE-2021-32028)

Работа с «лишними» столбцами теперь не будет нести в себе риски. Данная уязвимость устранена в версиях ядра СУБД с номерами: 13.3, 12.7, 11.12.

3.CVE-2021-3677 – Memory disclosure in certain queries

Специально созданный запрос мог считывать произвольные байты памяти сервера. В конфигурации по умолчанию любой аутентифицированный пользователь базы данных мог осуществить эту атаку. Атака не требует создавать объекты. Если настройки сервера включают max_worker_processes=0, известные версии этой атаки неосуществимы.

Что сделано для устранения (CVE-2021-3677)

Исправлено неверное формирование плана запроса. Планировщик мог создать такой план в тех случаях, когда две ProjectionPaths были наложены друг на друга. Единственный известный способ вызвать эту ситуацию включает параллельные операции сортировки, но могут быть и другие случаи. Результатом могли быть сбои или неправильные результаты запроса и раскрытие содержимого памяти сервера. Данная уязвимость устранена в версиях: 13.4, 12.8, 11.13.

Такие уязвимости, как переполнение буфера, тоже можно отнести к вариантам работы с памятью:

4. CVE-2021-32027 – Buffer overrun from integer overflow in array subscripting calculations

При изменении определенных значений массива SQL проверка отсутствия границ позволяет аутентифицированным пользователям базы данных записывать произвольные байты в обширную область памяти сервера. Наибольшая угроза от этой уязвимости связана с конфиденциальностью и целостностью данных, а также доступностью системы. При тщательном отслеживании того, чтобы размеры массивов не были большими, для предотвращения переполнения целых чисел, значения нижней границы обычно не проверялись. Кажется, что это безвредно для чтения массива, за исключением того, что его элементы с индексами, условно превышающими INT_MAX, недоступны. Однако, это путало логику назначения массивов, что могло привести к нехватке памяти.

Что сделано для устранения (CVE-2021-32027)

Исправлено путем добавления проверок того, что нижние границы массива недостаточно велики, чтобы вызвать переполнение. Уже не актуально в версиях: 13.3, 12.7, 11.12.

Третья группа уязвимостей – «Повышение или превышение привилегий»

И наконец третья, последняя по очереди, но не последняя по опасности – группа.

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

1. CVE-2021-20229 – Single-column SELECT privilege enables reading all columns

Пользователь, имеющий привилегию SELECT для отдельного столбца, мог создать запрос, который возвращает все столбцы таблицы, несмотря на отсутствие привилегий.

Кроме того, сохраненное представление, использующее привилегии на уровне столбцов, будет содержать неполные «растровые изображения» использования столбцов. В установках, которые зависят от разрешений на уровне столбцов для обеспечения безопасности, рекомендуется выполнить команду CREATE or REPLACE для всех пользовательских представлений, чтобы принудительно выполнить их повторный анализ.

Что сделано для устранения (CVE-2021-20229)

Исправлено некорректное использование привилегий SELECT на уровне столбцов для алиасов соединений (join aliases). Данная проблема устраняется установкой следующих релизов: 13.3, 12.7, 11.12

2. CVE-2021-3393 – Partition constraint violation errors leak values of denied columns

Пользователь, имеющий привилегию UPDATE для секционированной таблицы, но не имеющий привилегии SELECT для некоторого столбца, мог получать значения запрещенных столбцов из сообщения об ошибке. Это похоже на CVE-2014-8161, но вариантов использования меньше.

Что сделано для устранения (CVE-2021-3393)

Исправлено дополнительными проверками при работе с секционированными таблицами. Исправлено в версиях: 13.3, 12.7, 11.12.

3. CVE-2021-44228 или Log4j

Также с ней связаны CVE-2021-45046 и CVE-2021-4104.Критическая уязвимость Log4j позволяет любому злоумышленнику вводить текст в сообщения или параметры сообщений в журналы сервера, которые загружают код с удаленного сервера, затем целевой сервер выполняет этот код с помощью вызовов интерфейса именования и каталогов Java (JNDI), мы рекомендуем проверить окружение СУБД на наличие продуктов и систем, подверженных данной уязвимости.

Какие из всего этого можно сделать выводы?

1. Будьте бдительны. Активность злоумышленников не снижается, а только увеличивается. Внимательно следите за анонсами производителей СУБД об обнаруженных уязвимостях.
2. Ставьте рекомендованные патчи, максимально быстро после их выхода. Порой время между публикацией уязвимости и её использованием очень мало.
3. Используйте в своей работе проверенные решения. Пользуйтесь только доверенными источниками. Перепроверяйте откуда ваша копия. Не забывайте, проверку вами контрольной суммы дистрибутива никто не заменит.
4. Внимательно следите за анонсами производителей СУБД об обнаруженных уязвимостях на сайтах продукта.

Всем добра в новом 2022 году!

Автор: программист-аналитик команды разработки СУБД Jatoba Андрей Никель.