On Wed, 25 Aug 2021 22:58:03 +0300 Vitaly Lipatov wrote:
> Andrey Savchenko писал 25.8.21 22:14:
> > On Wed, 25 Aug 2021 20:14:41 +0300 Dmitry V. Levin wrote:
> >> On Wed, Aug 25, 2021 at 12:18:40PM +0300, Andrey Savchenko wrote:
> ...
> >> > Динамическая линковка лишь создаёт иллюзию безопасности за счёт
> >> > исправления проблемы в одной библиотеке сразу для всех. Но проблема
> >> > может быть в хедерах, а C++ библиотеки всё больше переходят
> >> > в хедеры. В итоге может получится, что CVE исправлен, библиотека
> >> > обновлена без изменения ABI, а непересобранные приложения всё ещё
> >> > уязвимы.
> >> 
> >> А безопаснее всего публиковать только исходники, и пусть пользователи
> >> сами пересобирают, как сочтут нужным, правда же?
> > 
> > На этот вопрос нельзя однозначно ответить, поскольку в таком
> > случае задача обеспечения безопасности во многом перекладывается на
> > пользователей и ответ зависит от их квалификации. Так вернёмся к
> > обсуждению DSO vs static в бинарном дистрибутиве общего назначения.
> > 
> > 1) Безопасность.
> > 
> > Выше я привёл пример, когда DSO лишь маскирует проблему
> > безопасности, но не решает её. В случае со static очевидно, что
> > пересобирать нужно всех потребителей (при необходимости рекурсивно).
> > Так что относительно просто реализовать механизм контроля
> > гарантированного исправления ошибок и уязвимостей среди
> > прямых и косвенных пользователей библиотеки.
> > 
> > В случае с DSO может возникнуть крайне опасная ситуация скрытого
> > наличия уязвимости, когда CVE в библиотеке исправлен, по
> > setversions с клиентами всё хорошо, мы успешно заявили об
> > исправлении данной CVE в дистрибутиве, а в реальности уязвимость
> > кое-где осталась.
> > 
> > Самым простым решением данной проблемы будет безусловная пересборка
> > всех зависимостей, так же, как и со static — но в таком случае
> > никаких преимуществ у DSO не остаётся.
> > 
> > Можно попробовать отслеживать, были ли изменения хедеров
> > и пересобирать безусловно только в таком случае — но это более
> > сложный и в то же время всё ещё грубый путь решения задачи, т.к. не
> > всякое изменение в хедере ведёт к изменению бинарного кода
> > в клиенте.
> Я бы хотел добавить только, что
> в реальной жизни эта проблема решается проще — при исправлении CVE 
> проект выпускает новую версию библиотеки, и если вдруг уязвимость 
> требует пересборки клиентов (из-за её исправления в заголовочных 
> файлах), то об этом сообщат пользователям библиотеки (в описании 
> релиза).

Некоторые апстримы ушли по-умолчанию целиком в хедеры и отдельно не
выделяют такие ситуации, например, cgal.

> Также, как я понимаю, достаточно сложно создать уязвимость именно в том 
> коде, который генерируется при сборке приложения, а не библиотеки. Разве 
> известны такие случаи?

Я отдельно не искал. Но почему ошибка в реализации шаблона
представляется невероятной?

Best regards,
Andrew Savchenko