В экстренном порядке выпущены (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/
Новость: http://www.opennet.me/opennews/art.shtml?num=36588
Интересно, а кто-нибудь когда-нибудь использовал "-" в начале названия базы? Мне вот не приходило сталкиваться, но кто то вполне мог.
Как я понял, для эксплуатации этой уязвимости не обязательно, чтобы была база, начинающаяся с "-". Достаточно сделать запрос к базе такого вида.
Не, не запрос, а именно при соединении указать базу.Фишка, как я понимаю, в том, что форкается воркер, парсит command line аргументы как бы он это сделал в single-user recovery-mode, и вуаля.
Два узбека поняли друг-друга.
#!/usr/bin/pythonimport 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));
}как-то так.
> "имя базы обрабатывается как опция для однопользовательского режима восстановления, наличие подобной базы на сервере не требуется"
В Solaris 10 была ошибка один-в-один в telnet, в имени пользователя можно было передать команды для процесса login: telnet -l-f<user> <hostname> зайти под <user> без пароля :)
> В Solaris 10 была ошибка один-в-один в telnet, в имени пользователя можно
> было передать команды для процесса login: telnet -l-f<user> <hostname> зайти под
> <user> без пароля :)Вспомнил тоже. В Солярисе 10 телнет сервер был вырублен дефолтом в релизе 8/07. При инсталляции в режиме ограничения сетевых сервисов. А вообще, использовать телнет даже в 90х считалось уже моветоном. Даже в локалках. Тем более, SSH уже был изобретен.