Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 577482 (CVE-2016-2315) - <dev-vcs/git-2.7.3-r1: buffer overflow (CVE-2016-2315)
Summary: <dev-vcs/git-2.7.3-r1: buffer overflow (CVE-2016-2315)
Status: RESOLVED FIXED
Alias: CVE-2016-2315
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Security
URL: http://www.openwall.com/lists/oss-sec...
Whiteboard: B2 [glsa cve]
Keywords:
Depends on:
Blocks:
 
Reported: 2016-03-15 15:13 UTC by Agostino Sarubbo
Modified: 2017-02-14 19:07 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Agostino Sarubbo gentoo-dev 2016-03-15 15:13:46 UTC
From ${URL} :

> The problem you describe is one where the size of the allocation does
> not match what strcpy would write. And that's kind-of fixed by moving to
> memcpy() in 34fa79a6, because at least now the initial value of "len"
> matches the number of bytes we write (so that number might be totally
> bogus, but we don't write more than we allocate).
>
> But "len" can also change after the fact, due to the loop. If you have a
> sequence of path components, each less than 2^31, they can sum to a much
> smaller positive value due to integer overflow (e.g., A/B/C with lengths
> A=2^31-5, B=2^31-5, C=20 would yield len=10). Then the buffer is too
> small to fit C, let alone all of the extra components we insert in the
> second loop.
>
> The fix I came up with for this is to convert all of the "int" variables
> here to "size_t". That doesn't actually _fix_ the problem at all, but
> does mean on a 64-bit system that you need a 2^64-long path to trigger
> it, which is impractical. But that doesn't help 32-bit systems (though
> in practice, I wouldn't be surprised if we barf long before that, as we
> would be unable to hold the "struct name_path" list in memory).
>
> Note that there is also a similar problem in tree-diff.c's
> path_appendnew().  There we build up the full pathname in a strbuf,
> which checks for overflow. But we then pass that length as an int and
> allocate a FLEX_ARRAY struct with it, which can end up too-small. This
> one is the more interesting of the two, I think, as it triggers via
> git-log, whereas the path_name() happens only during a repack (so it
> will hit you _eventually_, but probably not as soon as you've cloned).
>
> My solution there was similar: use size_t, which at least means you'd
> have to allocate petabytes on a 64-bit system to trigger it (much less
> on a 32-bit system, but _probably_ you'd be saved by malloc failing
> first).
>
> And that's why I dragged my feet on sending those fixes upstream; I
> don't think they're complete. The complete fix would be to use size_t
> consistently to store return values for strlen(), and to do integer
> overflow checks whenever we do computations on size_t.
>
> Those of you on this list may recall I posted a series for the latter
> last year, but it was somewhat invasive. It may be worth resurrecting.
>
> I think we could also get rid of path_name() entirely. The sole purpose
> at this point is to compute the name-hash for pack-objects, which could
> be done by walking the name_path list rather than re-constructing the
> whole thing in memory.

Fixed in 2.7.1


@maintainer(s): since the fixed package is already in the tree, please let us know if it is ready for the stabilization or not.
Comment 1 Lars Wendler (Polynomial-C) gentoo-dev 2016-03-15 15:24:29 UTC
I'd go with =dev-vcs/git-2.7.3 but that's up for Robin to decide...
Comment 2 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2016-03-15 19:07:55 UTC
+1 to stable 2.7.3
Comment 3 Aaron Bauman Gentoo Infrastructure gentoo-dev Security 2016-03-15 23:12:58 UTC
@arches, please stabilize dev-vcs/git-2.7.3

TARGET KEYWORDS = alpha, amd64, arm, hppa, ia64, ppc64, ppc, sparc, x86, arm64, s390, sh
Comment 4 Agostino Sarubbo gentoo-dev 2016-03-16 10:59:08 UTC
amd64 stable
Comment 5 Agostino Sarubbo gentoo-dev 2016-03-16 11:01:01 UTC
x86 stable
Comment 6 Agostino Sarubbo gentoo-dev 2016-03-16 12:08:59 UTC
ppc stable
Comment 7 Hanno Böck gentoo-dev 2016-03-16 13:20:12 UTC
There just was a message to oss-security that 2.7.3 actually does not contain the fix:
http://www.openwall.com/lists/oss-security/2016/03/16/9

The post links to patches, not sure when git will make a new release, maybe they should be backported to our ebuild.
Comment 8 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2016-03-16 19:07:34 UTC
@hanno:
I'm running the testsuite on the backported patch now; if it passes I'll push an -r1 and we can restart stable.
Comment 9 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2016-03-16 20:32:51 UTC
@hanno: backported now.

@arches, please stabilize dev-vcs/git-2.7.3-r1

TARGET KEYWORDS = alpha, amd64, arm, hppa, ia64, ppc64, ppc, sparc, x86, arm64, s390, sh

Apologies for the second round of stablization; upstream didn't actually have the fix in 2.7.3.
Comment 10 Agostino Sarubbo gentoo-dev 2016-03-17 10:02:30 UTC
 Stable for alpha/amd64/arm/ia64/ppc/ppc64/sparc/x86
Comment 11 ytrezq 2016-03-17 11:56:44 UTC
Remember due the nature of the bug, it might be impossible to trigger ʀᴄᴇ on big endian machines.
Comment 12 ytrezq 2016-03-17 12:56:38 UTC
So such architectures might be safe.
Comment 13 Oleh 2016-03-18 10:23:36 UTC
New versions of git available: 2.4.11, 2.5.5,  2.6.6, 2.7.4 which should have this security bug fixed, i.e no backports needed.
Comment 14 Jeroen Roovers (RETIRED) gentoo-dev 2016-03-20 10:22:01 UTC
Stable for HPPA.
Comment 15 Aaron Bauman Gentoo Infrastructure gentoo-dev Security 2016-03-25 13:04:40 UTC
@maintainers, please cleanup vulnerable versions.  Thank you.
Comment 16 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2016-03-26 01:27:21 UTC
cleanup done
Comment 17 GLSAMaker/CVETool Bot gentoo-dev 2016-05-02 19:40:09 UTC
This issue was resolved and addressed in
 GLSA 201605-01 at https://security.gentoo.org/glsa/201605-01
by GLSA coordinator Kristian Fiskerstrand (K_F).
Comment 18 Thomas Deutschmann gentoo-dev Security 2017-02-14 19:07:53 UTC
Fixing alias encoding.