От переводчика: я наткнулся на TheUpdateFramework при поиске библиотек, реализующих автоматическое обновление ПО на десктопе. С одной стороны, мне показалось интересным и обстоятельным представленное ниже описание аспектов безопасности систем обновления ПО; с другой — наверняка помимо академических исследований, хоть и под крылом LinuxFoundation, можно найти много годных решений. Можете предлагать варианты в комментариях.

Безопасность

Мы можем считать систему обновления ПО "безопасной", если:

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

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

Атаки и недостатки

Ниже перечислены некоторые из известных атак на системы обновления ПО, включая слабости, делающие эти атаки возможными. Чтобы спроектировать безопасный фреймворк обновления ПО, необходимо понять эти атаки и разработать стратегии защиты. Некоторые из этих недостатков могут быть связаны друг с другом, в зависимости от архитектуры и реализации определенной системы обновления ПО.

• Установка произвольного ПО. Атакующий может подставить произвольные файлы в ответ на запросы на скачивание и установить всё что пожелает в клиентскую систему, даже без определения неправомерности таких действий.
• Атаки отката обновления. Атакующий предоставляет системе обновления ПО файлы более старой версии, чем сейчас установлена на клиенте. Пользователь устанавливает версию, которая возможно содержит уязвимости, без возможности узнать, что эта версия устарела. Позднее уязвимости могут эксплуатироваться атакующим.
• Атаки перемотки. Атакующий произвольным образом увеличивает номер версии, делая ее намного выше текущего значения, таким образом обманывая систему обновления ПО и заставляя ее считать, что любые последовательные апдейты на самом деле пытаются откатить версию ПО на клиента на предыдущую, устаревшую версию. В некоторых ситуациях, например в случае наличия максимально возможного номера версии, преступник может использовать этот максимум, чтобы система обновления никогда не смогла установить новый апдейт.
• Атаки неограниченной заморозки. Атакующий продолжает возвращать системе обновления ПО файлы, которые клиент уже видел. В результате, клиент продолжает находиться в неведении насчет новых версий ПО.
• Атаки бесконечных данных. В ответ на запрос на скачивание атакующий возвращает бесконечный поток данных, напрямую причиняя вред клиенту (например, заполнением диска или оперативной памяти).
• Атаки медленного ответа. Атакующий отвечает клиентам очень медленным потоком данных, что в конечном итоге приводит к тому, что клиент никак не может завершить процесс обновления ПО.
• Атаки лишних зависимостей. Атакующий сообщает клиенту, что для установки требуемого ПО также требуется установить стороннее ПО (привет, mail.ru — прим. пер.). Это стороннее ПО может быть из надежного источника, но тем не менее иметь известные уязвимости, которые может эксплуатировать злоумышленник.
• Атаки со смешанным сочетанием. Атакующий возвращает клиенту снимок репозитория, который содержит файлы, никогда не существовавшие в одной ревизии одновременно. Это может приводить к установке устаревших версий зависимостей и другим, более сложным последствиям.
• Установка другого ПО. Атакующий возвращает клиенту доверенный файл, который просто не является тем, что хотел установить клиент.
• Вредоносные зеркала, предотвращающие обновления. Атакующий контролирует одно из зеркал репозитория и может использовать его для предотвращения получения клиентами обновлений из других, не зараженных зеркал.
• Уязвимости компроментации ключей. Атакующий, которые может скомпрометировать единственный в системе ключ (или несколько ключей, числом не более заданного порога), может скомпрометировать клиентов. Эти атаки могут возникать как в случае доверия единственному онлайн-ключу (например, при защите обновлений только SSL-шифрованием), так и в случае единственного оффлайн-ключа (для большинства систем обновления ПО, которые используют ключи для подписи).

Принципы обеспечения безопасности

Для того, чтобы убедиться в защищенности системы от всех описанных выше атак, архитектура и реализация Фреймворка Обновлений (TUF) полагается на несколько основных концепций. Подробности того, как TUF передает информацию, описанную выше, можно посмотреть в документации к метаданным.

Доверие

Доверие к загруженным файлам в действительности означает предположение, что файлы были предоставлены стороной без уязвимых архитектурных решений. Двумя часто ускользающими от внимания аспектами доверия в системе обновления ПО являются следующие:

• Доверие не должно предоставляться навечно. Необходимо отзывать доверие, если оно не обновляется.
• Доверие не должно предоставляться одинаково для всех участников. Этот тип разделенного доверия означает, что можно доверять только тем файлам участника, предоставление которых данным участником оговорено корневой ролью.

Уменьшение рисков для ключей (устойчивость к компроментации)

Криптографические подписи являются обязательным компонентом обеспечения безопасности в системах обновления ПО. Безопасность ключей, используемых в данных подписях, напрямую влияет на безопасность клиентов, которых защищает система. Вместо того, чтобы наивно полагать, что приватные ключи никогда не могут быть скомпрометированы, безопасные системы обновления ПО должны предвидеть, как уберечь клиентов от возможности компроментации этих ключей. Это основной принцип устойчивости к компроментации.

Обеспечение безопасности клиентов при компрометации ключа включает в себя:

• Быструю и безопасную замену и отзыв ключа.
• Минимальное доверие ключам с высоким риском компроментации. Ключи, которые хранятся онлайн или используются в системах автоматизации не должны создавать мгновенную угрозу для клиентов при компрометации.
• Использование множества ключей и порог/кворум подписей.

Целостность

Обеспечение целостности в Фреймворке Обновлений (TUF) относится не только к отдельным файлам, но также и к репозиторию в целом. Довольно очевидно, что клиенты должны проверять, что отдельные файлы корректны. Уже не так очевидно, но всё ещё очень важно для клиентов быть уверенными, что ревизия репозитория в целом корректна. Например, если доверенный источник предоставляет два файла, система обновления ПО должна видеть последние версии обоих файлов (не только одного), и только те версии этих двух файлов, которые существуют в репозитории одновременно.

Актуальность

Так как обновления ПО часто исправляют уязвимости, для систем обновления ПО важно получать последние доступные версии. Атакующий может попробовать заставить клиента установить устаревшие версии ПО или просто убедить клиента в том, что новые обновления отсутствуют.

Обеспечение актуальности означает:

• Никогда не принимать файлы более старые чем те, что уже установлены.
• Определять возможные проблемы с получением обновлений.

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

Безопасность реализации

В добавление к безопасной архитектуре, в TUF также ведется работа против уязвимостей реализации, включая уязвимости, общие для систем обновления ПО. В некоторых случаях для этого используется включение дополнительной информации в метаданные обновлений. Например, знание об ожидаемом размере скачиваемого файла позволяет TUF ограничить объем скачиваемых данных. В результате, TUF защищен против атаки бесконечных данных, обсуждавшейся выше.