Max Home IndustryНу какой сюрприз! Любой программист на C или C ++ скажет вам, что неправильное управление памятью — самая большая проблема, с которой они сталкиваются. Но 70% всех проблем с безопасностью связано с памятью — это может быть больше, чем ожидалось.
Одно из главных достоинств C / C ++ — возможность работать с памятью на очень низком уровне. Конечно, это тоже их недостаток. Слишком легко ошибиться. Самая распространенная ошибка — «использовать после освобождения». Это происходит, когда вы пытаетесь использовать указатель на память после того, как память была освобождена. Иногда это работает, потому что система не уничтожила или не перераспределила память, и ваша программа получает своего рода бесплатную поездку. Затем, когда-нибудь в будущем, система действительно перейдет к освобождению и даже повторному использованию памяти, и результаты будут непредсказуемыми.
Это настолько известная проблема, что большинство программистов C / C ++ стараются не допустить ошибки, и все же команда Chromium заявляет, что 36% всех выявленных ими проблем безопасности являются «use-after-free». Эту ошибку так просто обнаружить, что можно подумать, что ее можно избежать, но ее также легко сделать. Освобождение памяти происходит в одном месте программы, а использование — в другом. Эти два места часто разделены по времени, а также по loc, и в результате появляется висячий указатель, потерянный в пространстве.
Анализ, недавно проведенный командой безопасности Chromium, рассматривает проблемы, обнаруженные в коде 2015 года. К сожалению, остальная часть анализа не столь информативна. Остальные проблемы с памятью называются просто «Другая небезопасная память», на которые приходится около трети от общего числа, но можно поспорить, что это включает в себя переполнение указателя. Там есть всеохватывающие неинформативные категории «Другое» и «Утверждение, связанное с безопасностью» с долями 24% и 7% соответственно.
Цифра 70% согласуется с более ранним выводом Microsoft: ошибки безопасности памяти составляют 70 процентов уязвимостей.
Сообщение также включает заявление:
«Архитектура безопасности Chromium всегда создавалась с учетом того, что эти ошибки существуют, а код изолирован, чтобы они не захватили хост-машину. За последние годы эта архитектура была улучшена, чтобы гарантировать изоляцию веб-сайтов друг от друга. Эти огромные усилия позволил нам — просто — опередить злоумышленников. Но мы приближаемся к пределам песочницы и изоляции сайтов ».
Каково решение? В сообщении говорится, что могут быть полезны три идеи. Во-первых, использовать специальные библиотеки, разработанные для обеспечения безопасности. Второй — использовать собственные диалекты C ++ и, возможно, полностью запретить необработанные указатели из кода C ++, включить проверки границ и использовать сборщик мусора. Третий вариант, пожалуй, самый интересный, поскольку предлагает использовать более безопасные языки. Вы можете быть удивлены предложенными языками:
Ява и Котлин
JavaScript
Ржавчина
Быстрый
…
Что ж, из этого набора я никогда не считал Java, Kotlin, JavaScript или Swift особенно безопасными. Однако, учитывая способ управления памятью, они безопаснее, чем C ++. Тем не менее, утечки памяти обычны для всех из них.
Затем идет Rust — язык, в который мы в настоящее время вкладываем так много надежд. Может ли быть, что Rust с концепцией владения является долгосрочным решением? Если так, то это, вероятно, надолго, потому что это будет смелый разработчик Chromium, который посвятил себя языку еще на этой ранней стадии. Пусть другие, Microsoft и Mozilla, поэкспериментируют и увидят, к чему это приведет.
А пока нам просто нужно смириться с неизбежными ошибками безопасности, которые, похоже, влечет за собой ручное управление памятью. Неужто должен быть лучший способ?