Re: Stack read out-of-bounds in parse_sha1_header_extended using git 2.10.0

From: Jeff King <peff@peff.net>
Date: Sep 27, 2016, 07:19 UTC
Message-ID: <20160927071936.5hneqhv22zw73asy@sigill.intra.peff.net>
In-Reply-To: <xmqqtwd2sf9t.fsf@gitster.mtv.corp.google.com>

On Mon, Sep 26, 2016 at 11:10:54AM -0700, Junio C Hamano wrote:

Show 17 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
> 
> > I am inclined to say that it has no security implications.  You have
> > to be able to write a bogus loose object in an object store you
> > already have write access to in the first place, in order to cause
> > this ...
> 
> Note that you could social-engineer others to fetch from you and
> feed a small enough update that results in loose objects created in
> their repositories, without you having a direct write access to the
> repository.
> 
> The codepath under discussion in this thread however cannot be used
> as an attack vector via that route, because the "fetch from
> elsewhere" codepath runs verification of the incoming data stream
> before storing the results (either in loose object files, or in a
> packfile) on disk.

I don't think it could be used at all for anything that speaks the git protocol, because the object header is not present at all in a packfile. So even if you hit unpack-objects, it would be writing the (correct) loose object header itself.

But when we grab loose objects _directly_ from a remote, as in dumb-http fetch, I'd suspect that the code doing the verification calls unpack_sha1_header() as part of it. So I didn't test, but I'd strongly suspect that's a viable attack vector.

I'm not sure what the actual attack would look like, though, aside from locally accessing memory in a read-only way.

-Peff