Git — одна из самых популярных систем контроля версий, используемая миллионами разработчиков по всему миру. Ее надежность и безопасность крайне важны для сохранения целостности и конфиденциальности проектов. Однако недавно обнаруженная критическая уязвимость CVE-2025-48384 проливает свет на важный аспект безопасности, связанный с особенностями обработки файлов конфигурации и взаимодействием с подмодулями в Git. Эта уязвимость особенно актуальна для пользователей Unix-подобных систем и может привести к удаленному выполнению кода при клонировании репозиториев с опцией --recursive из непроверенных источников. Понимание механизмов, стоящих за этой уязвимостью, и своевременное обновление Git и связанных инструментов является важной задачей для специалистов в области безопасности и разработчиков.
Суть проблемы связана с особенностями работы Git с текстовыми файлами, точнее с форматом файлов конфигурации, таких как .gitmodules. Этот файл необходим для отслеживания подмодулей в репозитории и оформлен в стиле ini-файлов с секциями и ключ-значениями. Особенно важна здесь возможность Git обрабатывать различные виды символов конца строки, включая классические символы возврата каретки \r и перевода строки \n. Исторически понятия «возврат каретки» и «перевод строки» произошли из механики старых печатных машинок, где возврат каретки служил для возвращения печатающей головки в начало строки, а перевод строки — для перехода к следующей строке.
В системах Unix для разделения строк используется только символ перевода строки \n, тогда как в Windows традиционно применяются два символа — сочетание \r\n. Git умеет работать с обоими форматами. В функции get_next_char, отвечающей за чтение символов из конфигурационных файлов, реализована логика проверки символа возврата каретки. Если после \r следует \n, Git считает это одним символом конца строки и обрабатывает корректно. Если же следующий символ иной, то возвращается сам \r и следующий символ ставится обратно в поток для повторного чтения.
Эта тонкость становится ключевым фактором для эксплуатации уязвимости. Когда Git записывает конфигурационные файлы, в частности значения ключей, он проверяет наличие определенных символов или пробелов, чтобы определить, следует ли значение брать в кавычки. Однако до публикации исправления кавычки не ставились при наличии в значении символа возврата каретки. В результате, значение, заканчивающееся на \r, при повторном чтении файла интерпретировалось некорректно. Рассмотрим, что происходит именно в файле .
gitmodules. Этот файл может содержать путь к подмодулю с именем, включающим символ возврата каретки. В Unix-подобных системах возможно создание файлов и папок с управляющими символами в имени, чего нельзя сделать в Windows. Git читает путь из .gitmodules и проверяет его корректность.
Однако при записи связанного с подмодулем конфигурационного файла, например в .git/modules, символ возврата каретки оказывается не защищен кавычками и в конечном итоге обрезается. Таким образом, путь, который изначально проверялся и считался безопасным, после записи и повторного чтения меняется. Подмодули клонируются и размещаются по обновленному пути. Это расхождение путей в процессе клонирования подмодулей создает логическую уязвимость.
Используя эту особенность, злоумышленник может заставить Git разместить содержимое подмодуля вне ожидаемых директорий, обходя ограничения системы или политики проверки безопасности. Возможные последствия включают произвольную перезапись файлов в файловой системе, вплоть до конфигурационных файлов Git или скриптов хуков, что может привести к выполнению произвольного кода в контексте пользователя. Интересно отметить, что уязвимость не затрагивает Windows напрямую, поскольку файловая система не допускает в именах файлов управляющих символов вроде \r. Однако macOS, а также многие разновидности Linux и другие Unix-подобные ОС уязвимы. Клиенты и инструменты, использующие Git как библиотеку или внутренний компонент, включая популярный GitHub Desktop, тоже подвергаются риску, особенно если они по умолчанию используют опцию --recursive для клонирования подмодулей.
Владелец уязвимости — David Leadbeater — подробно описал проблему и предложил простое, но эффективное решение. При записи конфигурационных значений в функцию write_pair была добавлена проверка на наличие символа возврата каретки в значении. Если такой символ присутствует, все значение заключается в двойные кавычки, что предотвращает неправильную интерпретацию при повторном чтении и ломает цепочку эксплоита. Такой подход гарантирует целостность данных и сохраняет корректную работу механизмов проверки. Меры защиты от CVE-2025-48384 в первую очередь связаны с обновлением Git и зависимых программ до версий, содержащих патч.
Дополнительным промежуточным способом снижения риска является отказ от использования опции --recursive при клонировании подозрительных репозиториев и ручная проверка файла .gitmodules на предмет присутствия необычных или управляющих символов в путях. Следует быть особенно внимательным при работе с неофициальными и малоизвестными источниками кода. Этот случай указывает на важность правильной обработки управляющих символов в текстовых протоколах и форматах конфигураций. Аналогичные проблемы часто встречаются в сетевых протоколах и межпроцессном взаимодействии, где несогласованность в интерпретации символов конца строки приводит к уязвимостям типа CRLF-инъекций.
В современных условиях принцип устаревшей рекомендации Постела «быть консервативным в своем поведении и щедрым в принятии данных» пересматривается, поскольку излишняя либеральность при парсинге может создавать бреши для атак. Уязвимость CVE-2025-48384 является одним из результатов аудита исходного кода Git, проведенного при поддержке G-Research Open Source. Помимо приведенной проблемы, были выявлены и устранены и другие ошибки различной степени серьезности. Эти события подчеркивают важность регулярных проверок безопасности и своевременного реагирования на найденные уязвимости. История развития уязвимостей, связанных с символом возврата каретки, в Git насчитывает несколько инцидентов.
В январе 2025 года были обнаружены проблемы с протоколом взаимодействия с кредитными помощниками, вызванные подобным эффектом. В 2023 году ошибки обработки конфигурационных файлов также приводили к потенциальным нарушениям целостности. Этот контекст помогает лучше осознать, что вопросы безопасного парсинга и шаблонной обработки данных существенно влияют на надежность сложных инструментов. Для разработчиков и системных администраторов важно ознакомиться с техническими деталями этой уязвимости и практическими путями ее эксплуатации, чтобы эффективно диагностировать проблемы и внедрять превентивные меры. Понимание влияния особых символов, таких как возврат каретки, на внутренние процессы инструментов может помочь в предотвращении подобных угроз и в других сферах разработки.
В конечном итоге CVE-2025-48384 демонстрирует, что даже мелкие, на первый взгляд, особенности исторического наследия, такие как управление символами конца строки, могут приводить к серьезным проблемам безопасности. Внимание к деталям, глубокий анализ кода и своевременное исправление уязвимостей играют ключевую роль в обеспечении надежности современных систем контроля версий и тем самым безопасности всего software development lifecycle.
