The OpenNET Project / Index page

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

Обновление PostgreSQL с устранением уязвимостей

14.11.2020 11:17

Сформированы корректирующие обновления для всех поддерживаемых веток PostgreSQL: 13.1, 12.5, 11.10, 10.15, 9.6.20 и 9.5.24. Обновления для ветки 9.5 будут формироваться до февраля 2021 г., 9.6 - до ноября 2021 года, 10 - до ноября 2022 года, 11 - до ноября 2023 года, 12 - до ноября 2024 года, 13 до ноября 2025 года.

Всем пользователям рекомендовано срочно установить обновление в связи с устранением уязвимости CVE-2020-25695, которая позволяет выполнить произвольные функции SQL с правами администратора при наличии доступа к созданию постоянных объектов в любой схеме хранения. При невозможности выполнить обновление в качестве обходного пути блокирования проблемы можно отключить autovacuum и не запускать вручную операции ANALYZE, CLUSTER, REINDEX, CREATE INDEX, VACUUM FULL и REFRESH MATERIALIZED VIEW, а также не выполнять восстановление БД на основе вывода команды pg_dump. Выполнение VACUUM без опции FULL признано безопасным, как и выполнение любых команд при работе с объектами, принадлежащими пользователю.

Дополнительно устранены ещё две уязвимости:

  • CVE-2020-25694 - позволяет откатить клиентское соединение до менее безопасного состояния (без флагов channel_binding, sslmode, requirepeer и gssencmode), например, для отключения шифрования с целью организации MITM-атаки. Проблема проявляется только для соединений с сервером приложений clusterdb, pg_dump, pg_restore, psql, reindexdb и vacuumdb.
  • CVE-2020-25696 - команда \gset в psql позволяет переопределить специальные переменные и организовать выполнение кода с правами процесса psql при обращении при помощи команды \gset к серверу, подконтрольному злоумышленнику.


  1. Главная ссылка к новости (https://www.postgresql.org/abo...)
  2. OpenNews: Релиз СУБД PostgreSQL 13
  3. OpenNews: Для PostgreSQL подготовлено дополнение AGE для хранения данных в форме графа
  4. OpenNews: PostgreSQL Anonymizer 0.6, расширение для анонимизации данных в СУБД
  5. OpenNews: Обновление PostgreSQL с устранением уязвимости. Выпуск системы репликации pgcat
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/54088-postgresql
Ключевые слова: postgresql
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (52) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, InuYasha (??), 11:25, 14/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Патченный слоник - хороший слоник.
     
  • 1.2, Аноним (2), 11:36, 14/11/2020 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • –33 +/
     

     ....ответы скрыты (10)

  • 1.5, Анонимленьлогиниться (?), 12:37, 14/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    13 как падала на создании GIST индексов по триграмам, так и 13.1 ровно в том же месте падает :-(

    Остаемся на 12, она стабильная..

     
     
  • 2.7, Аноним (7), 12:46, 14/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Число нехорошее, по-видимому :|
     
  • 2.9, Аанон (?), 12:50, 14/11/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А багу зарегали?
     
     
  • 3.26, Анонимленьлогиниться (?), 19:54, 14/11/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > А багу зарегали?

    Нет. Как ни пытался, не смог сделать минимальное воспроизведение - т.е. оно не зависит от конкретных данных, на таблице 10000 строк падает, на таблице 5000 строк (любая половина этих 10000) - нет. Репорт с реальными данными сделать не могу (да и им нужно предсказуемое воспроизведение).

    Нашел только что падает особенно резво при попытке указать fillfactor отличный от дефолтного. Причем с некоторыми падает, с некоторыми нет.

    На табличке на 100000 строк падает и без указания fillfactor. Чем больше табличка, тем резвее падает. Падает весь сервер, натурально, без каких-либо внятных сообщений.

    Очень надеялся, что в 13.1 что-то станет лучше, но увы. Думаю, мало кто использует gist индексы... В первых релизах 12 (12.0/12.1) тоже было падение на этой же табличке ровно на этом же индексе :)) Но там падало иначе, в wal writer, при этом выводилось некое сообщение об ошибке, в итоге кто-то зарепортил такую же багу (https://www.postgresql.org/message-id/16162-45d21b7b6c1a3105@postgresql.o) и начиная с 12.2 исправили и получилось проапгрейдиться на 12.

    А вот 13 уже падает главный процесс.. внятной ошибки не выводится.. ждем репортов.

     
     
  • 4.31, мяя (?), 23:40, 14/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А отладчиком к процессу подключиться и получить стек вызовов с ошибкой при падении навыков нет?
     
     
  • 5.34, Анонимленьлогиниться (?), 00:30, 15/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > А отладчиком к процессу подключиться и получить стек вызовов с ошибкой при
    > падении навыков нет?

    Есть, равно как и понимание что без отладочной инфы (а почему-то в pgdg стали собирать без debuginfo) и потом траты кучи времени на объяснение разработчикам, где как и что реального результата не получится. А это время мне, увы, не оплачивается.. Так что я лучше займусь задачами, которые нужны тому, кто мне платит :)

     
     
  • 6.35, Аноним (35), 00:58, 15/11/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    В debian принято отладочные символы в отдельные deb упаковывать, их просто нужно поставить и у вас появятся отладочные символы в отладчике.
     
     
  • 7.43, Анонимленьлогиниться (?), 18:02, 15/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > В debian принято отладочные символы в отдельные deb упаковывать, их просто нужно
    > поставить и у вас появятся отладочные символы в отладчике.

    Это в редхате. Да, они раньше паковали debuginfo.. К 9 например.. но почему-то к последним версиям перестали. Видимо, багрепортов больше не ждут.

     
     
  • 8.46, Мелкий (?), 18:40, 16/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Devrim сопровождающий rpm репы решил в отдельный репозиторий вынести https y... текст свёрнут, показать
     
     
  • 9.48, Анонимленьлогиниться (?), 23:46, 17/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Это тут не причем, но Мало собрать debuginfo Надо собрать их к нужным пакетам... большой текст свёрнут, показать
     
     
  • 10.51, Анонимленьлогиниться (?), 00:03, 18/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    gt оверквотинг удален Ох Посыпаю голову пеплом я понял, в чем проблема Деб... текст свёрнут, показать
     
  • 10.52, Мелкий (?), 00:11, 18/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, к rpm репе действительно есть вопросы А даже вот такой backtrace на самом... текст свёрнут, показать
     
  • 6.45, тральшик (?), 07:33, 16/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    http://apt.postgresql.org/pub/repos/apt/pool/main/p/postgresql-13/postgresql- не оно?
     
     
  • 7.49, Анонимленьлогиниться (?), 23:48, 17/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > http://apt.postgresql.org/pub/repos/apt/pool/main/p/postgresql-13/postgresql-
    > не оно?

    нет )
    Оно оказалось тут https://download.postgresql.org/pub/repos/yum/debug/13/redhat/rhel-8.3-x86_64/
    но собрано неправильно и нужный дебагинфо к -contrib пакету не соответствует самому пакету, см. комментарий выше. Ну да ладно.

     
  • 4.33, JL2001 (ok), 00:16, 15/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >> А багу зарегали?
    > Нет. Как ни пытался, не смог сделать минимальное воспроизведение

    сообщите хотяб в таком виде, возможно, вам там напишут или волшебные флаги или способ диагностики или помогут с минимизацией или созданием абстрактного набора данных для теста

     
     
  • 5.36, Anon_noXX (?), 04:47, 15/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    a self-compiled Postgres 12.1

    I could successfully ... running a default-configured packaged version of postgres 12 for ubuntu 16.04

    Может, оно? А может быть jit? Или ФС - zfs.

     
     
  • 6.37, Anon_noXX (?), 04:54, 15/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Впрочем, я погорячился, товарищи из Core Team проблему подтверждают. Сорри.
     
     
  • 7.38, Anon_noXX (?), 04:57, 15/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    И опять я не прав, переписка-то 2019 годом заканчивается :)
     
     
  • 8.41, JL2001 (ok), 15:36, 15/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    так ворвитесь в тред и апните топик может у них не на ком воспроизвести зы а вы... текст свёрнут, показать
     
     
  • 9.42, Анонимленьлогиниться (?), 18:01, 15/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да нет Там бага была другая совсем Кто-то доопотимизировался при записи WAL в ... текст свёрнут, показать
     
  • 2.19, Аноним (19), 14:33, 14/11/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    номер репорта есть ?
     
  • 2.47, DEF (?), 20:53, 17/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Обратитесь к Олегу Бартунову! Это один из ключевых разработчиков. Он обязательно поможет. Его контакты легко гуглятся.
     
     
  • 3.50, Анонимленьлогиниться (?), 23:49, 17/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Обратитесь к Олегу Бартунову! Это один из ключевых разработчиков. Он обязательно поможет.
    > Его контакты легко гуглятся.

    Спасибо. Уже кто-то зарепортил аналогичный баг (см. комментарий выше) и сделали экспериментальный патч.. может в следующем релизе поправят и падать перестанет.

     

  • 1.11, Аноним (2), 13:10, 14/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    Почему не в одном хостинге я не видел САБЖ? Один лишь MySQL, прямо какой-то заговор
     
     
  • 2.12, Аноним (12), 13:28, 14/11/2020 [^] [^^] [^^^] [ответить]  
  • –9 +/
    Потому что сабж плохо управляем в целом, да и производительность из-за постоянной необходимости вакуума (ну, если не хочешь хранить гигабайты ненужных удалённых строк) у него так себе.
     
     
  • 3.21, Аноним (19), 15:24, 14/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    это было до 8.1, когда не было автовакуума. сейчас все пучком даже на больших нагрузках
     
  • 2.14, Аноним (14), 13:38, 14/11/2020 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Не заговор, а не востребован.
     
  • 2.16, Аноним (15), 13:55, 14/11/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Почему не в одном хостинге я не видел САБЖ? Один лишь MySQL, прямо какой-то заговор

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

     
     
  • 3.22, BSA (?), 15:57, 14/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    VPS из той же ниши, что и хостинг. Серьезную нагрузку не тянет, а если загрузить на сколько тянет, то хостер будет возмущаться, что ты слишком много ресурсов потребляешь.
     
     
  • 4.28, Аноним (28), 21:34, 14/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    В случае с ДО там топовые конфигурации получали значительно больше ресурсов и меньше соседей с шиткоинами. Линода вроде меньше оверселлила. Возмущений что-то не припомню, зато помню как в зависимости от поведения соседей менялась производительность.
     
  • 4.29, лютый жабби__ (?), 21:36, 14/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >VPS из той же ниши, что и хостинг.

    бред. у хетцнеров даже самый просто vps за 3 евро просто реактивный, что по процу, что по IO.
    на многих задачах оно просто рвёт парумилионные железные серверы (более старые и без SSD) )

     
  • 2.17, Иван (??), 13:56, 14/11/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Например?
    У меня ровно наоборот. Забыл когда последний раз видел mysql/mariadb.
     
  • 2.24, Аноним (24), 17:24, 14/11/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Что вы имеете в виду под хостингом?
    AWS - постгрес есть. Google Cloud - постгрес есть. Azure - постгрес есть.  DigitalOcean - постгрес есть. Yandex.Cloud - постгрес есть. Mail.ru cloud solutions - постгрес есть.
     
     
  • 3.44, Аноним (44), 23:42, 15/11/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если раньше под сайт достаточно было виртуального хоста + фтп + MySQL, то теперь надо отдельная виртуальная машина в облаке с операционкой в докере с постгресом, с операционной в докер с нджинксом, с операционной в докер с питоном, с кубернетесом, что бы запускать этот зоопарк докеров, не забываем про еластик стек, графану, прометеус, что там ещё молодёжно?
     
  • 2.25, zzz (??), 18:01, 14/11/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Потому что мамкины вебмастера не умеют в что-то сложнее SELECT * FROM?
     
  • 2.27, Casm (??), 20:33, 14/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Gitlab, например, только с postgresql работает
     
  • 2.53, ptr128 (?), 15:33, 21/11/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Если MySQL достаточно, то почему бы и нет?
    А вот для DW MySQL мало пригоден, тогда как PostgreSQL отлично с многотерабайтными БД справляется. Хоть и не без костылей, как принято в OpenSource )

     

  • 1.23, Ilya Indigo (ok), 16:25, 14/11/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –8 +/
    Оказывается VACUUM теперь не только к тормознутости приводит (сам git-подобный движок хранения, которому он нужен), но ещё и к проблеме с безопасностью.
     
     
  • 2.40, Аноним (40), 15:13, 15/11/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Работает не трожь
     

  • 1.39, Аноним (40), 15:10, 15/11/2020 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • –3 +/
     

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



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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