[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <0c221798-c6e3-962d-ae71-fb143223eda1@laposte.net>
Date: Wed, 16 Mar 2016 02:31:27 +0100
From: Laël Cellier <lael.cellier@...oste.net>
To: oss-security@...ts.openwall.com
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).
> -----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
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.
