В 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 баллов по программе обнаружения уязвимостей.

AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

Магнит и Avanpost внедрили систему для управления сертификатами ЭП

Розничная сеть «Магнит» совместно с Avanpost завершила проект по внедрению централизованной системы управления сертификатами электронной подписи и средствами криптографической защиты. Решение позволяет автоматизировать выпуск, продление и перевыпуск сертификатов, которые используются, в частности, для работы с ЕГАИС в торговых точках.

По данным компаний, система охватывает более 20 тысяч объектов сети на территории европейской части России и помогает снизить риски простоев при учёте и продаже алкоголя.

Под управление платформы было взято около 30 тысяч средств защиты информации, а агенты системы развернули на более чем 20 тысяч рабочих мест.

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

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

В рамках проекта Avanpost PKI интегрировали с основными корпоративными системами, включая 1С, Active Directory, КриптоПро, СМЭВ, HR MDM, а также с SIEM- и SOAR-платформами для мониторинга событий безопасности.

Срок реализации проекта — 2024-2025 годы.

Мария Дордий, руководитель отдела СКЗИ в «Магните», так описывает результаты:

«Проект по автоматизации выпуска электронных подписей в нашей розничной сети был направлен на повышение контроля, прозрачности и безопасности операций с ЭП и СКЗИ. Благодаря внедрению системы Avanpost PKI мы решили важнейшие задачи: централизовали управление СЗИ, СКЗИ и сертификатами и сократили время получения электронной подписи для наших сотрудников. Мы реализовали автоматизированные процессы одиночного и массового перевыпуска сертификатов, что критически важно для нашей масштабной сети с учетом разницы часовых поясов РФ и позволяет системе перевыпускать 1000 и более сертификатов в день. Снижение времени на получение и оперативный перевыпуск ЭП нивелирует риски простоя касс и продаж на торговых объектах. Кроме того, сотрудники получили удобный личный кабинет, позволяющий дистанционно контролировать сроки действия и обновлять сертификат. Создание гибкой ролевой модели доступа, формирование бизнес-процессов согласования, ведение журналов событий и аудит инцидентов ИБ позволили нам соблюсти требования регуляторов и контролировать нелегитимные операции, значительно повысив информационную безопасность».

Евгений Галкин, директор продуктовых направлений кибербезопасности и криптографии Avanpost, отметил:

«Автоматизация управления сертификатами для 20000 торговых объектов „Магнит“ — это по-настоящему масштабный и, что важно, уникальный для России проект. Совместно с коллегами из "Магнита" нам удалось создать централизованную систему, способную управлять сертификатами, обеспечивая их выпуск, установку на устройстве клиента с агентом Avanpost PKI, аннулирование, обновление по истечению срока и массовый перевыпуск. Мы гордимся, что построили такую систему на федеральном масштабе и фактически устранили риск остановки продаж алкоголя из-за просроченных сертификатов. В таком объеме и с такой степенью автоматизации наше решение является эксклюзивным на рынке, что подтверждает наше технологическое лидерство в сфере ретейла».

AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

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