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.
I'd go with =dev-vcs/git-2.7.3 but that's up for Robin to decide...
+1 to stable 2.7.3
@arches, please stabilize dev-vcs/git-2.7.3 TARGET KEYWORDS = alpha, amd64, arm, hppa, ia64, ppc64, ppc, sparc, x86, arm64, s390, sh
amd64 stable
x86 stable
ppc stable
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.
@hanno: I'm running the testsuite on the backported patch now; if it passes I'll push an -r1 and we can restart stable.
@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.
Stable for alpha/amd64/arm/ia64/ppc/ppc64/sparc/x86
Remember due the nature of the bug, it might be impossible to trigger ʀᴄᴇ on big endian machines.
So such architectures might be safe.
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.
Stable for HPPA.
@maintainers, please cleanup vulnerable versions. Thank you.
cleanup done
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).
Fixing alias encoding.
