oss-sec mailing list archives

Re: Exploitability of Git's CVE-2016-2315


From: Laël Cellier <lael.cellier () laposte net>
Date: Wed, 16 Mar 2016 10:17:35 +0100


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 () github 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.


Current thread: