The OpenNET Project / Index page

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

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

Доступна информация о наличии удалённо эксплуатируемых уязвимостей (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
Тип: Проблемы безопасности
Ключевые слова: git
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Ajax/Линейный | Раскрыть все сообщения | 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][B]Tue, 15 Mar 2016[/B][/U] 15:55:37 +0100

    | On [U][B]11/02/2016[/B][/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 на С написан не на С А С как раз лучше защищен от такого пер... весь текст скрыт [показать]
     
     
  • 3.11, anonymous (??), 21:49, 16/03/2016 [^] [ответить]    [к модератору]  
  • –1 +/
    Да ну, правда что ли?
    http://memesmix.net/media/created/kxjc4b.jpg
     
  • 2.14, Вареник (?), 02:16, 17/03/2016 [^] [ответить]     [к модератору]  
  • –5 +/
    Торвальдс весьма одиозен, применяя принципы, который хороши для ядра - к чистой ... весь текст скрыт [показать]
     
     
  • 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 [^] [ответить]     [к модератору]  
  • +/
    Слежение за буферами запилено в gcc 4 9 где-то, и clang 3 6 или 3 7 Только оно ... весь текст скрыт [показать]
     
  • 1.28, Аноним (-), 14:49, 19/03/2016 [ответить] [показать ветку] [···]     [к модератору]  
  • +/
    За счет объектов в плюсах можно следить за границами где надо и контролировать т... весь текст скрыт [показать]
     
     
  • 2.29, Аноним (-), 14:55, 19/03/2016 [^] [ответить]    [к модератору]  
  • +/
    Вот, к примеру, как сдвиги и повороты сделанные в c++ сворачиваются в 4 ассемблерные инструкции функции f(), если не считать ret https://goo.gl/yColR5
     

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


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