Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed, 16 Mar 2016 02:31:27 +0100
From: Laël Cellier <>
Subject: Re: 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)

Concerning the reply to ᴄᴠᴇ details. (as you can check without the 
quotes, the pgp signature is correct and belong to mitre) (it was 
originally posted on the git‑security mailing list).
> Hash: SHA256
>>>> int nlen = strlen(name); // the size is converted to a positive number
>>>> (the correct size was allocated previously with an unsigned long). I
>>>> got 705804100
>>> (i.e., inconsistent use of signed versus unsigned).
>>> Use CVE-2016-2315.
>> Yes, I think this is really the root of the issue ... It's
>> not just signed versus unsigned, though, but also truncation on 64-bit
>> systems (size_t down to int).
> OK, so more generally CVE-2016-2315 is the issue that "int" is the
> wrong data type for that nlen assignment.
>> Related ... is
>> integer overflow due to a loop which adds more to "len".
>> I think that should potentially have a separate CVE (as it was_not_
>> fixed by 34fa79a6, and in fact there is not a published fix yet).
> Use CVE-2016-2324 for this integer overflow.
> - -- CVE assignment team, MITRE CVE Numbering Authority
> M/S M300
> 202 Burlington Road, Bedford, MA 01730 USA
> [ PGP key available through  ]
> Version: GnuPG v1
> iQIcBAEBCAAGBQJWvN/aAAoJEL54rhJi8gl5uAYP/izpW1/dYi3/UB0FFp3J6iz0
> pOpLy0TgZbfGCvrLAg2xlOxkY8ENEsX1JLKkIwAh0ViaLmKD+4xucgT5DIlpk2fl
> 0eAH8Hxcl2Nn8vOYx5orA6vTJ+S5pVGGSONk448cUDut9F4NBF0ngZ1GnAzQGI1d
> kbvA7aEz9jqUZGcnihoz84DeHwxZAw037MG1Yd/QW0eyHEC9w2fHEVF6GyHxfcMG
> eDowkjefIkmwYlMTbzv9l8v7rc6T7fFSrWe9xYc61rSEkYM5U1Eq2xHEIku6kYQT
> ns+0R+pZgwXakbUe9cJEjHQprGFw0iYtRdBZIDjSeiWZwWBjR9GUkFz/HXo2MdKV
> esN1lpF1x9MqFWjkHlxyCJOEAR1yzClYWU7RodyFeBIfdpc+7BM/I4Mr2b77O+Oi
> hUMBsfbZSPBz0+dBLlijFOBCkf+dvULc6DXM/yBJyYebY8EyUmtvw89u4dXefsZJ
> bvkYw6ltNgXYEovlg+Zp5HDtY5wBeJl/00XRK/Yqtl96Rgmc59jOvnO6j2487cEH
> x4KzwEP7PNDad954iMNQAIv2DLr+6/dGh1LEIoJeWV6kgHR2fM6roY1Ky6Dhc3HS
> BDD/i2d53+Ydej4+xAs7ABe0SRnONPZLvGXfTg1Xf3A1DQ3ctBEU8WTgoDeoNGF1
> 0VRlf18y1csVeTrRhfyX
> =mJKj
But more generally, individual patches are here
And the affected versions are 2.7.0 and below. 2.7.1 is the first 
version which is safe to use. sid, you can relax the 2.7.3 in gitlab
This is the matter of pushing one or several crafted tree objects if the 
target is a server, or making a client cloning a crafted repository 
containing such objects.

Users of gerrit are also affected due to gerrit‑gc (so even probably 
google’s servers). But as the frontend is Jgit, the installed git 
version number is hidden (so the only way is to exploit remote code 
execution). (and this was because wikmedia used gerrit they were 
threat). Because gerrit‑gc rely on git, not on Jgit.

And for fun, a switch to java git might not be a good bet. Because I 
also probably found a server side memory leak in Jgit which can be 
triggered with a simple clone access (which I would be able to confirm 
once that vendor get that 
again (so they can ship it to me, so I can replace the one that died)).

Concerning github, I already told they fixed github enterprise in 
December, and of course they did for the main site at the same time :

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.