Потенциальная уязвимость
- Терминология
- Различие между потенциальной уязвимостью и уязвимостью
- Пример потенциальной уязвимости
- SAST: поиск уязвимостей и потенциальных уязвимостей
- Дополнительные ссылки
Потенциальная уязвимость (security weakness) — это ошибка в программном коде, которая при определённом стечении обстоятельств может быть использована злоумышленником для влияния на процесс работы в программе. Если способ использования программной ошибки найден, то это уже настоящая уязвимость (vulnerability).
Терминология
Программная ошибка. Ошибка в коде может как явно проявлять себя в виде некорректной работы программы, так и оставаться незаметной. При этом некоторые "спящие" ошибки можно эксплуатировать, и тогда можно говорить, что это уязвимость. Именно обыкновенные программные ошибки, а не высокоуровневые просчёты в системах безопасности чаще всего приводят к появлению уязвимостей.
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.
Потенциальная уязвимость. Ошибка в коде, которую теоретически можно использовать и создать эксплойт. Другие названия: дефект безопасности, security weakness. Существует система классификации ошибок, приводящих к уязвимостям: Common Weakness Enumeration (CWE). Таким образом, если найденная ошибка в коде может быть классифицирована согласно CWE, то перед нами потенциальная уязвимость.
Уязвимость. Ошибка, про которую уже стало известно, что её можно использовать во вредоносных целях. Такие ошибки собираются в базу данных общеизвестных уязвимостей информационной безопасности: Common Vulnerabilities and Exposures (CVE).
Уязвимость нулевого дня (Zero-day). Термин, обозначающий бреши и уязвимости, которые были допущены разработчиками, но при этом ещё не были ими обнаружены. До тех пор, пока уязвимость не будет устранена, она может использоваться для доступа к сетям, удалённому управлению компьютером, манипуляций с данными и т.п. Такое название термина устоялось по причине того, что у разработчиков нет ни дня на исправление дефекта, так как они о нём пока не знают.
SAST (Static Application Security Testing). Статические анализаторы, которые ориентированы на поиск ошибок, связанных с безопасностью. При этом реализуются два разных подхода, про которые будет рассказано ниже.
Различие между потенциальной уязвимостью и уязвимостью
Во многих статьях и документации к статическим анализаторам кода часто смешиваются понятия потенциальная уязвимость и уязвимость. Делается это или по причине недостаточной компетентности авторов публикаций, или для того, чтобы сделать описание проблем более пугающим.
Например, можно встретить текст такого типа:
Статический анализатор нашёл уязвимость, так как здесь может произойти переполнение буфера...
Но это ещё не уязвимость. Высока вероятность, что, хотя эта ошибка действительно приводит к некорректной работе программы, ей никак нельзя воспользоваться. Например, ошибка может приводить лишь к тому, что на экране что-то будет отрисовано не тем цветом.
Только если будет создан эксплойт, который позволяет использовать ошибку с какой-то целью, можно говорить о том, что перед нами уязвимость. До того момента, пока мы точно не знаем, является ошибка безобидной или это явная уязвимость, мы имеем дело с потенциальной уязвимостью.
Наша команда считает неправильным сгущать краски и писать, что анализатор PVS-Studio нашёл сотни уязвимостей в каком-то приложении. Инструмент находит именно потенциальные уязвимости, и вероятность, что их можно хоть как-то использовать, весьма низка. Это следует хотя бы из того, что создание эксплойта требует много сил, времени и профессионализма. Хотя мы постоянно слышим о новых уязвимостях, это всё равно редкие штучные события, в то время как ошибки в приложениях постоянно находятся тысячами.
Примечание. Если вы используете PVS-Studio как плагин для SonarQube, то часть предупреждений будет попадать в раздел "Уязвимости". На самом деле это, конечно не уязвимости, а потенциальные уязвимости. Просто разработчики SonarQube решили назвать серьёзные дефекты сразу уязвимостями.
Мы разобрали, почему не стоит каждую ошибку сразу именовать уязвимостью. Однако это не значит, что наличие таких ошибок в приложении допустимо. Нет смысла думать, исправлять ту или иную потенциальную уязвимость или нет. Любую проблему в коде лучше сразу исправить. Это предотвратит ненулевую вероятность, что кто-то придумает, как можно эксплуатировать ту или иную ошибку, и тем самым откроет новую уязвимость (т.е. появится уязвимость 0-ого дня).
Пример потенциальной уязвимости
Ошибка "недостижимый код" описана в базе CWE как CWE-561, а значит, является потенциальной уязвимостью. Давайте посмотрим, каким образом такая потенциальная уязвимость может оказаться как безобидной с точки зрения безопасности ошибкой, так и серьезной уязвимостью.
Вначале рассмотрим фрагмент кода из игры Vangers: One For The Road (подробности).
void uvsVanger::break_harvest(void){
....
pg = Pworld -> escT[0] -> Pbunch
-> cycleTable[Pworld -> escT[0] -> Pbunch -> currentStage].Pgame;
if (!pg) {
return;
ErrH.Abort("uvsVanger::break_harvest : don't know where to go ");
}
....
}
Предупреждение PVS-Studio: V779 CWE-561 Unreachable code detected. It is possible that an error is present.
В случае некоего ошибочного состояния программы функция break_harvest должна записать сообщение в лог и завершить свою работу. Случайно операция записи в лог расположена в коде уже после оператора return. То, что в лог не попадёт отладочное предупреждение, неприятно и однозначно является ошибкой, которую следует исправить. Однако никак нельзя сказать, что эта ошибка является уязвимостью.
Теперь рассмотрим ошибку, которая стала причиной появления уязвимости в операционной системе iOS.
Описание уязвимости CVE-2014-1266: The SSLVerifySignedServerKeyExchange function in libsecurity_ssl/lib/sslKeyExchange.c in the Secure Transport feature in the Data Security component in Apple iOS 6.x before 6.1.6 and 7.x before 7.0.6, Apple TV 6.x before 6.0.2, and Apple OS X 10.9.x before 10.9.2 does not check the signature in a TLS Server Key Exchange message, which allows man-in-the-middle attackers to spoof SSL servers by using an arbitrary private key for the signing step or omitting the signing step.
static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx,
bool isRsa,
SSLBuffer signedParams,
uint8_t *signature,
UInt16 signatureLen)
{
OSStatus err;
....
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
goto fail;
....
fail:
SSLFreeBuffer(&signedHashes);
SSLFreeBuffer(&hashCtx);
return err;
}
Обратите внимание, что если проверить этот фрагмент кода с помощью PVS-Studio, то он выдаст то же самое предупреждение: V779 CWE-561 Unreachable code detected. It is possible that an error is present.
Из-за двойного goto так же, как и в предыдущем примере, часть кода является недостижимой. Даже если переменная err равна нулю, происходит переход к метке fail. Это приводит к тому, что проверка подписи не производится. Функция возвращает 0, который обозначает, что с подписью всё хорошо. Далее программа получает ключ с сервера, даже если с подписью есть проблемы. Этот ключ нужен для шифрования данных при передаче.
Как видите, здесь точно такая же потенциальная уязвимость на самом деле уже оказалась настоящей серьезной уязвимостью.
Вывод. В случае игры было понятно, что ошибка некритична с точки зрения безопасности, но так будет не всегда. Потому не гадайте, есть опасность или нет. Даже если ошибка не может стать уязвимостью, её исправление пойдёт на пользу приложению.
SAST: поиск уязвимостей и потенциальных уязвимостей
Принципы работы SAST-инструментов разделяются на два направления.
Первое направление — поиск известных уязвимостей. Анализаторы первого типа работают по принципу антивируса. Им известно, как выглядят фрагменты кода, содержащие известные уязвимости (CVE). Эти фрагменты они и ищут в коде проверяемых проектов. На практике всё сложней, но общая идея именно такая.
Анализаторы этого типа помогут выявить, например, что в вашем коде используется старая версия библиотеки, содержащая известную и давно найденную уязвимость. Инструменты, осуществляющие поиск по базе, практически не дают ложных срабатываний, но они бессильны, когда речь заходит о поиске ошибок в новом коде (уязвимостей нулевого дня).
Второе направление: поиск уязвимостей нулевого дня. Приложение может содержать ошибку, которая некоторое время будет оставаться незамеченной. Если хакер обнаружит такую ошибку и придумает, как её можно эксплуатировать, то она превратится в новую уязвимость.
Анализаторы второго типа помогают обнаруживать ошибки, которые потенциально могут стать причиной уязвимости. Большое количество таких паттернов ошибок собраны в CWE, и многие разработчики анализаторов ориентируются на эту базу.
Анализатор PVS-Studio является SAST решением именно этого типа и умеет классифицировать свои предупреждения согласно CWE. Другими словами, можно сказать, что PVS-Studio ориентирован на предотвращение уязвимостей нулевого дня.
Дополнительные ссылки
- Статический анализатор кода PVS-Studio как защита от уязвимостей нулевого дня
- Как PVS-Studio может помочь в поиске уязвимостей?
- Технологии, используемые в анализаторе кода PVS-Studio для поиска ошибок и потенциальных уязвимостей
- Анализатор кода PVS-Studio как инструмент для поиска дефектов безопасности и защищённости приложений. Отчёт Forrester Research о SAST, Q3 2020
- Какая разница между DevOps и DevSecOps?
- OWASP, уязвимости и taint анализ в PVS-Studio C#
0