70% проблем с безопасностью в Chromium вызваны ошибками при работе с памятью

24 мая 2020 года

Разработчики проекта Chromium проанализировали 912 опасных и критических уязвимостей, выявленных в стабильных выпусках Chrome с 2015 года, и пришли к выводу, что 70% из них были вызваны небезопасной работой с памятью (ошибками при работе с указателями в коде на C/C++). Половина из данных проблем (36.1%) вызвана обращениями к буферу после освобождения связанной с ним памяти (use-after-free).

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

Для поддержания безопасности кодовой базы Google также применяет "правило двух", в соответствии с которым любой добавляемый код должен подпадать не больше, чем под два условия из трёх: работа с непроверенными входными данными, использование небезопасного языка программирования (C/C++) и выполнение с повышенными привилегиями. Из этого правила следует, что код для обработки внешних данных должен либо быть урезан до минимальных привилегий (изолирован), либо быть написан на безопасном языке программирования.

Для дальнейшего усиления защищённости кодовой базы запущен проект по предотвращению появления ошибок работы с памятью в кодовой базе. Выделяется три основных подхода: создание библиотек С++ с функциями для безопасной работы с памятью и расширение области применения сборщика мусора, применение аппаратных механизмов защиты MTE (Memory Tagging Extension) и написание компонентов на языках, обеспечивающих безопасную работу с памятью (Java, Kotlin, JavaScript, Rust, Swift).

Ожидается, что работа будет сосредоточена в двух направлениях:

• Значительное изменение процесса разработки на С++, не исключающее негативного влияния на производительность (дополнительные проверки границ и сборка мусора). Вместо raw-указателей предлагается использовать в коде тип MiraclePtr, позволяющий свести эксплуатируемые ошибки класса use-after-free к не представляющим угрозу безопасности крахам, без ощутимого негативного влияния на производительность, потребление памяти и стабильность.
• Применение языков, рассчитанных на выполнение проверок безопасной работы с памятью во время компиляции (позволит исключить негативное влияние на производительность, свойственное подобным проверкам во время выполнения кода, но приведёт к дополнительным расходам на организацию взаимодействия кода на новом языке с кодом на С++).

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

Источники

Creative Commons

Эта статья содержит материалы из статьи «70% проблем с безопасностью в Chromium вызваны ошибками при работе с памятью», опубликованной OpenNET и распространяющейся на условиях лицензии Creative Commons Attribution (CC BY) — указание автора, источник и лицензию.

Эта статья загружена автоматически ботом NewsBots и ещё не проверялась редакторами Викиновостей.
Любой участник может оформить статью: добавить иллюстрации, викифицировать, заполнить шаблоны и добавить категории.
Любой редактор может снять этот шаблон после оформления и проверки.

Комментарии

Викиновости и Wikimedia Foundation не несут ответственности за любые материалы и точки зрения, находящиеся на странице и в разделе комментариев.

Мнения

Пожалуйста, прочтите правила общения и оформления реплик на портале Викиновости

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

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

Несколько советов по оформлению реплик:

• Новые темы начинайте, пожалуйста, снизу.
• Используйте символ звёздочки «*» в начале строки для начала новой темы. Далее пишите свой текст.
• Для ответа в начале строки укажите на одну звёздочку больше, чем в предыдущей реплике.
• Пожалуйста, подписывайте все свои сообщения, используя четыре тильды (~~~~). При предварительном просмотре и сохранении они будут автоматически заменены на ваше имя и дату.

Обращаем ваше внимание, что комментарии не предназначены для размещения ссылок на внешние ресурсы не по теме статьи, которые могут быть удалены или скрыты любым участником. Тем не менее, на странице комментариев вы можете сообщить о статьях в СМИ, которые ссылаются на эту заметку, а также о её обсуждении на сторонних ресурсах.

Добавить комментарий