Сформированы корректирующие обновления для всех поддерживаемых веток 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.me/opennews/art.shtml?num=62722

• В PostgreSQL устранена уязвимость, использованная при атаке ...,Аноним, 16:32 , 16-Фев-25
• В PostgreSQL устранена уязвимость, использованная при атаке ...,Аноним, 16:36 , 16-Фев-25
• В PostgreSQL устранена уязвимость, использованная при атаке ...,Карлос Сношайтилис, 17:15 , 16-Фев-25
  • В PostgreSQL устранена уязвимость, использованная при атаке ...,филателист, 22:17 , 16-Фев-25
    • В PostgreSQL устранена уязвимость, использованная при атаке ...,EULA, 05:22 , 17-Фев-25
      • В PostgreSQL устранена уязвимость, использованная при атаке ...,n00by, 09:14 , 17-Фев-25
• В PostgreSQL устранена уязвимость, использованная при атаке ...,Аноним, 17:59 , 16-Фев-25
  • В PostgreSQL устранена уязвимость, использованная при атаке ...,Аноним, 00:52 , 17-Фев-25
• В PostgreSQL устранена уязвимость, использованная при атаке ...,Аноним, 18:16 , 16-Фев-25
  • В PostgreSQL устранена уязвимость, использованная при атаке ...,anonymos, 00:42 , 17-Фев-25
  • В PostgreSQL устранена уязвимость, использованная при атаке ...,n00by, 09:18 , 17-Фев-25
    • В PostgreSQL устранена уязвимость, использованная при атаке ...,Аноним, 11:38 , 17-Фев-25
      • В PostgreSQL устранена уязвимость, использованная при атаке ...,Аноним, 15:33 , 17-Фев-25
      • В PostgreSQL устранена уязвимость, использованная при атаке ...,n00by, 16:25 , 17-Фев-25
  • В PostgreSQL устранена уязвимость, использованная при атаке ...,Другой аноним, 11:54 , 17-Фев-25
    • В PostgreSQL устранена уязвимость, использованная при атаке ...,похнапоха., 14:08 , 18-Фев-25
• В PostgreSQL устранена уязвимость, использованная при атаке ...,Аноним, 23:06 , 16-Фев-25
• В PostgreSQL устранена уязвимость, использованная при атаке ...,fidoman, 03:39 , 17-Фев-25
  • В PostgreSQL устранена уязвимость, использованная при атаке ...,нах., 18:00 , 18-Фев-25
• В PostgreSQL устранена уязвимость, использованная при атаке ...,Аноним, 03:47 , 17-Фев-25
• В PostgreSQL устранена уязвимость, использованная при атаке ...,Аноним, 12:51 , 18-Фев-25
  • В PostgreSQL устранена уязвимость, использованная при атаке ...,нах., 18:08 , 18-Фев-25

> Соответственно, байт 0x27 в такой последовательности остаётся не экранирован,
> при том, что при обработке SQL-запроса в утилите psql он обрабатывается как кавычка.

Сиквель такой сиквель. Bobby Tables наносит ответный удар!

Чем сильнее удешевляется производство софта, тем больше ошибок будет в нём. Тестирование сейчас вообще переложили на конечных пользователей.

Почему в одном продукте используются разные парсеры utf8?

Много команд. Легаси... причины разные. Слишком большой продукт.

Это не легаси - это отсутствие архитектора ПО в команде.
Он должен определять набор инструментария в коде

Ныне демократия и каждый архитектор.

> Уязвимость проявляется в библиотеке libpq, предоставляющей
> API для взаимодействия с СУБД из программ на языке Си
> Уязвимость вызвана отсутствием в функциях экранирования проверки
> корректности используемых в тексте Unicode-символов

Абсолютно неудивительно при отсутствии поддержки utf8 из коробки.
В итоге в двух либах на одном и том же может быть две разные реализации поддержки utf8. А то и три.

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

Я ничего не понял. Там не использовались подготовленные запросы, вместо этого полагались на внешние функции экранирования?! Подготовленные запросы - стандартная практика: удобно, надёжно, безопасно. Выглядит так, как будто сотрудник, писавший код, специально оставил бэкдор, а потом уволился, и его проэксплуатировал. Либо как если там такой код со времён отсутствия подготовленных запросов в принципе, код был куплен злоумышленниками у инсайдеров, и после этого нашли. Понятно, откуда такая уязвимость в PostgreSQL - экранирование давно никто в здравом уме не использует.

А это - правильный вопрос!

Если кто-то прочёл написанное выше и не понял, что такое "подготовленный запрос", ему следует не лезть в поисковик, а сменить вид деятельности. Если не хочет, значит принудительно. Новость показывает, почему такие деятели опасны для остальных.

А также сменить вид деятельности тем, кто использует "подготовленный запрос" вместо prepared statement.

> А также

с*ечь на костре всех формалистов

Совершенно не важно, как там оно названо: речь о способности размышлять, а не угождать белому господину.

Дада конечно. В курсе что например драйвер JDBC будет делать запрос с литералами, даже если вы честный буратино и в своём коде Java используете подготовленные запросы. Параметр prepareThreshold, по умолчанию 5. Только на 5-й повторённый запрос с PreparedStatement это будет действительно PreparedStatement. Предыдущие 4 с литералами.

А тебя не смущает, что PreparedStatement - это ИНТЕРФЕЙС и его реализация ложится на поставщика JDBC драйвера?

Интересно, а хедеры всех браузеров от того же защищены?

>В приложениях BeyondTrust
>через утилиту командной строки psql

В приложениях... или в по-бырому наляпаных на коленке скриптах?

это приложению такое!
(я и похужее видал)

Ждем фикс фикса 20го числа, ибо исправляя CVE умудрились влепить регрессию.

У меня Postgres до сих пор на KOI8.
Думаете, пора ли переходить на локаль UTF8?

cp1251 should be enough for all

(причем это в общем и целом так и есть, а при попытке подсунуть в базу смайлик - надо просто п-дить дубиной по жопе)