Re: [SECURITY] [DSA 1637-1] New git-core packages fix buffer overflow

[Dmitry Potapov <dpotapov@gmail.com>]

Hello Debian Security Team,

On Mon, Sep 15, 2008 at 07:38:47AM +0000, Devin Carraway wrote:
> 
> - ------------------------------------------------------------------------
> Debian Security Advisory DSA-1637-1                  security@debian.org
> http://www.debian.org/security/                           Devin Carraway
> September 15, 2008                    http://www.debian.org/security/faq
> - ------------------------------------------------------------------------
> 
> Package        : git-core
> Vulnerability  : buffer overflow
> Problem type   : local (remote)
> Debian-specific: no
> CVE Id(s)      : CVE-2008-3546
> Debian Bug     : 494097
> 
> Multiple vulnerabilities have been identified in git-core, the core of
> the git distributed revision control system.  Improper path length
> limitations in git's diff and grep functions, in combination with
> maliciously crafted repositories or changes, could enable a stack
> buffer overflow and potentially the execution of arbitrary code.
> 
> The Common Vulnerabilities and Exposures project identifies this
> vulnerabilitiy as CVE-2008-3546.
> 
> For the stable distribution (etch), this problem has been fixed in
> version 1.4.4.4-2.1+etch1.

I believe that a stack buffer overflow in git-grep is not fixed.
Here is the patch:
http://repo.or.cz/w/git.git?a=commitdiff;h=620e2bb93785ed8eb60846d94fd4753d4817c8ec
The Debian Bug report mentions it, but somehow it was not applied
to 1.4.4.4-2.1+etch1. I have downloaded sources and still can see
that the grep_tree function contains the following line:
   strcpy(path_buf + len, entry.path);
This line causes a stack buffer overflow if entry.path is longer
than PATH_MAX.

BTW, there is another related fix:
http://repo.or.cz/w/git.git?a=commitdiff;h=7fec10b7f41fa32e71aa6377bd04cd7c6fb419e0

The comment to it says "we are mostly protected by the fact that many
codepaths first copy the path in a variable of size PATH_MAX, which
typically is 4096." But mostly does not mean every situation, and IIRC,
Git did crash being given too long name (probably memory corruption).
Actually, another reason why I mention this patch, it includes a test
case, which demonstrates a simple way how to create Git repository with
names longer than PATH_MAX. I used that method to find aforementioned
bugs in diff and grep functions as well to test my patches.

Hopefully, this information will be useful.

Thanks,
Dmitry