The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Опасная уязвимость во всех версиях Git

15.03.2016 23:32

Доступна информация о наличии удалённо эксплуатируемых уязвимостей (CVE-2016-2324 и CVE-2016‑2315) в Git, которые потенциально затрагивают такие системы, как Github, Bitbucket, Gerrit и Gitlab. Проблемы проявляются как на стороне сервера, так и на стороне клиента, и могут привести к выполнению кода атакующего, имеющего доступ к Git-репозиторию. Эксплуатация сводится к инициированию переполнения буфера при выполнении операции push или clone в репозитории, содержащем файл со слишком длинным именем или большим числом вложенных деревьев. Уязвимость устранена в версии 2.7.1 и присутствует во всех более ранних выпусках git (см. дополнение).

Атака может быть совершена на клиента, выполняющего операцию "clone" с сервера, на который могут вносить изменения злоумышленники. Сервер может быть атакован в случае доступа злоумышленников к выполнению команды push (например, публичные git-хостинги). Прототип эксплоита пока не продемонстрирован, возможность его создания обсуждается.

Дополнение: Сообщается, что предложенные патчи не вошли в релиз 2.7.1 и проблема до сих пор проявляется в самом последнем выпуске 2.7.3, т.е. остаётся неисправленной.

  1. Главная ссылка к новости (http://seclists.org/oss-sec/20...)
  2. OpenNews: Выпуск распределенной системы управления исходными текстами Git 2.7.0
  3. OpenNews: Критические уязвимости в GitLab
  4. OpenNews: В Git и Mercurial устранена критическая уязвимость, проявляющаяся в Windows и OS X
  5. OpenNews: Выявлена порция уязвимых SSH-ключей доступа к GitHub
  6. OpenNews: В Git устранено несколько уязвимостей
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/44052-git
Ключевые слова: git
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (27) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Roo2AT7d (ok), 04:12, 16/03/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    > переполнения буфера

    Впрочем, ничего нового.

     
     
  • 2.4, Andrey Mitrofanov (?), 09:47, 16/03/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> переполнения буфера
    > Впрочем, ничего нового.

    Гм, действительно. Соурс-бейзед "удача". Не exim, без регистрации и sms.
    -r--r--r-- 1 2767912 Фев  6 12:11 git_2.7.1-0.1~abm1_i386.deb
    -r--r--r-- 1 9325380 Фев 11 13:15 git-2.7.1-0.0.el6.x86_64.rpm
    https://www.opennet.ru/openforum/vsluhforumID3/106738.html#12

    А! Они перешли к рекламе фикса же. Вот о чём речь.


    | Subject: server and client side remote code execution through a buffer overflow in all git versions before 2.7.1 (unpublished ᴄᴠᴇ-2016-2324 and ᴄᴠᴇ‑2016‑2315)
    Date: [U]Tue, 15 Mar 2016[/U] 15:55:37 +0100

    | On [U]11/02/2016[/U] 16:50, Jeff King wrote this on the git security mailing list:

    | Of course everything Peff talked about above is now fixed in git 2.7.1

    | It seems while this threat is more widespread, it definitely lacks advertisement.
    | So some Peoples suggested me to post about it here.

       +
    Git 2.7.1   [...]   committed Feb 5, 2016
    https://github.com/git/git/commit/a08595f76159b09d57553e37a5123f1091bb13e7

     

  • 1.3, anonymous (??), 08:47, 16/03/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    http://harmful.cat-v.org/software/c++/linus
     
     
  • 2.5, Джо (?), 16:31, 16/03/2016 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Приехали. git на С написан не на С++.
    А С++ как раз лучше защищен от такого переполнения.
    Используя std::string и std::vector прострелить ногу сложнее чем с голыми char* при работе с именами файлов и/или директорий.

     
     
  • 3.11, anonymous (??), 21:49, 16/03/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да ну, правда что ли?
    http://memesmix.net/media/created/kxjc4b.jpg
     
  • 2.14, Вареник (?), 02:16, 17/03/2016 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Торвальдс весьма одиозен, применяя принципы, который хороши для ядра - к чистой прикладухе, которой является Git.

    Результат такого подохода, Git - "лапша" codestyle, набор заплаток и патчей, как изнутри, так и снаружи, с точки дрения пользователя.

     
     
  • 3.15, Вареник (?), 02:24, 17/03/2016 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Собственно его ядро уперлось в то же - скоро будет весить за гигабайт плоского бинарника, полностью состоящего из C-заплаток, в которых невозможно ничего изменить.
     
     
  • 4.22, Аноним (-), 21:39, 17/03/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И при всём этом - это единственное (!) ядро, без вендорских блобов работающее на туевой хуче оборудования, работающее хорошо, и обслуживающее львиную долю серверов Сети.

    Назовите хоть один аналог или альтернативу со сходными характеристиками. Их нет.

     
  • 4.23, llolik (ok), 22:13, 17/03/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Загляни в сорцы винды (вот только не надо делать невинность на лице и говорить, что их нет) и удивись тому, что увидишь всё точно тоже самое, только в куче с плюсами (а в новых ещё и с шарпом).
     

  • 1.6, Дуплик (ok), 16:37, 16/03/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    Нужно Git просто на Java переписать. Там ошибки такого плана вообще невозможны!
     
     
  • 2.8, Аноним (-), 16:59, 16/03/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это к iZENу ;)
     
  • 2.9, Аноним (-), 17:15, 16/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Нужно Git просто на Java переписать.

    Спасибо, уже есть базар и ртуть, если кого тормоза не напрягают.

     
  • 2.10, Аноним (-), 18:04, 16/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    man jgit
     
     
  • 3.18, La235l (?), 17:31, 17/03/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > man jgit

    Yes use java and jgit, and get you hard drive screwed. I found a remote exploitable memory leak in Jgit.
    and that time it don’t require push access. Only read permissions are required.

    Anything that let you handle individual variables directly is terribly wrong (the same is true for loop contructs). More Generally every imperative/reactive programming language is bad.
    The same is true fro computer architectures that behave like this at assembler/binary level https://en.wikipedia.org/wiki/High-level_language_computer_architecture

    The right safe way is to use functional based programming languages.
    Concerning performance Ocaml use native code and is faster than Java and C++

    The same is true for hierarchical database instead of relational ones. The design of filesystem around Folders/files/permission/paths is typicall in databases that were designed 50 years ago (concerning native support of an os without filesystems but relational databases, IBM’s AS/400 is the best partial response that come to my mind).

     
  • 2.19, LA203L (?), 17:45, 17/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Нужно Git просто на Java переписать. Там ошибки такого плана вообще невозможны!

    Java is based on fully imperative languages. It relies on C like syntax (which is a known source of errors) instead of Smaltalk.
    While it removes goto, it doesn’t removes for and while.

    When Security matters programming should at list be done in pure logic https://en.wikipedia.org/wiki/Logic_programming.
    The most well known examples are the injectable sql and the safe Prolog.

     
  • 2.21, La235l (?), 18:05, 17/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Нужно Git просто на Java переписать. Там ошибки такого плана вообще невозможны!

    And does evry jvm programs runs Jazelle ? No, and their own for having security issue.

     
     
  • 3.26, Аноним (-), 23:39, 17/03/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    MGIMO finished?
     
     
  • 4.27, Аноним (-), 10:55, 18/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Ask!
     

  • 1.12, Michael Shigorin (ok), 22:50, 16/03/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    http://www.openwall.com/lists/oss-security/2016/03/16/9
     
     
  • 2.13, Andrey Mitrofanov (?), 23:19, 16/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > http://www.openwall.com/lists/oss-security/2016/03/16/9

    E-e-y-y-e-s-s!! Ж)))

     

  • 1.16, Аноним (-), 12:38, 17/03/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    >C
    >переполнения буфера

    что-то новое

     
     
  • 2.24, Аноним (-), 22:41, 17/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Берешь более-менее новые gcc или clang и собираешь все с -fsanitize=address, правда скорость работы просядет. Сделать яву можно и из сишечки, было бы желание.
     

  • 1.17, Genby (?), 12:45, 17/03/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    C, оказывается, недостаточно объектный, чтобы автоматически следить за буферами... какая неожиданность...

    и дальше и дальше будут появляться подобные ошибки, пока крикливые кони не поймут, что использовать Си для прикладного ПО - это, мягко говоря, глупо!

     
     
  • 2.20, LA203L (?), 17:59, 17/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > C, оказывается, недостаточно объектный, чтобы автоматически следить за буферами... какая
    > неожиданность...
    > и дальше и дальше будут появляться подобные ошибки, пока крикливые кони не
    > поймут, что использовать Си для прикладного ПО - это, мягко говоря,
    > глупо!

    Not relly, C is the best answer for speed/memory after assembly.

    Laël

     
  • 2.25, Аноним (-), 22:49, 17/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > C, оказывается, недостаточно объектный, чтобы автоматически следить за буферами...

    Слежение за буферами запилено в gcc 4.9 где-то, и clang 3.6 или 3.7. Только оно скорость просаживает, как и везде, поэтому позиционируется как отладочная фича.

     

  • 1.28, Аноним (-), 14:49, 19/03/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    За счет объектов в плюсах можно следить за границами где надо и контролировать типы как надо, а не передавать в функцию адрес указателя на буфер вместо самого буфера. А за счет шаблонов можно сделать вещи гораздо более крутые, чем на макросах в сях, которые оптимизируются в компайлтайм, заинлайнятся и свернутся в несколько асёмблерных инструкций. И все это с контролем типов. А сишники пусть продолжают передавать данные через void* и выяснять тип if'ами в рантайме. Зато труЪ.
     
     
  • 2.29, Аноним (-), 14:55, 19/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Вот, к примеру, как сдвиги и повороты сделанные в c++ сворачиваются в 4 ассемблерные инструкции функции f(), если не считать ret https://goo.gl/yColR5
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру