Несколько недель назад сообщество Linux потрясла тревожная новость о том, что исследователи из Университета Миннесоты разработали (но, как оказалось, не полностью реализовали) метод внедрения в ядро ​​Linux того, что они называли «лицемерными фиксациями». – идея состоит в том, чтобы распространять поведение, которое трудно обнаружить, само по себе бессмысленное, которое впоследствии может быть выровнено злоумышленниками для выявления уязвимостей.

За этим быстро последовало – в некотором смысле не менее тревожное – объявление о том, что в университете есть было запрещено, по крайней мере временно, участвовать в разработке ядра. За этим последовали публичные извинения от исследователей.

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

В равной степени несомненно, что сопровождающие и руководство проекта обязаны обеспечивать соблюдение политики и не тратить свое время зря. Здравый смысл подсказывает (и требует пользователей), что они стремятся выпускать выпуски ядра, не содержащие эксплойтов. Но при убийстве мессенджера упускается по крайней мере кое-что – что это было исследование, а не чистая злоба, и что оно проливает свет на своего рода программную (и организационную) уязвимость, требующую технического и системного смягчения.

Я думаю, что попытки «лицемера совершают» – это симптом со всех сторон связанных тенденций, которые угрожают всей расширенной экосистеме с открытым исходным кодом и ее пользователям. Эта экосистема долгое время боролась с проблемами масштаба, сложности и того, что бесплатное программное обеспечение с открытым исходным кодом (СОПО) приобретает все более важное значение для всех видов человеческой деятельности. Давайте посмотрим на этот комплекс проблем:

• Крупнейшие проекты с открытым исходным кодом теперь ставят перед собой большие задачи.
• Их сложность и темп выросли за пределы масштабов, с которыми могут справиться традиционные подходы «общего пользования» или даже более развитые модели управления. [19659012] Они развиваются, чтобы превращать друг друга в товар. Например, становится все труднее однозначно утверждать, следует ли считать «Linux» или «Kubernetes» «операционной системой» для распределенных приложений. Коммерческие организации приняли это к сведению и начали реорганизацию вокруг портфелей и описаний «полного цикла».
• Поступая таким образом, некоторые коммерческие организации начали искажать традиционные модели участия FOSS. Сейчас много экспериментов. Между тем, финансирование, обязательства по численности персонала для FOSS и другие показатели, похоже, снижаются.
• Проекты и экосистемы OSS адаптируются по-разному, что иногда мешает коммерческим организациям чувствовать себя как дома или видеть выгоду от участия.

Между тем ландшафт угроз продолжает развиваться:

• Злоумышленники становятся крупнее, умнее, быстрее и терпеливее, что приводит к долгим играм, подрыву цепочки поставок и т. Д.
• Атаки более прибыльны с финансовой, экономической и политической точек зрения, чем когда-либо.
• Пользователи более уязвимы, подвержены большему количеству векторов, чем когда-либо прежде.
• Растущее использование общедоступных облаков создает новые уровни технических и организационных монокультур, которые могут способствовать и оправдать атаки.
• Сложные коммерческие готовые решения. Решения (COTS), частично или полностью собранные из программного обеспечения с открытым исходным кодом, создают сложные поверхности для атак, компоненты (и взаимодействия) которых доступны и хорошо понятны злоумышленникам.
• Soft Компонентизация программного обеспечения позволяет использовать новые виды атак на цепочку поставок.
• Между тем, все это происходит, когда организации стремятся избавиться от нестратегического опыта, переложить капитальные затраты на операционные расходы и развиваться, чтобы зависеть от поставщиков облачных услуг и других организаций, выполняющих тяжелую работу безопасность.

Конечный результат состоит в том, что масштабные и критичные проекты ядра Linux не готовы бороться с изменяющими правила игры гипермасштабируемыми моделями угроз. В конкретном случае, который мы рассматриваем здесь, исследователи смогли нацелить сайты-кандидаты на вторжения с относительно небольшими усилиями (используя инструменты статического анализа для оценки блоков кода, которые уже идентифицированы как требующие внимания со стороны участников), предложить «исправления» неофициально по электронной почте и использовать множество факторов, в том числе их собственную репутацию надежных и частых участников, чтобы довести код эксплойта до предела.

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

Но как бороться с такими угрозами? Формальная проверка практически невозможна в большинстве случаев. Статический анализ не может выявить тщательно спланированные вторжения. Темпы проекта должны поддерживаться (в конце концов, есть известные ошибки, которые нужно исправить). И угроза асимметрична: согласно классической линии – синяя команда должна защищать от всего, красная команда должна добиться успеха только один раз.

Я вижу несколько возможностей для исправления:

• Ограничьте распространение монокультур. Такие вещи, как Alva Linux и AWS Open Distribution of ElasticSearch, хороши отчасти потому, что они оставляют широко используемые решения FOSS бесплатными и с открытым исходным кодом, но также потому, что они вносят техническое разнообразие.
• Переоценить управление проектом, организацию и финансирование с целью смягчения последствий полная уверенность в человеческом факторе, а также стимулирование коммерческих компаний делиться своим опытом и другими ресурсами. Большинство коммерческих компаний были бы счастливы внести свой вклад в открытый исходный код из-за его открытости, а не вопреки этому, но во многих сообществах это может потребовать изменения культуры для существующих участников.
• Ускорьте превращение в товар, упростив стек и проверив составные части. Возложите соответствующую ответственность за безопасность на уровни приложений.

По сути, я выступаю за то, чтобы оркестраторы, такие как Kubernetes, имели меньшее значение, а Linux – меньшее влияние. Наконец, мы должны как можно быстрее приступить к формализации использования таких вещей, как unikernels.

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