В 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, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

Сбер готов делиться технологиями автоматического выявления дипфейков

Заместитель Председателя Правления Сбербанка Станислав Кузнецов заявил, что Сбер готов предоставлять свои технологии автоматического выявления дипфейков другим участникам рынка. Об этом он рассказал на форуме «Диалог о фейках 3.0» во время панельной дискуссии «Глобальный диалог: обеспечение цифрового суверенитета в условиях многополярности».

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

При этом дипфейки всё чаще применяются в мошеннических схемах, включая телефонное мошенничество и кражу денег.

«Если ещё в 2024 году преступники использовали базы данных, то теперь они запускают ИИ-агентов, которые сами находят нужную информацию. В основе таких преступлений — кибермистификация, когда ложь маскируется под правду с помощью технологий», — отметил Кузнецов.

Он подчеркнул, что для эффективной борьбы с дипфейками необходимо решить три ключевые задачи:

  1. Законодательно урегулировать их использование, в том числе признать применение дипфейков отягчающим обстоятельством при совершении преступлений.
  2. Развивать технологии быстрого выявления фейков и не допускать их распространения.
  3. Интегрировать системы распознавания дипфейков в массовые сервисы — смартфоны, ТВ, соцсети, мессенджеры и операторы связи.

Во время дискуссии Кузнецов продемонстрировал, как с помощью современных инструментов можно в реальном времени “надеть” лицо другого человека и заставить его говорить нужные слова. Он подчеркнул, что подобные возможности представляют серьёзную угрозу — от кражи личности до дискредитации публичных фигур.

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

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

Он добавил, что масштабное внедрение подобных систем может стать переломным моментом в борьбе с распространением дипфейков и повысить доверие к цифровому контенту.

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

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