GPT-3 нашёл 213 Security Vulnerabilities... Или не нашёл
Этот текст является развёрнутым комментарием к статье "Я нашёл 213 уязвимостей безопасности в кодовой базе при помощи GPT-3".


Чтобы было понятно о чём идёт речь, прошу в начале взглянуть на статью Chris Koch "Я нашёл 213 уязвимостей безопасности в кодовой базе при помощи GPT-3" (оригинал). Я написал к ней большой комментарий. Потом захотелось написать ещё один. Поэтому я решил, что лучше оформить все свои мысли в виде этой отдельной публикации.


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


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


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


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


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

В целом я согласен со вторым сообщением:


Format string vulnerability: The program does not check the format of the user input, which could lead to a format string attack.

Хотя тут можно придраться к формулировке. Необязательно именно проверять входные данные. Как вариант, можно просто по-другому использовать 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 и т.д.


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


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 прав. Затем появилась приписка, что это ложное срабатывание. Спасибо внимательным читателям, которые указали на неточность. В общем, стоит приглядеться, и вся магия полезных сообщений 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. Они вообще нигде не используются.


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


Кстати, в этом же примере есть как минимум ещё две ошибки, про которые GPT-3 молчит.


free(buff1);          // <=
if (size1/2==0){
  free(buff1);        // <=
}
else{
  if(size1 == 123456){
    buff1[0]='a';     // <=
  }
}

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


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


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


  1. Использование машинного обучения в статическом анализе исходного кода программ.
  2. Технологии статического анализа кода PVS-Studio.

Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Andrey Karpov. GPT-3 detected 213 Security Vulnerabilities… Or it did not.

Комментарии (27)


  1. Travisw
    11.04.2023 14:33

    я удивляюсь тем людям которые написали 3-й кусок кода - так студенты только пишут


    1. domix32
      11.04.2023 14:33
      +1

      Ещё есть олимпиадники.


  1. Proydemte
    11.04.2023 14:33

    По идее надо тестировать GPT4 или github copilot X. Смысла писать про GPT3 уже мало, надо сравнивать последнии версии.


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


    Но можно попробовать связаться с производителями и предложить реализовать плагин, по подобию Wolfram. Чтобы когда copilot работает, он мог прогнать код через ваш анализатор.


    Хотим мы или нет, но это уже реальность и множество разработчиков будет использовать эти системы. Если не подстроиться под новые реальности, можно оказаться на обочине, даже если их система существенно уступает вашей.


    1. thomasf88
      11.04.2023 14:33
      -5

      Все верно. Программисты по сути уже не нужны. Пару лет и все.

      Причем чем больше получает денег программист - тем в большей он зоне риска. Лафа закончилась.

      Я сам программист, ухожу в реал постепенно.


      1. Proydemte
        11.04.2023 14:33
        +3

        ухожу в реал постепенно.
        Куда и как в реал? Если не секрет конечно, для понимания возможных опций.


      1. AllexIn
        11.04.2023 14:33
        +8

        Как раз для высоко квалифицированных спецов я угрозы не вижу. Потому что пока это всё про "написать простой код". Написать много простого кода. Но архитектуру оно строит с трудом. Уникальные приложения вообще не может толком писать. Даже по не популярным api не может подсказать.


    1. Xadok
      11.04.2023 14:33
      +2

      Чтобы когда copilot работает, он мог прогнать код через ваш анализатор.

      Условный cross tu анализ это очень непросто, нельзя просто взять и скормить кусок кода. Это и в текущих реалиях очень долго.

      То есть одна система пока никак не может заменить другую


      1. Proydemte
        11.04.2023 14:33
        -3

        Есть данные о статистически сколько багов самого высокого уровня приходится на cross tu и сколько нет?


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


        1. Xadok
          11.04.2023 14:33

          Нет конечно, но это сложно детектируемые и воспроизводимые IFNDR например


        1. Andrey2008 Автор
          11.04.2023 14:33
          +3

          Примечание на всякий случай. PVS-Studio работает как standalone-приложение и не нуждается в подключение к сети.


  1. Jocker24u
    11.04.2023 14:33
    +1

    Это всё бла бла бла, во-первых база gpt-3 до 19 года во вторых алгоритм работы завязан на словарных ключах а не на некой "логике" это означает что решения задачи основывается на предыдущих примерах похожих задач или других диалогов. Насчет того есть ли там ошибки или их там нет сам по себе абсурден, если машина говорит что они там есть а человек говорит что их там нет то машина всегда будет права, другой вопрос какой конкретно человек "не прав" скорей всего что все "человеки" и те кто писали алгоритм и те кто спрашивают, но так как на сайте openAI" есть такие крутые строчки "ChatGPT Mar 23 Version. ChatGPT may produce inaccurate information about people, places, or facts" то ответ становится очевиден.


    1. domix32
      11.04.2023 14:33

      ChatGPT may produce inaccurate information about people

      Так в этом и соль, только автор оригинальной статьи преподнёс в виде "нашёл уязвимости" без нахождения уязвимости.


  1. Refridgerator
    11.04.2023 14:33
    +4

    Я не разделяю энтузиазм и восторг автора статьи

    Автор вероятно хочет верить в чудо, как и многие другие. Я не могу знать, какие деньги вкладываются в продвижение ГПТ, но вряд ли Стивен Вольфрам работал за бесплатно, чтобы ГПТ мог интегралы через его Вольфрам Альфу считать. На то, что это именно хайп, указывает исчезающе малое количество статей даже не с критикой, а с просто с беспристрастным анализом. Ну вот допустим, утверждают создатели, что ГПТ может писать код. Окей, давайте поставим задачу с вариантами ответа на разных языках, вот прям по алфавиту - алгол, бейсик, си, си++, D ... и сравним, а заодно проверим наличие готовых решений на стак оверфлоу или в гитхабе. Другой момент - раз авторы смогли подключить Вольфрам Альфу - они точно так же могли подключить и статический анализатор, просто забыли об этом сказать. Пусть не ищет ошибки, пусть переводит алгоритмы с одного языка на другой без ошибок - это даст намного более ясное понимание, насколько этот ИИ действительно интеллект.


    1. AllexIn
      11.04.2023 14:33

      И я бы тоже так считал...
      Если бы наш тех лид в рамках внутреннего обучения в компании не показал, как он использует ChatGPT чтобы писать огромные куски кода и тестов этого кода.
      Может там где-то и хайп. Но ChatGPT работает. Хотя пользоваться уметь надо(я вот не могу код с его помощью писать).


      1. KanuTaH
        11.04.2023 14:33

        У меня был негативный опыт с чатгпт, когда человек "написал" с его помощью код для вспомогательного скрипта на Питоне по обработке yml-файлов, генерируемых Clang-Tidy (конкретная задача была в том, чтобы объединять последовательные suggestions в одной и той же строке в один большой suggestion) и недолго думая взял и запихнул в production. Написано было совершенно ужасно - например, код считал suggestions "последовательными" даже если они относились к разным файлам, ибо никакой проверки на это не было вовсе. Чатгпт - это пока что в лучшем случае джун, которого нужно непрерывно контролировать, а ещё большой вопрос, что эффективнее - непрерывно контролировать и допинывать такого вот "джуна" (который к тому же не любит говорить "не знаю") или самому написать.


        1. AllexIn
          11.04.2023 14:33

          Ну я про то и говорю: я лично видел как ЧатГПТ в умелых руках выдает много приемлемого кода.


          1. KanuTaH
            11.04.2023 14:33
            +2

            Проблема была в том что код был неприемлемый даже на относительно несложной задаче :) Не знаю, может быть, его бы удалось рано или поздно превратить в приемлемый после ряда итераций по допиныванию чатгпт, но лично мне проще написать самому. Когда ты пишешь - ты "в потоке", а когда ты по сути проверяешь чужой код - это не то, это ИМХО тяжелее.

            P.S. Даже джун, которого нужно допинывать, все-таки ИМХО лучше, чем чатгпт - он при должных стараниях рано или поздно вырастет до синьора помидора, а вот насчет чатгпт я как-то не уверен :)


      1. Refridgerator
        11.04.2023 14:33
        +2

        Я прошу прощения, а пруфы-то будут? Ну просто на моей работе достаточно тех-лидов, которые на словах Львы Толстые и Д'Артаньяны, а по факту даже хэлловорд не в состоянии написать самостоятельно. Где конкретный код, которые решает конкретную задачу, решение которой не знает ни гугл, ни среднестатистический программист?


        1. AllexIn
          11.04.2023 14:33

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


  1. slamon
    11.04.2023 14:33
    +1

    Я не разделяю энтузиазм и восторг автора статьи.

    Ну ещё бы :))

    Было б странно с вашей стороны разделять энтузиазм и восторг на фоне появления конкурента, который прибьет ваш собственный продукт


    1. rg_software
      11.04.2023 14:33
      +3

      Ну а почему он должен прибить? Вот есть сегодня, в 2023 году, продукт А и продукт Б. Совершенно наплевать, как они устроены внутри, я юзер. В чём преимущество конкурента в данной конкретной задаче поиска ошибок в коде?


      1. slamon
        11.04.2023 14:33
        -1

        В стоимости продукта


        1. Andrey2008 Автор
          11.04.2023 14:33
          +2

          Не аргумент. Бесплатные анализаторы кода не мешают продавать лицензии PVS-Studio.


        1. rg_software
          11.04.2023 14:33
          +2

          Стоимость продукта есть функция спроса и предложения, то есть она может (и будет) меняться -- как у ChatGPT, так и у других систем. Не исключено, что популярность ChatGPT сыграет конкурентам только на руку, т.к. популяризует саму идею "а давайте спросим у софтины, насколько код хорош".


    1. Andrey2008 Автор
      11.04.2023 14:33
      +7

      Что что-то прибьёт PVS-Studio я уже читаю более десяти лет :). То Cppcheck, то Clang... То свежий Visual Studio 2010 (пример: "Народ против PVS-Studio: дубль первый"). Не страшно. Однако, считаю полезным знакомить читателей в комментариях (пример) или в таких вот статьях, с реальностью.


      1. AllexIn
        11.04.2023 14:33

        Что-то обязательно прибьет. Вопрос только в том, когда.


  1. WASD1
    11.04.2023 14:33

    Когда программисты говорят про переполнение буфера? Когда имеется в виду
    работа с нуль-терминированной строкой, неправильное использование
    функций strcat, memcpy и т.д.

    А я всегда думал, что это при выходе за границы буфера на запись (т.е. по сути риск испортить данные за пределами буфера).