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

Создана квантовая линия связи, передающая ключи на большие расстояния

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

Результаты исследования группа под руководством профессора Научно-технологического университета Китая в Хэфэе Паня Цзяньвэя опубликовала в журнале Science.

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

Использование такой схемы позволило увеличить соотношение сигнал/шум более чем в 1500 раз по сравнению с существующими подходами. В результате дальность передачи криптографических ключей удалось увеличить на три порядка — до сотен километров.

«Мы продемонстрировали возможность работы систем квантового распределения ключей на “междугородних” расстояниях. Это сокращает разрыв между экспериментальными разработками квантово-защищенных сетей и их практическим применением. Кроме распределения ключей, данный подход может использоваться для создания генераторов случайных чисел и проведения фундаментальных исследований в области квантовой механики», — отметили авторы работы.

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

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