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

"В PostgreSQL устранена уязвимость, использованная при атаке на BeyondTrust"	+/–
Сообщение от opennews (??), 16-Фев-25, 16:31
Сформированы корректирующие обновления для всех поддерживаемых веток PostgreSQL  17.3, 16.7, 15.11, 14.16 и 13.19, в которых исправлено более 70 ошибок и устранена уязвимость (CVE-2025-1094), в конце декабря задействованная в   атаке на компанию BeyondTrust и Министерство финансов США. Проблема в PostgreSQL выявлена при  анализе  удалённой уязвимости (CVE-2024-12356) в сервисах BeyondTrust PRA (Privileged Remote Access) и BeyondTrust RS (Remote Support), при эксплуатации которой дополнительно была задействована ранее неизвестная (0-day) уязвимость в libpq... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=62722
Ответить | Правка | Cообщить модератору

Сообщения

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

2. "В PostgreSQL устранена уязвимость, использованная при атаке ..."	+3 +/–
Сообщение от Аноним (-), 16-Фев-25, 16:32
> Соответственно, байт 0x27 в такой последовательности остаётся не экранирован, > при том, что при обработке SQL-запроса в утилите psql он обрабатывается как кавычка. Сиквель такой сиквель. Bobby Tables наносит ответный удар!
Ответить | Правка | Наверх | Cообщить модератору

3. "В PostgreSQL устранена уязвимость, использованная при атаке ..."	+6 +/–
Сообщение от Аноним (3), 16-Фев-25, 16:36
Чем сильнее удешевляется производство софта, тем больше ошибок будет в нём. Тестирование сейчас вообще переложили на конечных пользователей.
Ответить | Правка | Наверх | Cообщить модератору

13. "В PostgreSQL устранена уязвимость, использованная при атаке ..."	+3 +/–
Сообщение от Карлос Сношайтилис (ok), 16-Фев-25, 17:15
Почему в одном продукте используются разные парсеры utf8?
Ответить | Правка | Наверх | Cообщить модератору

	31. "В PostgreSQL устранена уязвимость, использованная при атаке ..."	+/–
	Сообщение от филателист (?), 16-Фев-25, 22:17
	Много команд. Легаси... причины разные. Слишком большой продукт.
	Ответить | Правка | Наверх | Cообщить модератору

	39. "В PostgreSQL устранена уязвимость, использованная при атаке ..."	+/–
	Сообщение от EULA (?), 17-Фев-25, 05:22
	Это не легаси - это отсутствие архитектора ПО в команде. Он должен определять набор инструментария в коде
	Ответить | Правка | Наверх | Cообщить модератору

	40. "В PostgreSQL устранена уязвимость, использованная при атаке ..."	+1 +/–
	Сообщение от n00by (ok), 17-Фев-25, 09:14
	Ныне демократия и каждый архитектор.
	Ответить | Правка | Наверх | Cообщить модератору

17. "В PostgreSQL устранена уязвимость, использованная при атаке ..."	+2 +/–
Сообщение от Аноним (-), 16-Фев-25, 17:59
> Уязвимость проявляется в библиотеке libpq, предоставляющей > API для взаимодействия с СУБД из программ на языке Си > Уязвимость вызвана отсутствием в функциях экранирования проверки > корректности используемых в тексте Unicode-символов Абсолютно неудивительно при отсутствии поддержки utf8 из коробки. В итоге в двух либах на одном и том же может быть две разные реализации поддержки utf8. А то и три.
Ответить | Правка | Наверх | Cообщить модератору

	36. "В PostgreSQL устранена уязвимость, использованная при атаке ..."	–1 +/–
	Сообщение от Аноним (36), 17-Фев-25, 00:52
	Хорошая попытка разобраться в том, что произошло, но вина на пхп, а точнее на факте того, что зачем-то этот пхп там что-то экранирует и код исполняет. Что это за монстр где между двумя сишками проложили скрипт, который тебе код при нужном запросе исполнит.
	Ответить | Правка | Наверх | Cообщить модератору

20. "В PostgreSQL устранена уязвимость, использованная при атаке ..."	+4 +/–
Сообщение от Аноним (20), 16-Фев-25, 18:16
Я ничего не понял. Там не использовались подготовленные запросы, вместо этого полагались на внешние функции экранирования?! Подготовленные запросы - стандартная практика: удобно, надёжно, безопасно. Выглядит так, как будто сотрудник, писавший код, специально оставил бэкдор, а потом уволился, и его проэксплуатировал. Либо как если там такой код со времён отсутствия подготовленных запросов в принципе, код был куплен злоумышленниками у инсайдеров, и после этого нашли. Понятно, откуда такая уязвимость в PostgreSQL - экранирование давно никто в здравом уме не использует.
Ответить | Правка | Наверх | Cообщить модератору

	35. "В PostgreSQL устранена уязвимость, использованная при атаке ..."	+1 +/–
	Сообщение от anonymos (?), 17-Фев-25, 00:42
	А это - правильный вопрос!
	Ответить | Правка | Наверх | Cообщить модератору

	41. "В PostgreSQL устранена уязвимость, использованная при атаке ..."	+1 +/–
	Сообщение от n00by (ok), 17-Фев-25, 09:18
	Если кто-то прочёл написанное выше и не понял, что такое "подготовленный запрос", ему следует не лезть в поисковик, а сменить вид деятельности. Если не хочет, значит принудительно. Новость показывает, почему такие деятели опасны для остальных.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	42. "В PostgreSQL устранена уязвимость, использованная при атаке ..."	+1 +/–
	Сообщение от Аноним (42), 17-Фев-25, 11:38
	А также сменить вид деятельности тем, кто использует "подготовленный запрос" вместо prepared statement.
	Ответить | Правка | Наверх | Cообщить модератору

	44. "В PostgreSQL устранена уязвимость, использованная при атаке ..."	+/–
	Сообщение от Аноним (44), 17-Фев-25, 15:33
	> А также с*ечь на костре всех формалистов
	Ответить | Правка | Наверх | Cообщить модератору

	45. "В PostgreSQL устранена уязвимость, использованная при атаке ..."	+/–
	Сообщение от n00by (ok), 17-Фев-25, 16:25
	Совершенно не важно, как там оно названо: речь о способности размышлять, а не угождать белому господину.
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

	43. "В PostgreSQL устранена уязвимость, использованная при атаке ..."	+/–
	Сообщение от Другой аноним (?), 17-Фев-25, 11:54
	Дада конечно. В курсе что например драйвер JDBC будет делать запрос с литералами, даже если вы честный буратино и в своём коде Java используете подготовленные запросы. Параметр prepareThreshold, по умолчанию 5. Только на 5-й повторённый запрос с PreparedStatement это будет действительно PreparedStatement. Предыдущие 4 с литералами.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	47. "В PostgreSQL устранена уязвимость, использованная при атаке ..."	+1 +/–
	Сообщение от похнапоха. (?), 18-Фев-25, 14:08
	А тебя не смущает, что PreparedStatement - это ИНТЕРФЕЙС и его реализация ложится на поставщика JDBC драйвера?
	Ответить | Правка | Наверх | Cообщить модератору

34. "В PostgreSQL устранена уязвимость, использованная при атаке ..."	+/–
Сообщение от Аноним (-), 16-Фев-25, 23:06
Интересно, а хедеры всех браузеров от того же защищены?
Ответить | Правка | Наверх | Cообщить модератору

37. "В PostgreSQL устранена уязвимость, использованная при атаке ..."	–1 +/–
Сообщение от fidoman (ok), 17-Фев-25, 03:39
>В приложениях BeyondTrust >через утилиту командной строки psql В приложениях... или в по-бырому наляпаных на коленке скриптах?
Ответить | Правка | Наверх | Cообщить модератору

	49. "В PostgreSQL устранена уязвимость, использованная при атаке ..."	+/–
	Сообщение от нах. (?), 18-Фев-25, 18:00
	это приложению такое! (я и похужее видал)
	Ответить | Правка | Наверх | Cообщить модератору

38. "В PostgreSQL устранена уязвимость, использованная при атаке ..."	+2 +/–
Сообщение от Аноним (38), 17-Фев-25, 03:47
Ждем фикс фикса 20го числа, ибо исправляя CVE умудрились влепить регрессию.
Ответить | Правка | Наверх | Cообщить модератору

46. "В PostgreSQL устранена уязвимость, использованная при атаке ..."	+/–
Сообщение от Аноним (46), 18-Фев-25, 12:51
У меня Postgres до сих пор на KOI8. Думаете, пора ли переходить на локаль UTF8?
Ответить | Правка | Наверх | Cообщить модератору

	50. "В PostgreSQL устранена уязвимость, использованная при атаке ..."	+/–
	Сообщение от нах. (?), 18-Фев-25, 18:08
	cp1251 should be enough for all (причем это в общем и целом так и есть, а при попытке подсунуть в базу смайлик - надо просто п-дить дубиной по жопе)
	Ответить | Правка | Наверх | Cообщить модератору

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

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