Я нашёл 213 уязвимостей безопасности в кодовой базе при помощи GPT-3

А обычные статические анализаторы такое не ловят разве? PVS-Studio, можете сравнить со своим решением? )

Есть ещё SonarLint, есть PVS-Studio

    fp = fopen(filename,"r"); 

    if(fp == NULL)
    {
        printf("\nCan't open file or file doesn't exist.");
        exit(0);
    }

1. Unchecked return value: The return value of the fopen() function is not checked, which could lead to a null pointer dereference.

хм, есть же проверка

хмм .. интересно, а вот по коду страниц на фронте - он сможет уязвимости в беке найти или нет?

GPT-3 прав насчёт первых двух уязвимостей, однако третья уязвимость ложноположительная — obj.username экранирован, хотя GPT-3 утверждает, что это не так.

Он заглянул уровнем ниже, в escape, проанализировал код этой функции, и пришёл к выводу что она не экранирует username 😁

Пример с Java сомнительный. `ObjectInputStream` - уязвимость по своей природе, Insecure File Permissions - уязвимость с натягом, сильно зависит от контекста. С таким же успехом отсутствие проверки на разрешенный путь filename тоже можно было бы назвать уязвимостью. Сам код кривой, обработка ошибок плохая, потенциально это отказ в обслуживании. Метод десереализации почему-то возвращает new Object() в случае ошибки - вряд ли это ожидаемое поведение. Думаю любой линтер нашел бы это.

Я не разделяю энтузиазм и восторг автора статьи. Наши собственные недавние эксперименты с ChatGPT показали куда более скромные и неоднозначные результаты. Публикация на эту тему: Хорошо ли ChatGPT ищет ошибки в коде?

Мне кажется, ChatGPT очаровал автора и он приписывает ему правильные ответы, даже там где их нет. Этим, возможно, и объясняется только одно замеченное ложное срабатывание. Если не хотеть их замечать, то их и не будет :)

Почему я столь скептичен? Автор скорее всего приводит самые красивые и сильные примеры работы ChatGPT. Согласитесь, вряд ли он отбирал слабые примеры :). Так вот, даже в этих отобранных примерах удачной работы имеются незамеченные автором ложные срабатывания.

Возьмём первый пример.

int main(int argc, char **argv) {
    printf(argv[1]);

В целом я согласен с вторым пунктом: Format string vulnerability. Хотя и тут можно придраться к формулировке. Собственно проверять необязательно, нужно просто по-другому использовать printf. Объяснение ошибки явно проигрывает документации классических статических анализаторов: V618. Ну да ладно, первое сообщение более мне интересно.

"Unvalidated user input: The program does not check the length of the user input, which could lead to a buffer overflow attack.". На мой взгляд это ложное срабатывание. Нет проверки количества аргументов (переменной argc). Здесь ошибка: возможен выход за границы массива argv. А GPT-3 начинает философствовать про какие-то переполнения буфера. Можно, конечно, сказать, что это одно и то же... Но это тогда можно просто сказать "у вас тут ошибка". Если это так - повезло. А если нет, то извините :). Когда программисты говорят про переполнение буфера? Когда имеется в виду именно работа с нуль-терминированной строкой, неправильное использование strcat, memcpy и т.п.

Ладно, возможно, это было неубедительное ложное срабатывание. Хорошо, вот код из 3-его примера:

fp = fopen(filename,"r"); 
if(fp == NULL)
{
  printf("\nCan't open file or file doesn't exist.");
  exit(0);
}

Не понимаю, как можно сказать, что это правильное предупреждение: Unchecked return value: The return value of the fopen() function is not checked, which could lead to a null pointer dereference. GPT-3 явно облажался, а автор не захотел это заметить.

В этом-же третьем примере:

char OOBR_stack = buff3[size3+100];
char OOBR_heap = buff4[100];

Uninitialized memory access: The OOBR_stack and OOBR_heap variables are accessed without being initialized, which could lead to undefined behavior.

Полная фигня. Вот же инициализация. Эти переменные никак нельзя назвать неинициализированными. Другое дело, что при их инициализации происходит выход за границы массива, но это совсем другая ошибка, про которую GPT-3 ничего не сказал. Ещё GPT-3 неправ, говоря про доступ к неинициализированным переменным OOBR_stack и  OOBR_heap. Они вообще нигде не используются.

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

P.S. Слишком пафосно называть всё это уязвимостями. Это просто ошибки. Возможно, некоторые из них являются потенциальными уязвимостями, но не более того. Вот когда найденный дефект можно использовать в своих целях, то тогда да - это уязвимость. Иначе это просто баг, которых тысячи в любых приложениях :). Я то точно знаю, что таких багов полно везде. С помощью PVS-Studio мы уже обнаружили более 15000 багов в открытых проектах. Но мы скромнее и не называем это УЯЗВИМОСТЯМИ!! ААА! Страшно, бойтесь! :)

Как можно доверять какую-то проверку правильности чего угодно программе, которая на вопрос "сколько букв в слове шесть" отвесчает 'В слове "шесть" 6 букв.' - для меня выше понимания.

В Примере 3 глаз сразу зацепился за:

        char* buff1=(char*)malloc(size1);

        memcpy(buff1,img.data,sizeof(img.data));
        free(buff1);

явный баг - буфер выделили, туда чего-то записали и тут же его прихлопнули. Интересно, думаю, глянуть поиском, что там происходить с этим buff1 - и, конечно, тут же нашлась чуть ниже строка :

                buff1[0]='a';

Короче - баг багованый. А что нам по этому поводу скажет GPT-3? GPT-3 молчит как партизан!

Интересно выходит, при обучении GPT-3 просматривает за секунду больше кода, чем я видел за всю жизнь, а явных багов не видит! То ли его как-то не так учат, то ли он сам по себе тупой... не знаю. Нейронов не хватает или организованы они как-то не правильно?

Интересно было бы посмотреть на результаты GPT-4

GPT-3 прав насчёт первых двух уязвимостей, однако третья уязвимость ложноположительная — obj.username экранирован, хотя GPT-3 утверждает, что это не так.

Вызов сторонней библиотеки, которая должна выполнить функцию єкранирования не является гарантией того, что єта сторонняя библиотека всегда делает єто правильно.

Точнее можно сказать только увидев код библиотеки.

Случаи, когда подобный сторонний код работает с ошибками - не редкость.