Я уже давно ничего не писал об ИИ или том, как мы (не) используем его для разработки в нашем проекте curl. Больше откладывать нельзя. Хочу продемонстрировать вам наиболее значительный эффект, который ИИ может оказать на curl сегодня, подкрепив его примерами.
▍ Охота на баги
Наша программа охоты на баги подразумевает выплату реальных вознаграждений хакерам за то, что они сообщают об уязвимостях безопасности. Шанс заработка привлекает определённое число «искателей удачи». Это люди, которые, по сути, просто грепают паттерны в исходном коде или в лучшем случае выполняют какое-то несложное сканирование безопасности. После этого, не проводя никакого дальнейшего анализа, они сообщают о своих открытиях в надежде, что смогут получить денежную награду.
Мы уже несколько лет проводим такие мероприятия, и количество фиктивных отчётов никогда не являлось серьёзной проблемой. Кроме того, такие отчёты обычно легко и быстро выявлялись. Они редко создавали какие-то серьёзные проблемы и не занимали много времени. В чём-то можно сравнить это с большинством тупых спам-рассылок.
На данный момент по результатам охоты мы выплатили более $70 000. Всего мы получили 415 отчётов об уязвимостях. Из них в конечном итоге подтверждено было 64. При этом 77 оказались информативными, то есть обычно указывали на баги или аналогичные проблемы. Оставшиеся 66% оказались не связаны ни с проблемами безопасности, ни с типичными багами.
▍ Приукрашенный мусор хуже всего
Когда присылаемые отчёты приукрашают, чтобы они выглядели убедительнее, нам требуется больше времени на изучение такого отчёта и его итоговое отклонение. Каждый отчёт безопасности должен предполагать какое-то определённое количество времени на свой анализ человеком.
Чем больше приукрашен мусор, тем больше времени и энергии приходится на этот отчёт тратить, прежде чем отклонить. Мусорный отчёт никак не помогает проекту. Он лишь занимает время разработчика, которое тот мог вложить во что-то более продуктивное. Отчасти дело в том, что работа с безопасностью считается одной из важнейших областей, склонной перекрывать практически всё остальное.
Отчёт о безопасности может отвлечь разработчика от исправления реально раздражающего бага, поскольку проблемы с безопасностью всегда важнее других багов. Если отчёт оказался фиктивным, то в итоге мы и безопасность не улучшили, и потратили ценное время, которое могли уделить исправлению какой-то ошибки или разработке новой возможности. И я уже не говорю о том, что возня с мусором просто высасывает твою энергию.
▍ Отчёты, сгенерированные ИИ
Я понимаю, что ИИ способен на многое. Как и любой инструмент общего назначения, его также можно использовать во зло. Я уверен, что ИИ можно продуктивно обучать и в конечном итоге использовать даже для поиска и извещения о проблемах безопасности, но пока нам ещё нужно поискать хорошие примеры такого его применения.
Сегодня пользователи, похоже, предпочитают задействовать доступные LLM, скармливая им фрагменты кода curl и затем отправляя вывод в качестве отчёта об уязвимости. Усложняет обнаружение подобных фейков то, что пользователи также копируют и вставляют в отчёт какие-то свои формулировки. Это, конечно, разбавляет вывод ИИ, но мусор всё равно остаётся мусором.
▍ Выявление мусора, сгенерированного ИИ
Люди, участвующие в охоте на баги, зачастую не говорят бегло по-английски, и порой сложно с ходу понять, что они имеют ввиду. В таких случаях может потребоваться несколько уточнений, чтобы всё достаточно прояснить. Это, естественно, абсолютно нормально и приемлемо. Язык и культурные различия выступают реальными преградами.
Иногда охотники используют ИИ или другие инструменты, которые помогают им строить фразы или переводят их речь. И я не вижу в этом ничего плохого в качестве помощи, упрощающей коммуникацию на иностранном языке. Даже те составители отчётов, которые не владеют английским, вполне могут найти баги и сообщить о проблемах безопасности.
Итак: одно только существование нескольких разоблачающих признаков генерации текста при помощи ИИ или аналогичного инструмента ещё не является ярким доказательством. Он всё равно может содержать элементы правды и представлять действительную проблему. Отчасти именно поэтому грамотно сформированный мусор сложнее анализировать, и это занимает больше времени.
▍ Пример A: отчёт о раскрытии изменений кода
Осенью 2023 года я предупредил сообщество о скором обнародовании уязвимости CVE-2023-38545, серьёзность которой мы оценивали высоко.
За день до её публикации, один из пользователей Hackerone прислал отчёт: уязвимость и соответствующие изменения кода Curl CVE-2023-38545 обнародованы в интернете.
Звучало довольно угрожающе, и в случае истинности оказалось бы ощутимой проблемой.
Тем не менее в отчёте присутствовали типичные галлюцинации ИИ: в нём смешивались и сопоставлялись факты и подробности из старых отчётов о безопасности, создавая что-то новое, никак не связанное с реальностью. Изменения кода на тот момент не были обнародованы в интернете. Фактически раскрытые изменения касались предыдущих, более старых проблем. Как, собственно, и предполагалось.
Конкретно в этом отчёте его составитель услужливо сообщил нам, что использовал для поиска уязвимости Bard. Bard — это генеративный ИИ от Google. В итоге оказалось проще понять, что перед нами ересь, закрыть отчёт и двигаться дальше. По журналу отчётов видно, что выяснение этого заняло у нас немного времени.
▍ Пример B: уязвимость переполнения буфера
Это оказалась более сложная и менее очевидная подделка, но и её выдали глюки нейросети. Здесь мы видим пример того, как проблема становится серьёзнее, когда инструмент используется более грамотно и лучше интегрирован в коммуникацию.
Утром 28 декабря 2023 года пользователь отправил на Hackerone такой отчёт: уязвимость переполнения буфера при обработке WebSocket. В моей временно́й зоне тогда было утро.
Опять же, одно только название уже звучит серьёзно. Поскольку наш код WebSocket всё ещё экспериментальный, и в программу охоты на баги не включён, я отнёсся к отчёту расслабленно. Его прислал незнакомый мне пользователь, но «репутацию» на Hackerone он имел неплохую — это был не первый его отчёт о безопасности.
Составлен документ был достаточно опрятно. Он включал детали и был написан на грамотном английском. Он также содержал предлагаемое исправление, и на первый взгляд ошибочным или кривым не выглядел. Казалось, будто составитель обнаружил что-то плохое и при этом понимал это достаточно хорошо, чтобы попутно предложить решение. Если сравнивать с отчётами в целом, то выглядел он лучше, чем среднестатистическое первое сообщение.
В нём можно видеть мой первый шаблонный ответ, информирующий пользователя о том, что я получил отчёт и во всём разберусь. Когда он был размещён, я ещё не знал, насколько сложной или простой окажется проблема.
Спустя полтора часа я просмотрел код, не нашёл никаких проблем, ещё раз перечитал его, потом ещё и ещё… Где, чёрт возьми, здесь переполнение буфера, о котором говорит отправитель? Тогда я разместил под присланным сообщением первый комментарий с просьбой прояснить, где конкретно происходит указанное переполнение.
После получения в ответах нескольких повторяющихся вопросов и множества явно кривых формулировок я понял, что проблема вымышлена, и в полдень того же дня закрыл отчёт как фиктивный. Не было никакого переполнения буфера.
Не знаю наверняка, были ли ответы пользователя сгенерированы конкретно LLM, но есть несколько признаков того.
▍ Бан таких пользователей
На Hackerone нет явного механизма «банить составителя отчёта, лишая его возможности дальнейшего взаимодействия с нашим проектом». Если бы такой механизм существовал, я бы его использовал. Исследователи теряют «репутацию», когда мы закрываем присланный ими отчёт как фиктивный, но это очень малая кара, притом что происходит она лишь раз в каждом проекте.
Я обратился к разработчикам Hackerone с просьбой расширить функциональность.
Обновление: такая функция существует, просто я искал её не там…
▍ Взгляд в будущее
Думаю, что по мере того, как подобные отчёты будут становиться более распространёнными, мы можем научиться лучше распознавать признаки их генерации с помощью ИИ, и на основе этого исключать фиктивные. Это, естественно, окажется некстати, если ИИ будет использоваться для подобающих целей, таких как перевод или просто помощь с формулировкой текста.
Уверен, что в будущем появятся инструменты на базе ИИ, которые будут реально справляться с этой задачей лучше, хотя бы иногда. Так что не могу утверждать, что применение ИИ для поиска уязвимостей безопасности всегда является плохой идеей.
Но при этом я также думаю, что если просто добавить в этот процесс даже минимальную проверку человеком, эти инструменты окажутся намного эффективнее. Но случится это наверняка лишь в далёком будущем.
У меня нет сомнений, что даже в будущем люди будут искать лёгкие пути. Уверен, они не перестанут искать возможность урвать быстрых денег. Платит же за это в итоге, как и в случае с почтовыми спамерами, конечный получатель. Простота использования и широкий доступ к мощным языковым моделям слишком соблазнительны, чтобы этими возможностями пренебречь. Так что на наши почтовые ящики Hackerone однозначно будет приходить всё больше сгенерированного ИИ мусора.
Обсуждение темы на Hacker news.
Автор: Bright_Translate
