Кис Кук Я делаю сообщение в блоге, в котором выразил обеспокоенность по поводу процесса исправления ошибок продолжается в стабильных ветвях ядра Linux и является ли упомянуть, что еженедельно вносится около сотни исправлений в стабильных ветках, что слишком много и требует больших усилий для поддержки продуктов на основе ядра Linux.
По словам Кеса, процесс обработки ошибок ядра игнорируется и ядру не хватает как минимум 100 дополнительных разработчиков согласованно работать в этой сфере. Помимо упоминания о том, что основные разработчики ядра регулярно исправляют ошибки, но нет гарантии, что эти исправления будут перенесены на сторонние варианты ядра.
При этом он упоминает, что пользователи различных продуктов на основе ядра Linux также не имеют возможности контролировать, какие ошибки исправлены и какое ядро используется на их устройствах. В конечном счете, поставщики несут ответственность за безопасность своих продуктов, но столкнувшись с очень большим количеством исправлений в стабильных ветвях ядра, они столкнулись с выбором: переносить все исправления, выборочно переносить наиболее важные или игнорировать все исправления. .
Разработчики ядра апстрима могут исправлять ошибки, но они не могут контролировать, что нижестоящий поставщик выбирает для включения в свои продукты. Конечные пользователи могут выбирать свои продукты, но, как правило, они не могут контролировать, какие ошибки будут исправлены или какое ядро используется (проблема сама по себе). В конечном итоге поставщики несут ответственность за безопасность своих продуктов.
Кис Кук предполагает, что оптимальным решением будет перенос только самых важных исправлений и уязвимостей, но основная проблема состоит в том, чтобы отделить эти ошибки от общего потока, поскольку большинство возникающих проблем являются следствием использования языка C, который требует большой осторожности при работе с памятью и указателями.
Что еще хуже, многие исправления потенциальных уязвимостей не помечены идентификаторами CVE или не получают идентификатор CVE через некоторое время после выпуска исправления.
В такой среде производителям очень сложно отделить мелкие исправления от серьезных проблем безопасности. Согласно статистике, более 40% уязвимостей удаляются до назначения CVE, а в среднем задержка между выпуском исправления и назначением CVE составляет три месяца (то есть вначале a воспринимает решение как частую ошибку,
В результате отсутствие отдельной ветки с исправлениями уязвимостей и не получая информации о связи с безопасностью той или иной проблемы, производители продуктов на базе ядра Linux должны постоянно передавать все исправления новых стабильных веток. Но эта работа является трудоемкой и встречает сопротивление со стороны компаний из-за опасений регрессионных изменений, которые могут нарушить нормальную работу продукта.
Ключи повар считает, что единственное решение сохранить безопасность ядра по разумной цене в долгосрочной перспективе - это переместить инженеров по исправлению к сумасшедшим сборкам ядраl работать вместе согласованно для поддержки исправлений и уязвимостей в исходном ядре. В настоящее время многие производители не используют последние версии ядра в своих продуктах и исправлениях обратного порта сами по себе, то есть получается, что инженеры из разных компаний дублируют работу друг друга, решая одну и ту же проблему.
Например, если 10 компаний, в каждой из которых есть инженер, поддерживающий одни и те же исправления, перенаправят этих инженеров для исправления ошибок вверх по течению, вместо того, чтобы переносить одно исправление, они могут исправить 10 разных ошибок для общей выгоды или собраться вместе, чтобы просмотреть ошибки. Предлагаемые изменения . И избегайте включения кода с ошибками в ядро. Ресурсы также можно использовать для создания новых инструментов анализа и тестирования кода, которые будут автоматически обнаруживать на ранней стадии типичные классы ошибок, которые возникают снова и снова.
Ключи повар также предлагает более активно использовать автоматическое тестирование и фаззинг непосредственно в процессе разработки ядра, используйте системы непрерывной интеграции и откажитесь от архаичного управления разработкой через электронную почту.
источник: https://security.googleblog.com