В PostgreSQL 9.2.4, 9.1.9 и 9.0.13 устранена критическая уязвимость

04.04.2013 20:43

В экстренном порядке выпущены внеплановые корректирующие обновления для всех поддерживаемых веток PostgreSQL: 9.2.4, 9.1.9, 9.0.13 и 8.4.17, в которых устранено 5 уязвимостей, одна из которых признана критически опасной. Всем пользователям PostgreSQL 9.x рекомендуется незамедлительно осуществить обновление СУБД. Также для общего увеличения безопасности инфраструктуры разработчики PostgreSQL советуют проследить, чтобы из посторонних подсетей был закрыт доступ к сетевому порту PostgreSQL.

Критически опасная узявимость (СVE-2013-1899) проявляется только в ветках 9.x и позволяет инициировать повреждение файлов в директории с данными PostgreSQL через отправку специально оформленного запроса на присоединение к серверу, в котором фигурирует имя базы, начинающееся с символа "-" (имя базы обрабатывается как опция для однопользовательского режима восстановления, наличие подобной базы на сервере не требуется). Для осуществления атаки достаточно возможности доступа к сетевому порту PostgreSQL, наличие аккаунта в СУБД не требуется. Отмечается три основных сценария эксплуатации уязвимости:

Атакующий может инициировать добавление текста ошибки PostgreSQL в хвост существующих файлов в директории "data", что может привести к краху СУБД и невозможности перезапуска, без ручного удаления добавленного к файлам "хвоста";
Атакующий может повысить свои привилегии, если он уже имеет аккаунт в СУБД и его логин совпадает с именем БД, путем установки переменной конфигурации, которая даст ему права суперпользователя в СУБД;
Атакующий может выполнить произвольный код на сервере, если он уже имеет аккаунт в СУБД, его логин совпадает с именем БД и у него есть возможность сохранить файл в файловой системе сервера (в том, числе в директории /tmp). Активный SELinux защищает от указанного типа эксплуатации.

Описание менее опасных проблем, исправленных в новых выпусках PostgreSQL:

CVE-2013-1900 - позволяет угадать значения генератора случайных чисел, сгенерированных через функции contrib/pgcrypto для другого пользователя.
CVE-2013-1901 - позволяет непривилегированному пользователю выполнить команды, которые могут повлиять на содержимое выполняемой в текущий момент резервной копии.
CVE-2013-1902 - проявляется в создании графическим инсталлятором EnterpriseDB для Linux и Mac OS X временных файлов с предсказуемыми именами в директории /tmp.
CVE-2013-1903 - проявляется в небезопасной передаче инсталлятором EnterpriseDB пароля суперпользвоателя БД в один из скриптов.

Выпущенные обновления также содержат исправление ошибок, влияющих на стабильность. В том числе устранена серия проблем в управлении индексами GiST, что может потребовать выполнения операции REINDEX для подобных индексов.

исправить +9 +/–

Лицензия: CC BY 3.0

Короткая ссылка: https://opennet.ru/36588-postgresql

Ключевые слова: postgresql

При перепечатке указание ссылки на opennet.ru обязательно

Обсуждение (7)

1.1, Аноним (-), 21:20, 04/04/2013 [ответить]	+/–
Интересно, а кто-нибудь когда-нибудь использовал "-" в начале названия базы? Мне вот не приходило сталкиваться, но кто то вполне мог.

2.2, Max (??), 22:02, 04/04/2013 [^] [^^] [^^^] [ответить]	+/–
Как я понял, для эксплуатации этой уязвимости не обязательно, чтобы была база, начинающаяся с "-". Достаточно сделать запрос к базе такого вида.

3.4, Anonymous000 (?), 00:26, 05/04/2013 [^] [^^] [^^^] [ответить]	+/–
Не, не запрос, а именно при соединении указать базу. Фишка, как я понимаю, в том, что форкается воркер, парсит command line аргументы как бы он это сделал в single-user recovery-mode, и вуаля.

4.5, pavlinux (ok), 01:04, 05/04/2013 [^] [^^] [^^^] [ответить]

+/–

Два узбека поняли друг-друга.

#!/usr/bin/python

import psycopg2

try:
conn = psycopg2.connect("dbname='-fakedb' user='postgres' host='microsoft.com' password='billpass'")
except:
print "Unable 2 connect 2 ze database"

...

#include <postgresql/libpq-fe.h>

int main( void ) {

  char *str = "dbname=-fakedb user=postgres host=microsoft.com password=billpass";
  while (1)
    PQfinish(PQconnectdb(str));
}

как-то так.

2.3, Buy (ok), 23:35, 04/04/2013 [^] [^^] [^^^] [ответить]	+/–
> "имя базы обрабатывается как опция для однопользовательского режима восстановления, наличие подобной базы на сервере не требуется"

1.6, Аноним (-), 13:40, 05/04/2013 [ответить]	+/–
В Solaris 10 была ошибка один-в-один в telnet, в имени пользователя можно было передать команды для процесса login: telnet -l-f<user> <hostname> зайти под <user> без пароля :)

2.8, Аноним (-), 17:19, 05/04/2013 [^] [^^] [^^^] [ответить]	+/–
> В Solaris 10 была ошибка один-в-один в telnet, в имени пользователя можно > было передать команды для процесса login: telnet -l-f<user> <hostname> зайти под > <user> без пароля :) Вспомнил тоже. В Солярисе 10 телнет сервер был вырублен дефолтом в релизе 8/07. При инсталляции в режиме ограничения сетевых сервисов. А вообще, использовать телнет даже в 90х считалось уже моветоном. Даже в локалках. Тем более, SSH уже был изобретен.

игнорирование участников | лог модерирования

Добавить комментарий

Текст: