Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Date: Fri, 18 Mar 2016 00:20:27 +0100
From: Laël Cellier <>
To: oss-security <>
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)

On 16/03/2016 16:40, Stefan Cornelius wrote:
> Hi,
> I'm Stefan Cornelius of Red Hat Product Security. Obviously, we're
> currently working on the Git security issues.
> In one of the emails to oss-sec you mention that you have some kind of
> reproducer for CVE-2016-2315.
> Would you please be kind enough to share this reproducer with us?
Unfortunately, I can currently only share early work based on a modified 
version of gitdb which can’t create a packfile (Maybe I will be able to 
upload the full gitdb version in a few weeks). You can find it as an 
attachment along an example file.

This email contains a vulnerable version of git with libasan and no optimizations which helped 
me to identify the issue. When I pushed that large repository, libasan 
printed a stack trace which ended on strcpy() in path_name.c (just cat 
2GB.txt in a terminal)

Either way once you have packfile, you need to create a network payload. 
Since my vector was ssh I used the good vim editor on the packfile in 
order to add the missing informations (nul bytes included) (since 
everything is text based outside the packfile).
Doing it manually was much faster than trying to create a script. I 
included an example for ssh which will fill ram if cloned or pushed 
(without doing anything related to the vulnerability). It should help 
demonstrating how to produce one for triggering rce.

For those who don’t want to try it. I included a crafted repo ready for 
use which will crash affected versions. It will help distributions 
testing their own patches.
Of course everything I did was about strcpy() and don’t contains 
executable code (though putting some shoud be easy). For other 
vulnerabilities based on that size_t to int truncation, just ask Peff at 
GitHub, inc. He did is own testing.
> It would help us tremendously. We will not share the reproducer with
> third parties and will only use it for our internal testing.
On the contrary, please make them widely available so other 
distributions can test their own patches faster.
> Thank you very much and kind regards,
The attachments being too large, you can download them on

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.