[<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.
