Исследователь Лаел Целлье (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:
В коде хорошо просматривается уязвимость CVE-2016-2315. Из приведенного отрывка видно, что если strlen() будет работать с излишне длинным именем файла и получится излишне большое число, это закончится переполнением для nlen, из-за чего значение получится отрицательным, а не положительным. Из-за этого len тоже станет отрицательным, и памяти, запрошенной xmalloc(), может не хватить для итоговой комбинированной строки,
Функция 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 баллов по программе обнаружения уязвимостей.
Российские операторы связи обсуждают с властями возможность открыть пользователям доступ к зарубежным сервисам, которые формально не заблокированы в России, но всё равно недоступны без VPN. Об этом на полях ПМЭФ рассказал генеральный директор «Билайна» Сергей Анохин.
По его словам, идея так называемых белых списков VPN, которую он ранее озвучивал публично, получила поддержку и теперь развивается дальше. Впрочем, речь идёт уже не совсем о VPN.
Как пояснил Анохин, операторы предлагают дать пользователям возможность напрямую открывать отдельные зарубежные сервисы, не прибегая к обходным инструментам. В качестве примеров он назвал Netflix и популярные нейросети.
«Есть сервисы, которые не подпали под ограничения со стороны Роскомнадзора за неисполнение российского законодательства, но приняли решение не работать в России. Например, ряд развлекательных сервисов, тот же Netflix, нейронные сети. Они востребованы российскими пользователями, но, чтобы ими пользоваться, нужен VPN», — отметил глава «Билайна».
Анохин считает, что у операторов есть понимание, как технически реализовать подобный механизм.
Если идея будет одобрена, может появиться своеобразный список зарубежных сервисов, доступ к которым российские пользователи смогут получать без VPN, несмотря на действующие географические ограничения со стороны самих площадок.
Фактически речь идёт о попытке решить парадоксальную ситуацию, когда сервис не запрещён российскими властями, но воспользоваться им всё равно нельзя без дополнительных инструментов.
Впрочем, до практической реализации пока далеко. Никаких сроков, перечня сервисов или технических деталей участники обсуждения не раскрывают.
Свидетельство о регистрации СМИ ЭЛ № ФС 77 - 68398, выдано федеральной службой по надзору в сфере связи, информационных технологий и массовых коммуникаций (Роскомнадзор) 27.01.2017 Разрешается частичное использование материалов на других сайтах при наличии ссылки на источник. Использование материалов сайта с полной копией оригинала допускается только с письменного разрешения администрации.
