Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <c82384d8-0058-ae6b-81ee-b4b8d35ad22b@laposte.net>
Date: Wed, 16 Mar 2016 10:17:35 +0100
From: Laël Cellier <lael.cellier@...oste.net>
To: Chris Williams <cwilliams@...pub.com>, oss-security@...ts.openwall.com
Subject: Re: Exploitability of Git's CVE-2016-2315


> Hi Laël,
>
> Congrats on the GitHub bounty for the Git bug. I have a quick question about CVE-2016-2315: is it feasibly exploitable? Do you have to push a very large repository with very long strings to overflow the signed integer in path_name()?
>
> Many thanks,
>
> C.
>
Yes, you have to create a repository path which is larger than 2³¹.

However, you have the control at what place the remote code execution 
should happen in the buffer. git objects are zlib compressed and git 
Servers tend to allow downloading over https or (even better ssh) which 
use zlib compression. This allow compress data twice (compressing a 
second time tend to be efficient in zlib if the data is well compressible).

If you find well zlib compressible data which you can combine with 
assembly, you’ll probably be able to reduce network data to 
200Mb. GitHub told they change their message if they could run the proof 
on 
https://github-enterprise.s3.amazonaws.com/hyperv/releases/github-enterprise-2.4.1.vhd 
or 
https://github-enterprise.s3.amazonaws.com/kvm/updates/github-enterprise-kvm-2.4.1.pkg 
or 
https://github-enterprise.s3.amazonaws.com/kvm/releases/github-enterprise-2.4.1.qcow2 
or 
https://github-enterprise.s3.amazonaws.com/esx/releases/github-enterprise-2.4.1.ova 
or 
https://github-enterprise.s3.amazonaws.com/xen/releases/github-enterprise-2.4.1.vhd

I used python gitdb to confirm the server side memory corruption. This 
allowed me to leverage the bug.
However, without a push command I can use, I had to build an ssh network 
payload from the generated packfile (the ꜱꜱʜ protocol is simpler than 
the ʜᴛᴛᴘꜱ one) that I could use with
ssh -C -o compressionlevel=9 git@...hub.com git-receive-pack the/repo.git

Creating an ʜᴛᴛᴘꜱ version should possible, however curl doesn’t know 
about ʜᴛᴛᴘ compression for uploading. So this require to pre compress 
the payload and trick ʜᴛᴛᴘ headers

The git:// protocol doesn’t support compression, so only the packfile 
compression remains.

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.