19 Июл 2021

Уязвимость нулевого дня

19 Июл 2021

Уязвимость нулевого дня / 0-day / zero day — этот термин обозначает ещё не устранённые уязвимости.

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

Название термина отражает, что у разработчиков нет ни дня на исправление дефекта, так как они о нём пока не знают.

Большинство уязвимостей связано не с какими-то просчётами в системах безопасности или высокоуровневыми ошибками в логике, а с обыкновенными ошибками в коде приложений.

The National Institute of Standards and Technology (NIST) reports that 64% of software vulnerabilities stem from programming errors and not a lack of security features.

Существует бесконечное количество способов допустить ошибку в коде, которая станет причиной уязвимости. К счастью, во всём этом есть определённые закономерности. Большинство ошибок можно классифицировать и выявить определённые ошибочные паттерны.

Эти паттерны хорошо изучены, и существуют их классификации. Наиболее значимые среди них:

OWASP Application Security Verification Standard (OWASP ASVS);
Common Weakness Enumeration (CWE);
SEI CERT Coding Standards.

Для выявления уязвимостей нулевого дня используются статические анализаторы кода, такие как PVS-Studio. Как правило, такие анализаторы поддерживают один или несколько стандартов, перечисленных выше.

Примечание. Статические анализаторы — это достаточно общее понятие. Чтобы подчеркнуть, что анализатор ориентирован предотвращать уязвимости, его называют средством статического тестирования защищённости приложений (SAST). См. также PVS-Studio SAST.

Неправильно говорить, что SAST-решения непосредственно выявляют уязвимость нулевого дня. Анализаторы выявляют потенциальные уязвимости. Другими словами, они указывают на странные/аномальные фрагменты кода, которые могут являться ошибками и дефектами безопасности.

Только небольшая часть выявленных ошибок на самом деле представляет угрозу. Возьмём, например, ошибку "переполнение буфера". Все стандарты классифицируют её как крайне опасную с точки зрения безопасности. Но только малую часть таких ошибок можно эксплуатировать. Большинство из них приводят к неприятным, но не фатальным последствиям. Например, переполнение буфера может приводить к порче изображения.

Хотя только часть ошибок может стать причинами уязвимостей, программистам нет смысла пытаться их как-то разделять. Рационально исправлять все участки кода, на которые выданы предупреждения (кроме случаев явно ложных срабатываний анализатора). Даже если исправляется не потенциальная уязвимость, а просто ошибка, это всё равно полезно. Тем более что часто очень непросто понять, представляет ли та или иная ошибка опасность с точки зрения безопасности. Лучше не рисковать, а исправить её.

Дополнительные ссылки: