I в LLM означает Intelligence

Я уже давно ничего не писал об ИИ или том, как мы (не) используем его для разработки в нашем проекте curl. Больше откладывать нельзя. Хочу продемонстрировать вам наиболее значительный эффект, который ИИ может оказать на curl сегодня, подкрепив его примерами.

▍ Охота на баги

Наша программа охоты на баги ^[1] подразумевает выплату реальных вознаграждений хакерам за то, что они сообщают об уязвимостях безопасности. Шанс заработка привлекает определённое число «искателей удачи». Это люди, которые, по сути, просто грепают паттерны в исходном коде или в лучшем случае выполняют какое-то несложное сканирование безопасности. После этого, не проводя никакого дальнейшего анализа, они сообщают о своих открытиях в надежде, что смогут получить денежную награду.

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

На данный момент по результатам охоты мы выплатили более $70 000. Всего мы получили 415 отчётов об уязвимостях. Из них в конечном итоге подтверждено было 64. При этом 77 оказались информативными, то есть обычно указывали на баги или аналогичные проблемы. Оставшиеся 66% оказались не связаны ни с проблемами безопасности, ни с типичными багами.

▍ Приукрашенный мусор хуже всего

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

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

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

▍ Отчёты, сгенерированные ИИ

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

Сегодня пользователи, похоже, предпочитают задействовать доступные LLM, скармливая им фрагменты кода curl и затем отправляя вывод в качестве отчёта об уязвимости. Усложняет обнаружение подобных фейков то, что пользователи также копируют и вставляют в отчёт какие-то свои формулировки. Это, конечно, разбавляет вывод ИИ, но мусор всё равно остаётся мусором.

▍ Выявление мусора, сгенерированного ИИ

Люди, участвующие в охоте на баги, зачастую не говорят бегло по-английски, и порой сложно с ходу понять, что они имеют ввиду. В таких случаях может потребоваться несколько уточнений, чтобы всё достаточно прояснить. Это, естественно, абсолютно нормально и приемлемо. Язык и культурные различия выступают реальными преградами.

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

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

▍ Пример A: отчёт о раскрытии изменений кода

Осенью 2023 года я предупредил сообщество о скором обнародовании уязвимости CVE-2023-38545 ^[2], серьёзность которой мы оценивали высоко.

За день до её публикации, один из пользователей Hackerone прислал отчёт ^[3]: уязвимость и соответствующие изменения кода Curl CVE-2023-38545 обнародованы в интернете.

Звучало довольно угрожающе, и в случае истинности оказалось бы ощутимой проблемой.
Тем не менее в отчёте присутствовали типичные галлюцинации ИИ: в нём смешивались и сопоставлялись факты и подробности из старых отчётов о безопасности, создавая что-то новое, никак не связанное с реальностью. Изменения кода на тот момент не были обнародованы в интернете. Фактически раскрытые изменения касались предыдущих, более старых проблем. Как, собственно, и предполагалось.

Конкретно в этом отчёте его составитель услужливо сообщил нам, что использовал для поиска уязвимости Bard. Bard — это генеративный ИИ от Google. В итоге оказалось проще понять, что перед нами ересь, закрыть отчёт и двигаться дальше. По журналу отчётов видно, что выяснение этого заняло у нас немного времени.

▍ Пример B: уязвимость переполнения буфера

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

Утром 28 декабря 2023 года пользователь отправил на Hackerone такой отчёт ^[4]: уязвимость переполнения буфера при обработке WebSocket. В моей временно́й зоне тогда было утро.

Опять же, одно только название уже звучит серьёзно. Поскольку наш код WebSocket всё ещё экспериментальный, и в программу охоты на баги не включён, я отнёсся к отчёту расслабленно. Его прислал незнакомый мне пользователь, но «репутацию» на Hackerone он имел неплохую — это был не первый его отчёт о безопасности.

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

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

Спустя полтора часа я просмотрел код, не нашёл никаких проблем, ещё раз перечитал его, потом ещё и ещё… Где, чёрт возьми, здесь переполнение буфера, о котором говорит отправитель? Тогда я разместил под присланным сообщением первый комментарий с просьбой прояснить, где конкретно происходит указанное переполнение.

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

Не знаю наверняка, были ли ответы пользователя сгенерированы конкретно LLM, но есть несколько признаков того.

▍ Бан таких пользователей

На Hackerone нет явного механизма «банить составителя отчёта, лишая его возможности дальнейшего взаимодействия с нашим проектом». Если бы такой механизм существовал, я бы его использовал. Исследователи теряют «репутацию», когда мы закрываем присланный ими отчёт как фиктивный, но это очень малая кара, притом что происходит она лишь раз в каждом проекте.

Я обратился к разработчикам Hackerone с просьбой расширить функциональность.

Обновление: такая функция существует, просто я искал её не там…

▍ Взгляд в будущее

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

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

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

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

Обсуждение темы ^[4] на Hacker news.