Доступна (http://seclists.org/oss-sec/2016/q1/645) информация о наличии удалённо эксплуатируемых уязвимостей (CVE-2016-2324 (https://security-tracker.debian.org/tracker/CVE-2016-2324) и CVE-2016‑2315 (https://security-tracker.debian.org/tracker/CVE-2016-2315)) в Git. Проблемы проявляются как на стороне сервера, так и на стороне клиента, и могут привести (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-2315) к выполнению кода атакующего, имеющего доступ к Git-репозиторию. Эксплуатация сводится к инициированию переполнения буфера при выполнении операции push или clone в репозитории, содержащем файл со слишком длинным именем или большим числом вложенных деревьев. Уязвимость устранена в версии 2.7.1 и присутствует во всех более ранних выпусках git.
URL: http://seclists.org/oss-sec/2016/q1/645
Новость: http://www.opennet.me/opennews/art.shtml?num=44052
> переполнения буфераВпрочем, ничего нового.
>> переполнения буфера
> Впрочем, ничего нового.Гм, действительно. Соурс-бейзед "удача". Не 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
http://www.opennet.me/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/a08595f76159b09d57553e37a5...
http://harmful.cat-v.org/software/c++/linus
Приехали. git на С написан не на С++.
А С++ как раз лучше защищен от такого переполнения.
Используя std::string и std::vector прострелить ногу сложнее чем с голыми char* при работе с именами файлов и/или директорий.
Да ну, правда что ли?
http://memesmix.net/media/created/kxjc4b.jpg
Торвальдс весьма одиозен, применяя принципы, который хороши для ядра - к чистой прикладухе, которой является Git.Результат такого подохода, Git - "лапша" codestyle, набор заплаток и патчей, как изнутри, так и снаружи, с точки дрения пользователя.
Собственно его ядро уперлось в то же - скоро будет весить за гигабайт плоского бинарника, полностью состоящего из C-заплаток, в которых невозможно ничего изменить.
И при всём этом - это единственное (!) ядро, без вендорских блобов работающее на туевой хуче оборудования, работающее хорошо, и обслуживающее львиную долю серверов Сети.Назовите хоть один аналог или альтернативу со сходными характеристиками. Их нет.
Загляни в сорцы винды (вот только не надо делать невинность на лице и говорить, что их нет) и удивись тому, что увидишь всё точно тоже самое, только в куче с плюсами (а в новых ещё и с шарпом).
Нужно Git просто на Java переписать. Там ошибки такого плана вообще невозможны!
Это к iZENу ;)
> Нужно Git просто на Java переписать.Спасибо, уже есть базар и ртуть, если кого тормоза не напрягают.
man jgit
> man jgitYes 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_a...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).
> Нужно 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.
> Нужно Git просто на Java переписать. Там ошибки такого плана вообще невозможны!And does evry jvm programs runs Jazelle ? No, and their own for having security issue.
MGIMO finished?
Ask!
http://www.openwall.com/lists/oss-security/2016/03/16/9
> http://www.openwall.com/lists/oss-security/2016/03/16/9E-e-y-y-e-s-s!! Ж)))
>C
>переполнения буферачто-то новое
Берешь более-менее новые gcc или clang и собираешь все с -fsanitize=address, правда скорость работы просядет. Сделать яву можно и из сишечки, было бы желание.
C, оказывается, недостаточно объектный, чтобы автоматически следить за буферами... какая неожиданность...и дальше и дальше будут появляться подобные ошибки, пока крикливые кони не поймут, что использовать Си для прикладного ПО - это, мягко говоря, глупо!
> C, оказывается, недостаточно объектный, чтобы автоматически следить за буферами... какая
> неожиданность...
> и дальше и дальше будут появляться подобные ошибки, пока крикливые кони не
> поймут, что использовать Си для прикладного ПО - это, мягко говоря,
> глупо!Not relly, C is the best answer for speed/memory after assembly.
Laël
> C, оказывается, недостаточно объектный, чтобы автоматически следить за буферами...Слежение за буферами запилено в gcc 4.9 где-то, и clang 3.6 или 3.7. Только оно скорость просаживает, как и везде, поэтому позиционируется как отладочная фича.
За счет объектов в плюсах можно следить за границами где надо и контролировать типы как надо, а не передавать в функцию адрес указателя на буфер вместо самого буфера. А за счет шаблонов можно сделать вещи гораздо более крутые, чем на макросах в сях, которые оптимизируются в компайлтайм, заинлайнятся и свернутся в несколько асёмблерных инструкций. И все это с контролем типов. А сишники пусть продолжают передавать данные через void* и выяснять тип if'ами в рантайме. Зато труЪ.
Вот, к примеру, как сдвиги и повороты сделанные в c++ сворачиваются в 4 ассемблерные инструкции функции f(), если не считать ret https://goo.gl/yColR5