В 2024 году мы выпустили пост We Hacked Google A.I. for $50,000, в котором говорилось, как наша группа в составе Рони «Lupin» Карта (это я), Джозефа «rez0» Тэкера и Джастина «Rhynorater» Гарднера поехала в 2023 году в Лас-Вегас, чтобы искать уязвимости Gemini на проводимом Google мероприятии LLM bugSWAT. В этом году мы повторили нашу поездку…
Мир генеративного ИИ (Generative Artificial Intelligence, GenAI) и больших языковых моделей (Large Language Model, LLM) продолжает оставаться технологическим Диким Западом. С момента, когда на арене появились GPT, гонка за доминированием в сфере LLM лишь ожесточилась: за создание самой качественной модели конкурируют такие технологические гиганты, как Meta*, Microsoft и Google. Но теперь на арену выходят Anthropic, Mistral, Deepseek и другие компании, сильно повлиявшие на эту отрасль.
Компании активно создают ИИ-помощников, классификаторы и множество других инструментов на основе LLM, но остаётся актуальным критически важный вопрос: действительно ли разработка выполняется безопасно? Как было сказано нами в прошлом году, из-за стремительного внедрения иногда кажется, что мы забыли фундаментальные принципы безопасности, открыв двери как для новых, так и уже знакомых уязвимостей.
Мир искусственного интеллекта быстро меняется из-за появления ИИ-агентов. Такие интеллектуальные сущности используют сложные алгоритмы «цепочек рассуждений» (chains of thought): процессы, при которых модель генерирует целостную последовательность внутренних этапов рассуждений для решения сложных задач. Документируя свой мыслительный процесс, эти агенты не только улучшают свои способности принятия решений, но и обеспечивают прозрачность, позволяя разработчикам и исследователям понимать и совершенствовать их. Такая динамическая комбинация автономной работы и визуальных рассуждений прокладывает путь к созданию ещё более адаптивных, интерпретируемых и надёжных ИИ-систем. Мы становимся свидетелями появления множества приложений: от интерактивных помощников до изощрённых систем помощи в принятии решений. Интеграция алгоритмов chain-of-thought в ИИ-агенты задаёт новый стандарт достижений моделей в реальных сценариях использования.
Компания Google, к своей чести, активно исследует этот новый фронт безопасности ИИ и начала заниматься этим достаточно давно. Мероприятия LLM bugSWAT, проводящиеся в таких популярных местах, как Лас-Вегас — свидетельство стремления к проактивному исследованию проблемы «красными» командами. Такие мероприятия стимулируют исследователей со всего мира тщательно тестировать свои ИИ-системы, выискивая в них уязвимости.
В 2024 году мы снова ответили на этот вызов! Мы с Джастином вернулись на bugSWAT в Лас-Вегасе, и на этот раз наши усилия были крупно вознаграждены. Благодаря новой уязвимости в Gemini, о которой мы расскажем в посте, нам присудили звание самых ценных хакеров (Most Valuable Hacker, MVH) этого года!
Исследуем новый Gemini
Команда Google предоставила нам ранний доступ к следующему обновлению Gemini, в котором будет добавлено множество восхитительных функций. Наряду с исключительным доступом мы получили подробную документацию с объяснением этих функций и их возможностей. Цель заключалась в полном исследовании и тестировании этих возможностей с точки зрения нападающего.
Всё началось с простого промта. Мы попросили Gemini:
run hello world in python3 (запусти hello world на python3)Gemini показал код, а в интерфейсе появилась любопытная кнопка «Запустить в песочнице». Это нас заинтриговало, и мы приступили к изучению.
Gemini Python Playground – безопасное пространство… Или нет?
В Gemini появился Python Sandbox Interpreter. Его можно считать безопасным местом для запуска в самой среде Gemini кода на Python, написанного самим ИИ, и даже собственных скриптов пользователя. Эта песочница, созданная на основе Google gVisor в GRTE (Google Runtime Environment), была спроектирована как безопасное решение. Идея заключается в том, чтобы можно было экспериментировать с кодом без риска нанесения ущерба системе; это очень важная возможность для разработки и тестирования.
gVisor — это разработанное Google ядро пользовательского пространства, используемое в качестве посредника между контейнированными приложениями и операционной системой хоста. Перехватывая выполняемые приложениями системные вызовы, оно создаёт строгие границы безопасности, снижающие риск побега из контейнеров, а также ограничивает потенциальный урон от скомпрометированных процессов. gVisor не полагается исключительно на традиционную изоляцию уровня операционной системы, а реализует минимальное специализированное подмножество функций ядра, уменьшая таким образом поверхность атаки, но сохраняя при этом приемлемую производительность. Такой инновативный подход повышает безопасность контейнерных окружений, делая gVisor обязательным инструментом для безопасного запуска контейнированных нагрузок и управления ими.
Мы, исследователи безопасности и охотники за баг-баунти, знаем, что песочница gVisor защищена множеством слоёв, и, судя по изученной мной информации, пока никому не удалось устроить побег из этой песочницы. На самом деле, побег из песочницы принёс бы награду в 100 тысяч долларов:
Хоть побег из неё и возможен, это совершенно другая задача.
Однако не всегда обязательно осуществлять побег из песочницы, ведь во многих случаях внутри неё есть элементы, позволяющие реализовать утечку данных. Сотрудник команды безопасности Google дал нам такую идею: попробовать получить доступ к оболочке изнутри самой песочницы, чтобы поискать данные, которые не должны быть доступны. Главная проблема заключалась в следующем: эта песочница может выполняться только в специальном скомпилированном двоичном файле Python.
Размечаем территорию
Первым делом мы увидели, что из фронтенда можно полностью переписать код на Python и запустить нашу произвольную версию песочницы. Для начала нужно было понять структуру этой песочницы. Мы подозревали, что внутри могут таиться интересные файлы. Так как мы не могли запустить оболочку, то проверили, какие библиотеки в этом скомпилированном двоичном файле Python. Обнаружилось, что там есть os! Отлично, можно использовать её для изучения файловой системы.
Мы написали на Python следующий код:
import os def get_size_formatted(size_in_bytes): if size_in_bytes >= 1024 ** 3: size = size_in_bytes / (1024 ** 3) unit = "Go" elif size_in_bytes >= 1024 ** 2: size = size_in_bytes / (1024 ** 2) unit = "Mb" else: size = size_in_bytes / 1024 unit = "Ko" return f"{size:.2f} {unit}" def lslR(path): try: # Определяем, является ли путь папкой или файлом if os.path.isdir(path): type_flag = 'd' total_size = sum(os.path.getsize(os.path.join(path, f)) for f in os.listdir(path)) else: type_flag = 'f' total_size = os.path.getsize(path) size_formatted = get_size_formatted(total_size) # Проверяем разрешения на чтение и запись read_flag = 'r' if os.access(path, os.R_OK) else '-' write_flag = 'w' if os.access(path, os.W_OK) else '-' # Выводим тип, разрешения, размер и путь print(f"{type_flag}{read_flag}{write_flag} - {size_formatted} - {path}") # Если это папка, то рекурсивно выводим содержимое if type_flag == 'd': for entry in os.listdir(path): entry_path = os.path.join(path, entry) lslR(entry_path) except PermissionError: print(f"d-- - 0Ko - {path} (PermissionError: cannot access)") except Exception as e: print(f"--- - 0Ko - {path} (Error: {e})")Задача этого кода — получить рекурсивную функцию для создания списка файлов и папок, чтобы узнать, какие файлы там присутствуют, их размер и разрешения.
Мы использовали функцию для получения списка папки lslR("/usr").
Благодаря этому вызову нам удалось найти двоичный файл, находящийся в /usr/bin/entry/entry_point. Звучит интересно!
Утечка файла entry_point
Следующим этапом было извлечение этого файла, но он имеет размер 579 Мб, поэтому напрямую кодировать его в base64 и выводить во фронтенд было бы невозможно: вся песочница бы повисла и в конце концов завершила работу по таймауту.
Мы попробовали проверить, можно ли выполнить вызовы TCP, HTTP и DNS для изъятия информации. Любопытно, что наши попытки установить исходящие соединения завершились неудачей, а песочница казалась полностью изолированной от внешней сети. У нас возник интересный вопрос: если песочница настолько сильно изолирована, что не может выполнять внешние вызовы, то как она взаимодействует с сервисами Google наподобие Google Flights? Что ж… возможно, мы узнаем ответ позже.
Итак, нам нужно было вытащить этот двоичный файл, печатая его в консоль по блокам, для чего мы воспользовались функцией seek() , позволившей нам пройти по двоичному файлу и извлечь его целиком блоками по 10 МБ.
import os import base64 def read_and_encode(file_path, kilobytes): try: # Вычисляем количество считываемых файлов num_bytes = kilobytes * 1024 # Открываем файл и считываем указанное количество байтов with open(file_path, 'rb') as file: file_content = file.read(num_bytes) # Кодируем байты в Base64 encoded_content = base64.b64encode(file_content) # Выводим закодированную строку print(encoded_content.decode('utf-8')) except FileNotFoundError: print(f"FileNotFoundError: {file_path} does not exist") except PermissionError: print(f"PermissionError: Cannot access {file_path}") except Exception as e: print(f"Error: {e}") read_and_encode("/usr/bin/entry/entry_point", 10000)
Затем мы воспользовались Caido для перехвата запроса в нашем прокси, который должен был выполнять вызов песочницы, получать результат и затем отправлять его в функцию Automate. Функция Automate позволяет отправлять запросы группами. Так мы гибким образом можем инициировать брутфорс/фаззинг для быстрого изменения отдельных параметров запросов при помощи списков слов.
Примечание от Lupin: судя по описанию, кажется, что наш путь был простым, но на самом деле, чтобы добраться до этого этапа, нам понадобилось много часов. Мы с Джастином занимались хакингом в три часа ночи, и когда Джастин извлекал двоичный файл при помощи Caido, я уже спал на своей клавиатуре.
Получив блоки в кодировке base64, мы воссоздали весь файл локально и были готовы приступать к изучению его содержимого.
Как прочитать этот файл?
Команда file?
Команда file, запущенная с двоичным файлом, определила его как двоичный файл: 64-битный общий объект ELF LSB, x86-64, версии 1 (SYSV), с динамической компоновкой, интерпретатор /usr/grte/v5/lib64/ld-linux-x86-64.so.2 То есть это действительно двоичный файл. Хм, что можно с этим сделать?
Команда strings?
Вывод команды strings оказался особенно интригующим из-за множества ссылок на внутренний репозиторий Google google3. Это дало нам подсказку о существовании внутренних путей данных и блоков кода, не предназначавшихся для раскрытия вовне, что чётко говорило о существовании в двоичном файле следов проприетарного ПО Google. Но влияет ли это как-то на безопасность?
Binwalk!
Настоящий прорыв случился при использовании Binwalk. Этому инструменту удалось извлечь из двоичного файла полную структуру файлов, что позволило нам увидеть сложное содержимое песочницы. При извлечении обнаружилось множество папок и файлов, что дало нам подробную картину внутренней архитектуры, и выявило компоненты, которые нас потрясли.
Постойте-ка… это что, внутренний исходный код?
При изучении данных, сгенерированных нашим анализом binwalk, мы неожиданно обнаружили внутренний исходный код. Извлечение выявило целые папки проприетарного исходного кода Google. Но конфиденциален ли он?
Папка Google3 с кодом на Python
В папке, извлечённой при помощи binwalk, мы смогли найти папку google3 со следующими файлами:
total 2160 drwxr-xr-x 14 lupin staff 448B Aug 7 06:17 . drwxr-xr-x 231 lupin staff 7.2K Aug 7 18:31 .. -r-xr-xr-x 1 lupin staff 1.1M Jan 1 1980 __init__.py drwxr-xr-x 5 lupin staff 160B Aug 7 06:17 _solib__third_Uparty_Scrosstool_Sv18_Sstable_Ccc-compiler-k8-llvm drwxr-xr-x 4 lupin staff 128B Aug 7 06:17 assistant drwxr-xr-x 4 lupin staff 128B Aug 7 06:17 base drwxr-xr-x 5 lupin staff 160B Aug 7 06:17 devtools drwxr-xr-x 4 lupin staff 128B Aug 7 06:17 file drwxr-xr-x 4 lupin staff 128B Aug 7 06:17 google drwxr-xr-x 4 lupin staff 128B Aug 7 06:17 net drwxr-xr-x 9 lupin staff 288B Aug 7 06:17 pyglib drwxr-xr-x 4 lupin staff 128B Aug 7 06:17 testing drwxr-xr-x 9 lupin staff 288B Aug 7 06:17 third_party drwxr-xr-x 4 lupin staff 128B Aug 7 06:17 utilВ папке assistant также обнаружился внутренний код Gemini, связанный с вызовами RPC (используемыми для обработки запросов через инструменты наподобие YouTube, Google Flights, Google Maps и так далее). Папка имела следующую структуру:
. ├── __init__.py └── boq ├── __init__.py └── lamda ├── __init__.py └── execution_box ├── __init__.py ├── images │ ├── __init__.py │ ├── blaze_compatibility_hack.py │ ├── charts_json_writer.py │ ├── format_exception.py │ ├── library_overrides.py │ ├── matplotlib_post_processor.py │ ├── py_interpreter.py │ ├── py_interpreter_main.py │ └── vegalite_post_processor.py ├── sandbox_interface │ ├── __init__.py │ ├── async_sandbox_rpc.py │ ├── sandbox_rpc.py │ ├── sandbox_rpc_pb2.pyc │ └── tool_use │ ├── __init__.py │ ├── metaprogramming.py │ └── runtime.py └── tool_use ├── __init__.py └── planning_immersive_lib.py 8 directories, 22 filesПриглядимся к коду на Python
Внутри файла google3/assistant/boq/lamda/execution_box/images/py_interpreter.py обнаружился следующий фрагмент кода:
# Строка для выявления попыток дампа скриптов: snippet = ( # pylint: disable=unused-variable "3AVp#dzcQj$U?uLOj+Gl]GlY<+Z8DnKh" # pylint: disable=unused-variable )Похоже, этот фрагмент использовался как мера защита от неавторизованного дампинга скриптов, что определённо давало понять, что код не предназначен для публичного раскрытия.
После тщательного исследования мы решили, что включение того, что походило на внутренний код Google3, на самом деле было намеренным выбором.
Код на Python, несмотря на применение защиты от дампинга, команда безопасности Google заранее разрешила раскрывать публично. Хотя эти меры изначально предназначались для предотвращения нежелательного вывода, их оставили, потому что… а почему бы и нет?
Но на этом мы не оставили песочницу в покое, потому что чувствовали, что близки к чему-то серьёзному!
Копаемся в основной логике песочницы
При более глубоком изучении кода на Python мы заметили, что, как и можно было предполагать, эта песочница общается с внешними серверами Google, например, для получения данных из Google Flights и других сервисов Google.
Это было реализовано при помощи класса Python (google3.assistant.boq.lamda.execution_box.sandbox_interface), раскрывавшего различные функции наподобие _set_reader_and_writer, которые можно было вызывать.
def _set_reader_and_writer( reader_handle: io.BufferedReader | None, writer_handle: io.BufferedWriter | None, ) -> None: """Sets the readeаr and writer handles for rpcs. Should be called before running any user code that might import async_sandbox_rpc Args: reader_handle: the handle through which to receive incoming RpcResponses. If None will default to legacy behavior (/dev/fd/3) writer_handle: the handle through which to receive incoming RpcRequests. If. None will default to legacy behavior (/dev/fd/4) """ with _INIT_LOCK: global _READER_HANDLE global _WRITER_HANDLE _READER_HANDLE, _WRITER_HANDLE = reader_handle, writer_handle def run_tool( name: str, operation_id: str, parameters: str ) -> sandbox_rpc_pb2.RunToolResponse: """Runs a tool with the given name and id, passing in parameters. Args: name: The name of the tool. operation_id: The name of the operation to perform. parameters: The parameters to pass to the tool. Returns: A RunToolResponse containing the response from the tool. """ result = make_rpc( sandbox_rpc_pb2.RpcRequest( run_tool_request=sandbox_rpc_pb2.RunToolRequest( name=name, operation_id=operation_id, parameters=parameters ) ) ) if result and result.HasField("run_tool_response"): return result.run_tool_response else: return sandbox_rpc_pb2.RunToolResponse(response="") Мы можем передавать этим функциям различные блоки данных, они будут сериализовать данные в формат, совместимый с protobuf, а затем вызывать RPC, выполняя запись в дескриптор локального файла 5. Далее ответ можно считать из дескриптора локального файла 7. Благодаря использованию proto, найденных в огромном двоичном файле, мы смогли создавать входящие и исходящие сообщения сервера RPC, а также непосредственно вызывать эти инструменты Google.
Однако мы обнаружили нечто интересное: не во всех песочницах был доступен один и тот же список сервисов Google. Это зависело от того, кем создавалась песочница: фронтендом, способным выполнять исходный код на Python, или Google Agent. Что это означает?
Исследовательская статья про ReAct
Прежде чем приступать к дальнейшим объяснениям, нужно сказать, что команда Google показала нам следующую исследовательскую статью, на основе которой был создан Gemini:
В этой статье представлен новый (на момент публикации) подход: языковые модели попеременно генерируют пути рассуждений и выполняют определённые действия, по сути, переплетая свои мысли и поведение. На практике это означает, что в процессе размышлений над задачей модель создаёт прозрачный след из рассуждений, который позволяет ей планировать, отслеживать и регулировать свои действия, одновременно при необходимости взаимодействуя с внешними источниками для получения дополнительных данных. Такое динамическое взаимодействие не только повышает точность модели благодаря устранению частых проблем (например, галлюцинаций и распространения ошибок), но и делает процесс принятия решений более интерпретируемым и контролируемым для живых операторов.
Интегрируя и внутренние рассуждения, и внешние знания, ReAct создаёт гибкий обобщённый каркас, превосходно справляющийся с широким спектром задач, от ответов на вопросы и проверки фактов до текстовых игр и веб-навигации. По сути, ReAct использует сильные стороны и рассуждений, и действий, обеспечивая реализацию более надёжных, удобных для людей и универсальных языковых моделей.
Допустим, но зачем нам нужно это понимать? Ну, если следовать логике статьи, то Gemini может многократно отправлять самому себе промт, чтобы улучшать команды и обеспечить правильную цепочку рассуждений.
Если пользователь спросит: «Когда ближайший рейс из Торонто в Нью-Йорк», то цепочка рассуждений Gemini будет примерно такой:
-
Пользователь просит меня поискать ближайший рейс между Торонто и Нью-Йорком
-
Создаём такой план:
-
Мне нужно запустить код на Python, связывающийся с инструментом Google Flights
-
Код должен найти все рейсы с текущей даты до следующей недели между аэропортами YYZ и JFK
-
Код должен отсортировать по дате рейсы и взять первый элемент
-
-
После завершения плана он сгенерирует код при помощи имеющихся у Agent инструментов
-
После генерации кода он создаст песочницу с подходящими привилегиями (например, с доступом к инструменту Google Flights через дескриптор файла)
-
Выполнит код, обработает вывод
-
Сгенерирует ответ пользователю
Наша теория была такой:
-
Что, если мы сможем выполнить вторичное инъецирование промта на этапе планирования Gemini, чтобы получить доступ к более привилегированной песочнице?
Благодаря помощи команды безопасности Google мы протестировали эту идею и заметили, что при некоторых параметрах порождающего значения генерации и температуры (это обычные вероятностные нюансы LLM), мы иногда можем получить доступ к чему-то, напоминающему более привилегированную песочницу.
Под этим мы подразумеваем, что нападающий может получить доступ к расширениям через два новых дескриптора файлов. Эти дескрипторы файлов присутствуют всегда, но не всегда выполняют активное прослушивание; когда агент вызывает песочницу, они мониторят вызовы расширений (сервисов Google), чтобы мы могли взаимодействовать с API, а при доступе из интерпретатора Python эти расширения остаются недоступными.
Благодаря этому мы решили, что существует реальная возможность уязвимости P0: есть конкретный обработчик сообщений, который может позволить читать файлы во внутренней инфраструктуре Google, и мы надеялись, что песочница с расширением для работы с инструментом сможет инициировать вызов RPC к этому конкретному инструменту. Учитывая вероятностную природу атаки, усложнявшую её стабильное воспроизведение, мы попросили команду безопасности Google оценить ситуацию. В конечном итоге, она выяснила, что подозрительный обработчик сообщений недоступен через RPC и может вызываться только снаружи.
Хотя мы были ограничены в тестах, основная идея при дальнейшем исследовании обладала реальным потенциалом. Выполнение кода в контексте песочницы не должно давать дополнительные возможности, оно считается ненадёжным, снаружи песочницы выполняются проверки безопасности, а каждый вызов инструментов фильтруется. Невозможность запуска кода давало нам удобные преимущества:
-
Надёжность: после того, как мы сможем выполнять код, запуск действий будет более стабильным.
-
Цепочки/сложность: контролировать множество разных инструментов или выполнять fine-tuning параметров обычным текстом сложно; выполнение кода позволит нам создавать более сложные цепочки даже при наличии мер защиты.
-
Отравление выводимых инструментами результатов: мы сможем эффективнее манипулировать выводом инструментов.
-
Утечки: могут существовать другие скрытые части окружения, которые при обнаружении могут дать нам дополнительные преимущества.
Это показывает, что наша идея всё ещё имеет перспективы дальнейшей эскалации. А из-за потенциала возникновения утечек мы решили хотя бы проверить эту теорию…
Мы нашли нашу утечку
При более глубоком изучении мы нашли множество способов реализации утечки файлов proto. Файлы proto (сокращение от Protocol Buffer) — это «чертежи» данных, определяющие, как будут структурироваться сообщения и как будет выполняться обмен данными между разными частями системы. На первый взгляд они могут казаться безвредными, но утечка этих файлов может дать нам более подробную информацию о внутренней инфраструктуре Google.
Раскрываем classification.proto
Оказалось, что выполнив команду вида:
strings entry_point > stringsoutput.txtа затем поискав получившемся файле «Dogfood», можно извлечь блоки внутренних proto. Части извлечённого содержимого включены в описания метаданных крайне конфиденциальных proto. Сами по себе они не содержали пользовательских данных, но это внутренние категории, которые Google использует для классификации пользовательских данных.
По юридическим причинам мы не можем показать результат выполнения этой команды.
Почему мы искали именно строку «Dogfood»? В Google «догфудом» называется практика использования предрелизных версий продуктов и прототипов компании для тестирования и совершенствования их перед публичным выпуском. Это позволяет разработчикам тестировать развёртывание и потенциальные проблемы в этих продуктах до вывода в продакшен.
Более того, мы обнаружили раскрытый файл privacy/data_governance/attributes/proto/classification.proto, в котором подробно описывался способ классификации данных в Google. Хотя в файле присутствуют ссылки на соответствующую документацию, эти документы остаются высококонфиденциальными и не должны быть доступны публично.
Ещё одно примечание от Lupin: мы обнаружили это на следующий день после нашего ночного извлечения двоичного файла. Мы находились в арендованном Google номере отеля и вместе с командой безопасности разбирались, что же мы нашли. На этот раз Джастин спал на диване! Мы так долго искали этот баг, но это полностью себя оправдало!
Раскрытие внутренних определений Proto безопасности
В том же выводе мы также нашли множество внутренних файлов proto, которые должны были оставаться сокрытыми. Выполнив команду
cat stringsoutput.txt| grep '\.proto' | grep 'security'мы получили список множества конфиденциальных файлов, в том числе:
security/thinmint/proto/core/thinmint_core.proto security/thinmint/proto/thinmint.proto security/credentials/proto/authenticator.proto security/data_access/proto/standard_dat_scope.proto security/loas/l2/proto/credstype.proto security/credentials/proto/end_user_credentials.proto security/loas/l2/proto/usertype.proto security/credentials/proto/iam_request_attributes.proto security/util/proto/permission.proto security/loas/l2/proto/common.proto ops/security/sst/signalserver/proto/ss_data.proto security/credentials/proto/data_access_token_scope.proto security/loas/l2/proto/identity_types.proto security/credentials/proto/principal.proto security/loas/l2/proto/instance.proto security/credentials/proto/justification.protoПоискав в двоичных строках security/credentials/proto/authenticator.proto, мы действительно убедились, что данные раскрыты.
Зачем здесь были нужны эти proto?
Как мы говорили ранее, команда безопасности Google тщательно изучила всё в песочнице и одобрила нашу публикацию. Однако в конвейере сборки для компиляции двоичного файла песочницы присутствовал автоматизированный этап, добавлявший в бинарник файлы proto безопасности, если он обнаруживал, что этому бинарнику они требуются для применения внутренних правил.
В данном случае этот этап не был обязателен и привёл к непреднамеренному добавлению высококонфиденциальных внутренних proto!
Нам, охотникам за баг-баунти, очень важно глубоко понимать правила бизнеса, на которых строятся процессы в компании. Мы сообщили об этих утечках proto, потому что знали, что Google считает их высококонфиденциальной информацией и что их ни в коем случае нельзя раскрывать. Чем больше мы понимаем внутреннее устройство и приоритеты нашей цели, тем лучше справляемся с выявлением подобных малозаметных багов, которые в противном случае могли ускользнуть из поля зрения. Такое глубокое знание не только позволяет нам обнаруживать уязвимости, но и гарантирует соответствие наших отчётов критериям безопасности организации.
Заключение
Прежде чем завершить пост, должен сказать, что перед выводом в эксплуатацию таких передовых ИИ-систем жизненно необходимо выполнять их тестирование. В них так много взаимосвязей и мощных возможностей, что даже простая песочница с доступом к разным расширениям потенциально может привести к неприятным сюрпризам. Мы лично убедились в том, что когда все части системы работают совместно, даже небольшие оплошности могут открыть новые источники проблем. Иными словами, тщательное тестирование не просто рекомендуется — это единственный способ обеспечения безопасности и надлежащей работы.
В конечном итоге, мы получили огромное удовольствие от процесса. Взлом уязвимостей, раскрытие спрятанного кода и расширение возможностей песочницы Gemini были сложны, но в то же время нас очень радовала эта охота.
*Meta Platforms признана экстремистской организацией, её деятельность в России запрещена.
ссылка на оригинал статьи https://habr.com/ru/articles/896092/
Добавить комментарий