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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ