Ошибка безопасности, обнаруженная пятнадцать лет назад в публичном сообщении на GitHub, пережила попытки разработчиков устранить ее.
Несмотря на многочисленные предупреждения разработчиков о Gist на GitHub 2010 года, содержащем уязвимость обхода пути, в 2012, 2014 и 2018 годах уязвимость появилась в документации MDN Web Docs и фрагменте Stack Overflow.
Оттуда она распространилась по всему миру. модели (LLM) обучались на ошибочных примерах.Но его дни, возможно, сочтены.»Уязвимый фрагмент кода был впервые обнаружен в 2010 году на GitHub Gist, и он распространился на Stack Overflow, известные компании, учебные пособия и даже университетские курсы», — рассказал The Register Джафар Ахундали, кандидат наук из Лейденского университета в Нидерландах. в электронном письме.
Это даже заразило LLM и заставило их создавать в основном небезопасный код, когда их попросили написать код для этой задачи
«Большинство людей не обратили на это вниманияон уязвим, и хотя уязвимость проста, некоторые мелкие детали не позволили большинству пользователей увидеть ее. Это даже приводило к заражению LLM и заставляло их создавать в основном небезопасный код, когда их просили написать код для этой задачи».
Ахундали, который в 2019 году опубликовал исследовательскую статью о рисках копирования и вставки из примеров Stack Overflow, стремится устранить ошибку с помощью автоматизированной системы устранения уязвимостей..
Ахундали и его соавторы Хамидреза Хамиди, Кристиан Ритвельд и Ольга Гадяцкая описывают, как они это делают, в препринтной статье под названием «Устранение невидимого: обнаружение, использование и устранение уязвимости обхода путей на GitHub».
«В короче говоря, мы создали автоматизированный конвейер, который может автоматически обнаруживать, использовать и исправлять эту уязвимость во всех проектах GitHub», — сказал Ахундали. «Одним из главных преимуществ этого метода является то, что он не дает ложных срабатываний (помеченных как уязвимые, но безопасные), поскольку уязвимости сначала проверяются с помощью эксплойта в изолированной среде».
Ахундали сказал, что отличие от этой работы в том, что она включает в себя реальные действия. -мировое программное обеспечение, а не доступные наборы данных.
Ввод мусора и вывод мусора применимы и к LLM-системам
Постоянная уязвимость является примером общего перечисления слабых мест 22 (CWE-22), уязвимого шаблона кода, который может быть выражен различными способами и потенциально допускает несанкционированный доступ. злоумышленник пытается пройти по пути к файлу в приложении, чтобы получить доступ к каталогу, который находится за пределами обслуживаемого.Недостаток возникает из-за наличия функции join, которая объединяет два пути таким образом, что этим можно злоупотребить, чтобы избежать доступа к указанному каталогу или вызвать отказ в обслуживании из-за нехватки памяти.Это распространяется не только разработчиками, которые не в состоянии оценить риск, потому что клиентские инструменты, такие как curl, могут скрыть проблему, но и LLM-специалистами, обученными работе с уязвимыми примерами кода, извлеченными из наборов данных, полученных из GitHub и Stack Overflow code.Чтобы доказать это, авторы создали два сценария с участием Клода, второго пилота, Второго изобретательного пилота, второго точного пилота, GPT-3.5, GPT-4, GPT-4o и Gemini. Во-первых, они предложили каждому LLM создать статический файловый сервер без сторонних библиотек, а затем попросили его обеспечить безопасность кода. Во-вторых, они попросили каждого LLM создать защищенный статический файловый сервер без сторонних библиотек. Эти запросы повторялись по 10 раз для каждой модели.
В первом сценарии 76 из 80 запросов воспроизводили уязвимый код, а количество запросов снизилось до 42 из 80, когда модель попросили сделать код безопасным. Во втором сценарии, в котором изначально запрашивался безопасный код, 56 из 80 запросов вернули уязвимые образцы.»Этот эксперимент показывает, что популярные чат-боты LLM изучили уязвимый шаблон кода и могут уверенно генерировать небезопасные фрагменты кода, даже если пользователь специально запрашивает у них безопасную версию», — отмечают авторы, добавляя, что «GPT-3.5 и Copilot (сбалансированный) не генерируйте безопасный код в любом сценарии».
По словам Ахундали, тесты были проведены в июле 2024 года, поэтому с тех пор безопасность сгенерированного кода, возможно, изменилась.
С появлением агентов по кодированию и тенденций к «виртуальному кодированию» слепое доверие коду, сгенерированному искусственным интеллектом, без его полного понимания, создает серьезные риски для безопасности
«Возможно, стоит упомянуть, что в некоторых экспериментах LLMS упоминали, что «уязвимый код» на самом деле безопасен», — сказал он. «В некоторых случаях он обнаруживал уязвимость, а в некоторых других случаях исправление все еще было небезопасным. Таким образом, простое принятие результатов LLM не является надежным решением».
Ахундали добавил, что, хотя разработчики могут предпочесть LLM таким платформам, как StackOverflow, для удобства, LLM не предоставляют аналитической информации, проверенной экспертами.
«С появлением программистов и тенденций к «виртуальному кодированию» слепое доверие коду, сгенерированному искусственным интеллектом, без его полного понимания представляет серьезную угрозу безопасности», — сказал он. «Сложность в том, что даже при наличии нескольких экспертных оценок безопасность не может быть гарантирована, что оставляет проблему нерешенной».
Фактически, исследователи полагались на искусственный интеллект, чтобы найти ошибку обхода пути в общедоступных хранилищах кода и устранить ее.
Что они обнаружили и что сделали дальше
Ахундали и его коллеги разработали автоматизированный конвейер, который сканирует GitHub на наличие репозиториев с уязвимым шаблоном кода, проверяет, можно ли использовать код, и при необходимости генерирует патч используя GPT-4 от OpenAI, и сообщает о проблеме сопровождающему репозитория.
Скриншот GPT-4 предложение по исправлению кода — Нажмите, чтобы увеличить
В документе отмечается, что ответственное раскрытие результатов было одной из самых сложных частей разработки. Например, авторы намеренно избегали открывать проблемы на GitHub в популярных репозиториях (более 200 баллов) из-за опасений, что злоумышленники могут увидеть опубликованные в открытом доступе заметки и догадаться о характере ошибки до применения исправления. Чтобы избежать этого, они отправили уведомления по электронной почте на адреса электронной почты проектов, где они были доступны.
Из 40 546 проектов с открытым исходным кодом, загруженных с GitHub, было обнаружено 41 870 файлов с уязвимостями. Статическое тестирование безопасности приложений позволило сократить количество уязвимых файлов до 8397. Из них 1756 можно было использовать автоматически, что привело к созданию 1600 исправлений.»Общий показатель исправлений среди проектов, получивших запрос на перенос, составляет 11 процентов», — говорится в документе. «В общей сложности в 63 из 464 отчетов была устранена уязвимость (показатель устранения составил 14 процентов среди проектов, получивших полную информацию об уязвимости и исправлениях)».
«Хотя этот показатель невелик, основная причина этого заключается в том, что многие проекты больше не поддерживаются, и жизненный цикл программного обеспечения был завершен до того, как была обнаружена уязвимость», — пояснил Ахундали. «В некоторых случаях код использовался на этапе разработки, а не на рабочем сервере. Таким образом, это могло подвергнуть риску компьютер разработчика или серверы CI/CD. Этот код не просто потенциально небезопасен; он полностью уязвим, открывая доступ к файловой системе».
Несмотря на это, авторы отмечают, что низкий уровень исправлений свидетельствует о том, что разработчики не уделяют достаточного внимания уведомлениям об уязвимостях.Это понятно, учитывая отчеты проектов с открытым исходным кодом, таких как curl, которым приходилось бороться с некачественными отчетами об ошибках, генерируемыми ИИ, которые отнимают время у разработчиков. Когда искусственный интеллект становится частью проблемы, а не только ее решения, привлечение людей к разработке программного обеспечения с открытым исходным кодом важно как никогда. ®
