- Регистрация
- 18.01.19
- Сообщения
- 1,603
- Депозит
- 60,333 ₽
- Сделки (гарант)
- 13
Специалисты компании Google подсчитали, что примерно 70% проблем с безопасность в кодовой базе Chrome связаны с управлением памятью. Теперь в компании пытаются понять, как лучше решить эту проблему.
В общей сложности инженеры Google изучили 912 ошибок («высокой» или «критической» степени серьезности), исправленных в стабильной ветке Chrome с 2015 года. Как оказалась, половина из вышеупомянутых 70% — это use-after-free уязвимости, возникающие из-за некорректного управления указателями памяти, что в итоге открывает внутренние компоненты Chrome для атак.
Интересно, что выводы экспертов Google хорошо соотносятся со статистикой компании Microsoft, которая еще в прошлом году пришла к похожему выводу: за последние 12 лет 70% патчей для продуктов компании были выпущены для проблем с безопасностью памяти.
В сущности, обе компании страдают от одной и того же: использования языков C и C ++, которые считаются «небезопасными». Дело в том, что это весьма старые инструменты, созданные десятки лет назад, в то время, когда кибератаки и эксплуатация уязвимостей не представляли такой угрозы, как сейчас, и большинство разработчиков ПО попросту не думали о подобных нюансах.
Так, имея дело с C и C ++, разработчики имеют полный контроль над управлением указателями памяти в приложении. Не существует никаких ограничений или предупреждений, чтобы предупреждать разработчиков, если те совершают базовые ошибки в вопросах управления памятью. В результате в приложениях возникает множество уязвимостей, связанных с переполнением буфера, use-after-free, состоянием гонки, double free и так далее.
Подобные уязвимости весьма востребованы среди злоумышленников, ведь такие баги могут использоваться для внедрения кода в память устройства и последующего запуска этого кода в целевом приложении (браузере, сервере, ОС и так далее).
Инженеры Google пишут, что в период с марта 2019 года по настоящее время в Chrome было устранено 130 критических уязвимостей. Из них 125 были так или иначе связаны с нарушением целостности информации в памяти. То есть, невзирая на достижения разработчиков в области исправления ошибок других классов, управление памятью по-прежнему остается проблемой.
Все это стало настолько большой проблемой для Google, что теперь инженеры, работающие над Chrome, обязаны следовать «Правилу двух». Согласно этому правилу, когда Chrome-разработчики пишут новую функцию, их код может нарушать не более двух из перечисленных условий:
код обрабатывает недоверенный ввод;
код работает без песочницы;
код написан на небезопасном языке программирования (C/C ++).
До недавнего времени инженеры Google были большими сторонниками использования песочницы в Chrome. Так, они изолировали десятки процессов в собственной программной среде и развернули Site Isolation (помещает ресурсы каждого сайта в свои собственные изолированные процессы в песочнице). Однако теперь компания вынуждена искать другие подходы, отмечая, что использование песочниц в настоящее время достигло своего максимума с учетом производительности.
В дальнейшем Google планирует заняться разработкой кастомных библиотек C ++ с лучшей защитой от ошибок, связанных с памятью. Эти библиотеки будут использоваться с кодовой базой Chrome. Также инженеры компании изучают возможность использования проекта MiraclePtr, целью которого — превратить use-after-free уязвимости в несвязанные с безопасностью сбои, которые будут минимально влиять на производительность, стабильность, память и размер бинарников.
Кроме того, Google заявляет, что намеревается исследовать использование более «безопасных» языков программирования там, где это возможно. Речь идет о Rust, Swift, JavaScript, Kotlin и Java.
В общей сложности инженеры Google изучили 912 ошибок («высокой» или «критической» степени серьезности), исправленных в стабильной ветке Chrome с 2015 года. Как оказалась, половина из вышеупомянутых 70% — это use-after-free уязвимости, возникающие из-за некорректного управления указателями памяти, что в итоге открывает внутренние компоненты Chrome для атак.
Интересно, что выводы экспертов Google хорошо соотносятся со статистикой компании Microsoft, которая еще в прошлом году пришла к похожему выводу: за последние 12 лет 70% патчей для продуктов компании были выпущены для проблем с безопасностью памяти.
В сущности, обе компании страдают от одной и того же: использования языков C и C ++, которые считаются «небезопасными». Дело в том, что это весьма старые инструменты, созданные десятки лет назад, в то время, когда кибератаки и эксплуатация уязвимостей не представляли такой угрозы, как сейчас, и большинство разработчиков ПО попросту не думали о подобных нюансах.
Так, имея дело с C и C ++, разработчики имеют полный контроль над управлением указателями памяти в приложении. Не существует никаких ограничений или предупреждений, чтобы предупреждать разработчиков, если те совершают базовые ошибки в вопросах управления памятью. В результате в приложениях возникает множество уязвимостей, связанных с переполнением буфера, use-after-free, состоянием гонки, double free и так далее.
Подобные уязвимости весьма востребованы среди злоумышленников, ведь такие баги могут использоваться для внедрения кода в память устройства и последующего запуска этого кода в целевом приложении (браузере, сервере, ОС и так далее).
Инженеры Google пишут, что в период с марта 2019 года по настоящее время в Chrome было устранено 130 критических уязвимостей. Из них 125 были так или иначе связаны с нарушением целостности информации в памяти. То есть, невзирая на достижения разработчиков в области исправления ошибок других классов, управление памятью по-прежнему остается проблемой.
Все это стало настолько большой проблемой для Google, что теперь инженеры, работающие над Chrome, обязаны следовать «Правилу двух». Согласно этому правилу, когда Chrome-разработчики пишут новую функцию, их код может нарушать не более двух из перечисленных условий:
код обрабатывает недоверенный ввод;
код работает без песочницы;
код написан на небезопасном языке программирования (C/C ++).
До недавнего времени инженеры Google были большими сторонниками использования песочницы в Chrome. Так, они изолировали десятки процессов в собственной программной среде и развернули Site Isolation (помещает ресурсы каждого сайта в свои собственные изолированные процессы в песочнице). Однако теперь компания вынуждена искать другие подходы, отмечая, что использование песочниц в настоящее время достигло своего максимума с учетом производительности.
В дальнейшем Google планирует заняться разработкой кастомных библиотек C ++ с лучшей защитой от ошибок, связанных с памятью. Эти библиотеки будут использоваться с кодовой базой Chrome. Также инженеры компании изучают возможность использования проекта MiraclePtr, целью которого — превратить use-after-free уязвимости в несвязанные с безопасностью сбои, которые будут минимально влиять на производительность, стабильность, память и размер бинарников.
Кроме того, Google заявляет, что намеревается исследовать использование более «безопасных» языков программирования там, где это возможно. Речь идет о Rust, Swift, JavaScript, Kotlin и Java.
