forum.opennet.ru - "В PostgreSQL 9.2.4, 9.1.9 и 9.0.13 устранена критическая уяз..." (7)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"В PostgreSQL 9.2.4, 9.1.9 и 9.0.13 устранена критическая уяз..."

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"В PostgreSQL 9.2.4, 9.1.9 и 9.0.13 устранена критическая уяз..."	+/–
Сообщение от opennews (??) on 04-Апр-13, 21:20
В экстренном порядке выпущены (http://www.postgresql.org/about/news/1456/) внеплановые корректирующие обновления для всех поддерживаемых веток PostgreSQL: 9.2.4 (http://www.postgresql.org/docs/current/static/release-9-2-4....), 9.1.9 (http://www.postgresql.org/docs/9.1/static/release-9-1-9.html), 9.0.13 (http://www.postgresql.org/docs/current/static/release-9-0-13...) и 8.4.17 (http://www.postgresql.org/docs/current/static/release-8-4-17...), в которых устранено 5 уязвимостей (http://www.postgresql.org/support/security/), одна из которых признана критически опасной. Всем пользователям PostgreSQL 9.x рекомендуется незамедлительно осуществить обновление СУБД. Также для общего увеличения безопасности инфраструктуры разработчики PostgreSQL советуют (http://www.postgresql.org/support/security/faq/2013-04-04/) проследить, чтобы из посторонних подсетей был закрыт доступ к сетевому порту PostgreSQL. Критически опасная узявимость (СVE-2013-1899) проявляется только в ветках 9.x и позволяет инициировать повреждение файлов в директории с данными PostgreSQL через отправку специально оформленного запроса на присоединение к серверу, содержащего имя базы, начинающееся с символа "-". Для осуществления атаки достаточно возможности доступа к сетевому порту PostgreSQL, наличие аккаунта в СУБД не требуется. Что касается менее опасных проблем: - CVE-2013-1900 - позволяет угадать значения генератора случайных чисел, сгенерированных через функции contrib/pgcrypto для другого пользователя. - CVE-2013-1901 - позволяет непривилегированному пользователю выполнить команды, которые могут повлиять на содержимое выполняемой в текущий момент резервной копии. - CVE-2013-1902 - проявляется в создании графическим инсталлятором EnterpriseDB для Linux и Mac OS X временных файлов с предсказуемыми именами в директории /tmp. - CVE-2013-1903 - проявляется в небезопасной передаче инсталлятором EnterpriseDB пароля суперпользвоателя БД в один из скриптов. Выпущенные обновления также содержат исправление ошибок, влияющих на стабильность. В том числе устранена серия пробоем в управлении индексами GiST, что может потребовать выполнения операции REINDEX для подобных индексов. URL: http://www.postgresql.org/about/news/1456/ Новость: https://www.opennet.ru/opennews/art.shtml?num=36588
Ответить \| Правка \| Cообщить модератору

Оглавление

В PostgreSQL 9.2.4, 9.1.9 и 9.0.13 устранена критическая уяз..., Аноним, 21:20 , 04-Апр-13, (1) +1

В PostgreSQL 9.2.4, 9.1.9 и 9.0.13 устранена критическая уяз..., Max, 22:02 , 04-Апр-13, (2)

В PostgreSQL 9.2.4, 9.1.9 и 9.0.13 устранена критическая уяз..., Anonymous000, 00:26 , 05-Апр-13, (4)

В PostgreSQL 9.2.4, 9.1.9 и 9.0.13 устранена критическая уяз..., pavlinux, 01:04 , 05-Апр-13, (5)

В PostgreSQL 9.2.4, 9.1.9 и 9.0.13 устранена критическая уяз..., Buy, 23:35 , 04-Апр-13, (3)

В PostgreSQL 9.2.4, 9.1.9 и 9.0.13 устранена критическая уяз..., Аноним, 13:40 , 05-Апр-13, (6)

В PostgreSQL 9.2.4, 9.1.9 и 9.0.13 устранена критическая уяз..., Аноним, 17:19 , 05-Апр-13, (8)

Сообщения по теме [Сортировка по времени | RSS]

1. "В PostgreSQL 9.2.4, 9.1.9 и 9.0.13 устранена критическая уяз..." +1 +/–

Сообщение от Аноним (??) on 04-Апр-13, 21:20

Интересно, а кто-нибудь когда-нибудь использовал "-" в начале названия базы? Мне вот не приходило сталкиваться, но кто то вполне мог.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "В PostgreSQL 9.2.4, 9.1.9 и 9.0.13 устранена критическая уяз..." +/–

Сообщение от Max (??) on 04-Апр-13, 22:02

Как я понял, для эксплуатации этой уязвимости не обязательно, чтобы была база, начинающаяся с "-". Достаточно сделать запрос к базе такого вида.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

4. "В PostgreSQL 9.2.4, 9.1.9 и 9.0.13 устранена критическая уяз..." +/–

Сообщение от Anonymous000 on 05-Апр-13, 00:26

Не, не запрос, а именно при соединении указать базу.
Фишка, как я понимаю, в том, что форкается воркер, парсит command line аргументы как бы он это сделал в single-user recovery-mode, и вуаля.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

5. "В PostgreSQL 9.2.4, 9.1.9 и 9.0.13 устранена критическая уяз..." +/–

Сообщение от pavlinux (ok) on 05-Апр-13, 01:04

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

#!/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));
}
как-то так.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

3. "В PostgreSQL 9.2.4, 9.1.9 и 9.0.13 устранена критическая уяз..." +/–

Сообщение от Buy (ok) on 04-Апр-13, 23:35

> "имя базы обрабатывается как опция для однопользовательского режима восстановления, наличие подобной базы на сервере не требуется"

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

6. "В PostgreSQL 9.2.4, 9.1.9 и 9.0.13 устранена критическая уяз..." +/–

Сообщение от Аноним (??) on 05-Апр-13, 13:40

В Solaris 10 была ошибка один-в-один в telnet, в имени пользователя можно было передать команды для процесса login: telnet -l-f<user> <hostname> зайти под <user> без пароля :)

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

8. "В PostgreSQL 9.2.4, 9.1.9 и 9.0.13 устранена критическая уяз..." +/–

Сообщение от Аноним (??) on 05-Апр-13, 17:19

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

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "В PostgreSQL 9.2.4, 9.1.9 и 9.0.13 устранена критическая уяз..."	+1 +/–
Сообщение от Аноним (??) on 04-Апр-13, 21:20
Интересно, а кто-нибудь когда-нибудь использовал "-" в начале названия базы? Мне вот не приходило сталкиваться, но кто то вполне мог.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	2. "В PostgreSQL 9.2.4, 9.1.9 и 9.0.13 устранена критическая уяз..."	+/–
	Сообщение от Max (??) on 04-Апр-13, 22:02
	Как я понял, для эксплуатации этой уязвимости не обязательно, чтобы была база, начинающаяся с "-". Достаточно сделать запрос к базе такого вида.
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	4. "В PostgreSQL 9.2.4, 9.1.9 и 9.0.13 устранена критическая уяз..."	+/–
	Сообщение от Anonymous000 on 05-Апр-13, 00:26
	Не, не запрос, а именно при соединении указать базу. Фишка, как я понимаю, в том, что форкается воркер, парсит command line аргументы как бы он это сделал в single-user recovery-mode, и вуаля.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	5. "В PostgreSQL 9.2.4, 9.1.9 и 9.0.13 устранена критическая уяз..."	+/–
	Сообщение от pavlinux (ok) on 05-Апр-13, 01:04
	Два узбека поняли друг-друга. #!/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)); } как-то так.
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	3. "В PostgreSQL 9.2.4, 9.1.9 и 9.0.13 устранена критическая уяз..."	+/–
	Сообщение от Buy (ok) on 04-Апр-13, 23:35
	> "имя базы обрабатывается как опция для однопользовательского режима восстановления, наличие подобной базы на сервере не требуется"
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору

6. "В PostgreSQL 9.2.4, 9.1.9 и 9.0.13 устранена критическая уяз..."	+/–
Сообщение от Аноним (??) on 05-Апр-13, 13:40
В Solaris 10 была ошибка один-в-один в telnet, в имени пользователя можно было передать команды для процесса login: telnet -l-f<user> <hostname> зайти под <user> без пароля :)
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	8. "В PostgreSQL 9.2.4, 9.1.9 и 9.0.13 устранена критическая уяз..."	+/–
	Сообщение от Аноним (??) on 05-Апр-13, 17:19
	> В Solaris 10 была ошибка один-в-один в telnet, в имени пользователя можно > было передать команды для процесса login: telnet -l-f<user> <hostname> зайти под > <user> без пароля :) Вспомнил тоже. В Солярисе 10 телнет сервер был вырублен дефолтом в релизе 8/07. При инсталляции в режиме ограничения сетевых сервисов. А вообще, использовать телнет даже в 90х считалось уже моветоном. Даже в локалках. Тем более, SSH уже был изобретен.
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору