The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Обновление PostgreSQL с устранением уязвимости. Выпуск pg_ivm 1.0

12.05.2022 22:58

Сформированы корректирующие обновления для всех поддерживаемых веток PostgreSQL: 14.3, 13.7, 12.11, 11.16 и 10.22. Ветка 10.x приближается к окончанию срока поддержки (обновления будут формироваться до ноября 2022 года). Выпуск обновлений для ветки 11.x продлится до ноября 2023 года, 12.x - до ноября 2024 года, 13.x - до ноября 2025 года, 14.x - до ноября 2026 года.

В новых версиях предложено более 50 исправлений и устранена уязвимость CVE-2022-1552, связанная с возможностью обхода изоляции выполнения привилегированных операций Autovacuum, REINDEX, CREATE INDEX, REFRESH MATERIALIZED VIEW, CLUSTER и pg_amcheck. Атакующий, имеющий полномочия создания не временных объектов в любой схеме хранения, может добиться выполнения произвольных SQL-функций с правами суперпользователя во время выполнения привилегированным пользователем вышеотмеченных операций, затрагивающих объект атакующего. В том числе эксплуатация уязвимости может произойти при автоматической чистке базы при выполнении обработчика autovacuum.

При невозможности выполнить обновление в качестве обходного пути блокирования проблемы можно отключить autovacuum и не выполнять привилегированным пользователем операции REINDEX, CREATE INDEX, REFRESH MATERIALIZED VIEW и CLUSTER, а также не запускать утилиту pg_amcheck и не восстанавливать содержимое из резервной копии, созданной утилитой pg_dump. Выполнение VACUUM признано безопасным, как и применение любых операции команд, если обрабатываемые объекты принадлежат пользователям, заслуживающим доверия.

Из других изменений в новых выпусках можно отметить обновление кода JIT для работы с LLVM 14, разрешение использования шаблонов database.schema.table в утилитах psql, pg_dump и pg_amcheck, исправление проблем, приводящих к повреждению индексов GiST над столбцами ltree, неверному округлению значений в формате epoch, извлечённых из данных с типом interval, неверной работы планировщика при использовании асинхронных удалённых запросов, неверной сортировке строк таблицы при использовании выражения CLUSTER над индексами с ключами на базе выражений, потере данных при аварийном завершении сразу после построения отсортированного индекса GiST, взаимной блокировке при удалении секционированного индекса, состоянию гонки между операцией DROP TABLESPACE и фиксацией состояния (checkpoint).

Дополнительно можно отметить выпуск расширения pg_ivm 1.0 с реализацией поддержки IVM (Incremental View Maintenance) для PostgreSQL 14. IVM предлагает альтернативный способ обновления материализованных представлений, более эффективный в случае, если изменения затрагивают небольшую часть представления. IVM позволяет мгновенно обновлять материализованные представления, применяя к ним только инкрементальные изменения, без повторного вычисления представления, производимого при использовании операции "REFRESH MATERIALIZED VIEW".

  1. Главная ссылка к новости (https://www.postgresql.org/abo...)
  2. OpenNews: Обновление PostgreSQL. Выпуск reshape, утилиты для миграции на новую схему без остановки работы
  3. OpenNews: Конфликт, связанный с торговыми марками PostgreSQL, остаётся не урегулирован
  4. OpenNews: Один из разработчиков MySQL раскритиковал проект и рекомендовал использовать PostgreSQL
  5. OpenNews: Обновление PostgreSQL с устранением уязвимостей. Выпуск балансировщика соединений Odyssey 1.2
  6. OpenNews: Amazon открыл код Babelfish, расширений для замены MS SQL Server на PostgreSQL
Лицензия: CC-BY
Тип: Проблемы безопасности
Короткая ссылка: https://opennet.ru/57180-postgresql
Ключевые слова: postgresql
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (30) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 23:12, 12/05/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    В mssql и oracle такое часто находят?
     
     
  • 2.2, Аноним (2), 23:18, 12/05/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Чаще https://www.oracle.com/security-alerts/cpuapr2022.html#AppendixDB
     
     
  • 3.19, Анонимленьлогиниться (?), 10:40, 13/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Сравнивать просто число ошибок тут неуместно, т.к. Оракл как продукт раз в 10 больше постгри в плане разноплановости - там и Java VM, и RAC, и свой сторейдж и тп. Даже по ссылке гляньте, *где именно* уязвимости - generic ODBC, protobuf-java и тп
     
  • 2.9, Аноним (9), 06:46, 13/05/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    С каждым релизом любого форка MySQL по 20-30 CVE за раз.
     
     
  • 3.17, Аноним (1), 09:39, 13/05/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вопрос был не про mysql.
     
  • 2.22, Аноним (22), 12:10, 13/05/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Там такое и не только лучше спрятано.
     
     
  • 3.24, Аноним (1), 12:29, 13/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Пруфы? Я просто припоминаю, что у Оркала была примерно такая же уязвимость с правами не так давно, вот и хочу узнать, есть ли такая статистика, в частности, для обожаемой в индустрии майкрософтовской поделки. Ну а так там и продукт куда серьёзнее, в нём вполне может быть больше проблем, но и денег влито тоже больше.
     

  • 1.3, Аноним (3), 23:24, 12/05/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Данные надо хранить в банковских ячейках, а не вот это вот всё.
     
     
  • 2.4, ыы (?), 23:49, 12/05/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Точно! Распечатанные на несгораемой бумаге в двух экземплярах.
    И ячейки должны хранится в двух разных банках...

    Процесс обновления и синхронизации правда геморный.. Но то такое...

     
     
  • 3.5, Аноним (5), 23:55, 12/05/2022 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Больше ста лет только так и делали и всё работало.
     
     
  • 4.12, Брат Анон (ok), 07:48, 13/05/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Угу, Мавроди подтвердит.
     
     
  • 5.23, Аноним (22), 12:13, 13/05/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Уже не подтвердит.
     
     
  • 6.28, Брат Анон (ok), 19:57, 13/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Уже не подтвердит.

    Мавроди бессмертен. Крипта подтверждает.

     
  • 4.14, Аноним (14), 08:12, 13/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    И копьями и мечами больше ста лет воевали и всё работало, а теперь давай, поставь когорту мечников против "когорты автоматчиков".
     
     
  • 5.27, Аноним (27), 18:26, 13/05/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Автоматы надо запретить, они не юниксвейны, их злые корпорасты проталкивают.
    И можно будет дальше мечами махать.
     
     
  • 6.31, Dima (??), 11:18, 15/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Калаш и РПГ-7 делают все кому не лень, по всему миру.
     
  • 2.6, kai3341 (ok), 00:25, 13/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >  Данные надо хранить в банковских ячейках, а не вот это вот всё.

    И передавать голубиной почтой. RFC 1149 делали профессионалы, а не всякие смузихлёбы

     
     
  • 3.30, InuYasha (??), 19:57, 14/05/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В RFC 1149 уже завели сборщик...мусора?
     
  • 2.11, Брат Анон (ok), 07:47, 13/05/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Если только не банковская ячейка, а литровая банка.
    И не в банке, а на огороде, на грядке. И не бумага, а изделия из серебра и золота.
     

  • 1.7, menangen (?), 01:09, 13/05/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Что ещё за LLVM JIT в базе данных, нахрена??
     
     
  • 2.8, aa (?), 06:11, 13/05/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    возможно для выполнения хранимых процедур, которые могут быть на разных языках, в том числе с поддержкой этого самого джита
     
     
  • 3.10, Аноним (9), 06:50, 13/05/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Там не хранимые процедуры, а сами запросы компилируются на лету перед исполнением.

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

     
     
  • 4.13, Брат Анон (ok), 07:50, 13/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Хранимые процедуры тоже. На питхоне, например. Они, внезапно, тоже исполняют длинные сложные запросы.
     
     
  • 5.15, Аноним (15), 08:52, 13/05/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    JIT это для SQL. За код на питоне-перле-тикле отвечают соответствующие интерпетаторы со своими оптимизирующими свистоперделками.
     
     
  • 6.16, Брат Анон (ok), 09:21, 13/05/2022 [^] [^^] [^^^] [ответить]  
  • –4 +/
    > JIT это для SQL. За код на питоне-перле-тикле отвечают соответствующие интерпетаторы со
    > своими оптимизирующими свистоперделками.

    Угу расскажи это numba, cython, pyllvm.

     
     
  • 7.20, Анонимленьлогиниться (?), 10:41, 13/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    И что из этого доступно в хранимках на питоне в постгре? Правильно, ничего. Там даже права доступа нормально не работают...
     
  • 7.21, Аноним (-), 11:27, 13/05/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    не даром у тебя аватарка дегенерата
     
     
  • 8.25, Аноним (22), 12:32, 13/05/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это же Ильич в молодости ... текст свёрнут, показать
     

  • 1.26, Аноним (26), 18:25, 13/05/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    не нужно
     
     
  • 2.29, Аноним (29), 09:08, 14/05/2022 [^] [^^] [^^^] [ответить]  
  • +/
    О да, скажи это ещё разок!!!
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2022 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру