PVS-Studio всегда умел обнаруживать большое количество различных дефектов безопасности (потенциальных уязвимостей) в программном коде. Однако исторически мы позиционировали PVS-Studio как инструмент для поиска ошибок. Мы видим тенденцию в разработке программного обеспечения искать уязвимости в коде, хотя это все равно. Нам кажется, что пора провести ребрендинг нашего статического анализатора PVS-Studio. Мы начнем с перечисления общих слабых мест (CWE). В этой статье представлена таблица, в которой показаны совпадения диагностических предупреждений PVS-Studio с классификатором. Таблица будет постепенно обновляться и изменяться, но мы уже можем использовать таблицу для написания статей о дефектах безопасности, обнаруженных в проектах. Мы полагаем, что это привлечет больше внимания специалистов по программной безопасности.
Перечень общих слабых мест (CWE)
Давайте сначала проясним термины. Для этого я процитирую фрагмент FAQ с cwe.mitre.org.
A1. Что такое CWE? Что такое «слабое место в программном обеспечении»?
Common Weakness Enumeration (CWE), предназначенный как для сообщества разработчиков, так и для сообщества специалистов по безопасности, представляет собой официальный список или словарь общих слабых мест программного обеспечения, которые могут возникать в архитектуре, дизайне, коде или реализации программного обеспечения, которые могут привести к использованию уязвимостей безопасности. CWE был создан, чтобы служить общим языком для описания слабых мест в безопасности программного обеспечения; служить стандартной мерой для инструментов безопасности программного обеспечения, нацеленных на эти слабые места; и предоставить общий базовый стандарт для усилий по выявлению, смягчению и предотвращению слабых мест.
Слабые стороны программного обеспечения - это недостатки, сбои, ошибки, уязвимости и другие ошибки в реализации программного обеспечения, коде, дизайне или архитектуре, которые, если их не устранить, могут привести к уязвимости систем и сетей для атак. Примеры слабых мест программного обеспечения включают: переполнение буфера, строки формата и т. Д .; проблемы структуры и действительности; общие специальные манипуляции с элементами; ошибки канала и пути; ошибки обработчика; ошибки пользовательского интерфейса; ошибки обхода пути и эквивалентности; ошибки аутентификации; ошибки управления ресурсами; недостаточная проверка данных; оценка и внедрение кода; и случайность и предсказуемость.
A2. В чем разница между уязвимостью программного обеспечения и слабым местом программного обеспечения?
Слабые стороны программного обеспечения - это ошибки, которые могут привести к уязвимости программного обеспечения. Уязвимости программного обеспечения, например, перечисленные в списке общих уязвимостей и уязвимостей (CVE), представляют собой ошибку в программном обеспечении, которая может быть напрямую использована хакером для получения доступа к системе или сети.
Соответствие предупреждений PVS-Studio и CWE
Мы хотим, чтобы люди начали видеть в PVS-Studio не просто инструмент для поиска ошибок, а как инструмент, помогающий устранять уязвимости в коде. Конечно, не все дефекты безопасности, перечисленные в CWE, являются уязвимостями. Возможность использования той или иной уязвимости для атаки на программу зависит от множества факторов. Поэтому в дальнейшем мы напишем, что PVS-Studio обнаруживает не просто уязвимости, а потенциальные уязвимости - так будет правильнее.
Итак, вот первый вариант таблицы соответствий. Как я уже сказал, в будущем таблица будет обновляться, но этот вариант уже дает общее представление о возможностях анализатора.
Таблица N1. Первый черновик соответствия диагностики CWE и PVS-Studio.
Теперь мы можем писать в наших статьях, посвященных проверкам проектов, и о потенциальных уязвимостях. Поскольку эта тенденция становится все более распространенной среди анализаторов, мы также затронем эту тему в наших статьях.
Демонстрация
Давайте посмотрим, как эту таблицу можно использовать в статьях. Мы проанализируем проект и посмотрим на диагностические предупреждения с точки зрения слабых мест.
Конечно, не каждый проект стоит изучать с точки зрения уязвимостей. Итак, давайте рассмотрим такой серьезный проект, как Apache HTTP Server.
Когда мы это проверяем, мы видим ошибки, ползающие по всему коду. Но ждать! Это не просто ошибки, это слабые места в системе безопасности. Это звучит серьезнее, когда мы говорим о вопросах безопасности, чем о банальных опечатках и ошибках.
Сразу скажу, что в этот раз мы не собираемся анализировать весь проект, потому что перед нами стоит задача показать, как можно использовать таблицу на практике. Вот только три предупреждения.
Пример №1.
#define myConnConfig(c) \ (SSLConnRec *)ap_get_module_config(c->conn_config, &ssl_module)....int ssl_callback_alpn_select(SSL *ssl, const unsigned char **out, unsigned char *outlen, const unsigned char *in, unsigned int inlen, void *arg) { conn_rec *c = (conn_rec*)SSL_get_app_data(ssl); SSLConnRec *sslconn = myConnConfig(c); apr_array_header_t *client_protos; const char *proposed; size_t len; int i;/* If the connection object is not available, * then there's nothing for us to do. */ if (c == NULL) { return SSL_TLSEXT_ERR_OK; } .... }
Анализатор PVS-Studio выдает предупреждение: V595 Указатель c использовался до того, как он был проверен на nullptr. Проверить строки: 2340, 2348. ssl_engine_kernel.c 2340
Что касается дефектов безопасности, это: CWE-476 (разыменование нулевого указателя)
Суть этой ошибки. Выделим две наиболее важные строчки кода:
SSLConnRec *sslconn = myConnConfig(c);
if (c == NULL) {Проверка (c == NULL) показывает, что указатель может иметь значение NULL. Однако он уже разыменован внутри макроса myConnConfig:
#define myConnConfig(c) \
(SSLConnRec *)ap_get_module_config(c->conn_config, &ssl_module)Таким образом, этот код никак не защищен от разыменования нулевого указателя.
Пример N2.
int get_password(struct passwd_ctx *ctx)
{
char buf[MAX_STRING_LEN + 1];
....
memset(buf, '\0', sizeof(buf));
return 0;
err_too_long:
....
}Анализатор PVS-Studio выдает предупреждение: V597 Компилятор может удалить вызов функции memset, которая используется для очистки буфера buf. Для удаления личных данных следует использовать функцию memset_s (). passwd_common.c 165
Что касается дефектов безопасности, это: CWE-14 (Удаление кода компилятором для очистки буферов)
Суть этой ошибки. При компиляции кода в оптимизированном режиме компилятор удалит вызов функции memset, поскольку с точки зрения компилятора этот вызов является избыточным. После того, как созданный в стеке буфер заполняется нулями, он никак не используется. Это означает, что заполнение буфера нулями - пустая трата времени, и вызов функции memset следует удалить. Таким образом, личные данные не будут перезаписаны и останутся в памяти.
Хочу отметить, что это не какое-то абстрактное теоретически возможное поведение компилятора. Компиляторы действительно делают это для ускорения наших программ. Подробности:
- Перезапись памяти - зачем?
- V597. Компилятор может удалить вызов функции «memset, которая используется для очистки буфера Foo ».
Пример N3
static int is_quoted_pair(const char *s) { int res = -1; int c;if (((s + 1) != NULL) && (*s == '\\')) { c = (int) *(s + 1); if (apr_isascii(c)) { res = 1; } } return (res); }
Анализатор PVS-Studio выдает предупреждение: V694 Условие ((s + 1)! = ((Void *) 0)) ложно только при переполнении указателя, что в любом случае является неопределенным поведением. mod_mime.c 531
Что касается дефектов безопасности, это: CWE-571 (выражение всегда истинно)
Суть этой ошибки: условие ((s + 1)! = NULL) всегда истинно. Может быть ложным только в случае переполнения указателя. Это вызывает неопределенное поведение, поэтому говорить об этом случае нет смысла. Мы можем считать, что условие всегда верно; об этом нас предупредил анализатор.
Мы не являемся авторами кода, поэтому точно не знаем, как он должен быть написан, но, скорее всего, таким образом:
if ((*(s + 1) != '\0') && (*s == '\\')) {Вывод
Ура, анализатор PVS-Studio можно использовать для обнаружения потенциальных уязвимостей в коде!
Тем, кто желает исследовать возможности анализатора, предлагаем попробовать демо-версию на проекте. Страница продукта: PVS-Studio.
В случае возникновения технических вопросов или вопросов, касающихся лицензирования продукта, просим написать нам на support [@] viva64.com или воспользоваться формой обратной связи.
