В Git обнаружены серьезные уязвимости

В Git обнаружены серьезные уязвимости

В Git обнаружены серьезные уязвимости

Исследователь Лаел Целлье (Laël Cellier) обнаружил в серверной и клиентской части Git две опасные проблемы, которые затрагивают ветки 2.x, 1.9 и 1.7. В числе прочего, баги представляют потенциальную опасность для таких популярных ресурсов как Github, Bitbucket, Gerrit и Gitlab.

Два найденных в коде бага (CVE-2016-2324 и CVE-2016-2315) могут привести к исполнению произвольного кода и переполнению буфера. Для эксплуатации уязвимостей атакующему нужно создать репозиторий с деревом файлов с чрезвычайно длинными именами, а затем пушнуть его на уязвимый сервер (атака на сервер) или позволить уязвимому клиенту склонировать его из удаленного репозитория (атака на клиента).

Одна из уязвимостей была устранена с выходом версии 2.7.1, релиз которой состоялся в прошлом месяце, вторую проблему исправят в версии 2.8, которая пока только ожидает релиза

Целлье обнаружил два бага, и они оба связаны с функцией path_name(),которая используется для добавления имени файла к концу пути в дереве репозитория. Вот так выглядел код revision.c, то есть Git до версии 2.7.0:

 

Git

 

В коде хорошо просматривается уязвимость CVE-2016-2315. Из приведенного отрывка видно, что если strlen() будет работать с излишне длинным именем файла и получится излишне большое число, это закончится переполнением для nlen, из-за чего значение получится отрицательным, а не положительным. Из-за этого len тоже станет отрицательным, и памяти, запрошенной xmalloc(), может не хватить для итоговой комбинированной строки, пишет xakep.ru.

Функция strcpy() тоже подвержена ошибкам переполнения буфера. Вслепую копируя заданное атакующим длинное имя файла в буфер меньшего размера, она спровоцирует переполнение буфера. Функция повредит другие находящиеся в памяти данные (heap overwrite), таким образом позволяя атакующему управлять работой программы.

Исправление для версии 2.7.0 заменяет strcpy() более безопасной memcpy():

memcpy(m, name, nlen + 1);

Однако остается вторая проблема — CVE-2016-2324. Длинные пути, множество поддиректорий и огромные имена файлов могут вызвать другой вариант повреждения данных (heap overwrite) — уже из-за len. К примеру, для пути A/B/C, где A и B имеют длину 2^31-5, а C имеет длину 20, len будет равняться 10, а этого слишком мало, в буфер не поместится даже C, не говоря обо всем остальном.

В таких путях запросто можно хранить данные, к примеру, вредоносные пейлоады. В данном случае волноваться о том, что строка слишком длинная и «тяжелая» не нужно. При передаче информации от сервера клиенту (и наоборот) Git сжимает данные, используя zlib, что распространяется и на имена файлов. В теории можно создать дерево объемом тысячи килобайт или даже мегабайт, а затем использовать его для выведения из строя ASLR, исполнения кода и других неприятных трюков.

Как избавиться от CVE-2016-2324? Заменить path_name() чем-то более безопасным, что и было проделано в версии 2.8, которая сейчас ожидает релиза. Сам Целлье о данной проблеме высказался так:

«Исправление, которое я придумал: преобразовать все эти int в size_t. Это не исправит проблему окончательно, но на 64-разрядных системах потребуется путь длиной 2^64, чтобы уязвимость сработала, что вряд ли возможно. Правда, это не поможет 32-разрядным системам (хотя, на деле, я не удивлюсь, если все сломается задолго до этого, так как список name_path уже не поместится в памяти)».

Для демонстрации проблемы Целлье создал репозиторий longpath. Его главную страницу открыть невозможно – ошибка HTTP 500, но можно почитать Wiki.

Также исследователь пожаловался, что проблеме не уделяют должного внимания, к примеру, сообщил, что по его данным баги не устранены ни в одном дистрибутиве Linux. По словам Целлье уязвимостям была необходима «реклама».  Он оказался прав – стоило прессе обратить внимание на проблему, как выяснилось, что, например, все версии Debian GNU/Linux уязвимы перед CVE-2016-2324. Похоже, единственные, кто обновился своевременно, это GitHub, а затем один из его главных конкурентов — GitLab. Кстати, за свою находку Целлье получил от GitHub 5000 баллов по программе обнаружения уязвимостей.

Инфосистемы Джет запустила кибериспытания с призом до 1,5 млн

Компания «Инфосистемы Джет» запустила программу кибериспытаний на платформе Standoff Bug Bounty. Цель проекта — проверить реальную киберустойчивость компании к самым опасным сценариям атак, включая полный захват управления ИТ-инфраструктурой и получение несанкционированного доступа к системам клиентов. За подтверждение возможности реализации каждого из таких сценариев предусмотрено вознаграждение до 1,5 млн рублей.

Программа рассчитана до конца 2026 года, но может завершиться раньше — если исследователям удастся успешно продемонстрировать одно из двух недопустимых событий.

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

По словам Ивана Булавина, директора по продуктам платформы Standoff 365, формат кибериспытаний позволяет оценивать безопасность не через отдельные уязвимости, а через призму реальных бизнес-рисков.

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

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

Как пояснил Андрей Янкин, директор центра информационной безопасности «Инфосистемы Джет», компания заранее определила для себя наиболее критичные и недопустимые ИТ-сценарии — это полное разрушение ИТ-систем без возможности быстрого восстановления и атаки на клиентов через собственную инфраструктуру. Анализ десятков расследованных инцидентов ИБ за 2025 год показал, что именно такие результаты чаще всего интересуют реальных злоумышленников.

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

RSS: Новости на портале Anti-Malware.ru