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)

[Laël Cellier <lael.cellier () laposte net>]

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).
> -----BEGIN PGP SIGNED MESSAGE-----
> 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 throughhttp://cve.mitre.org/cve/request_id.html  ]
> -----BEGIN PGP SIGNATURE-----
> 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
> -----END PGP SIGNATURE-----
But more generally, individual patches are here 
http://thread.gmane.org/gmane.comp.version-control.git/286253
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 
http://www.materiel.net/carte-reseau/intel-dual-band-wireless-ac-7260-desktop-7260hmwdtx1-r-114087.html 
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 : 
https://bounty.github.com