Red Hat Bugzilla – Bug 1046227
CVE-2013-7203 gitolite: world writable files for fresh installs
Last modified: 2015-07-31 03:14:14 EDT
Gitolite was found to be vulnerable to local filesystem information leak, where it could create world writable files in the repositories (particularly the gitolite-admin one) depending on the user umask running gitolite setup.
Created gitolite tracking bugs for this issue:
Affects: fedora-all [bug 1046228]
Affects: epel-all [bug 1046231]
Created gitolite3 tracking bugs for this issue:
Affects: fedora-19 [bug 1046230]
Affects: epel-6 [bug 1046232]
This is fixed in gitolite3 188.8.131.52, which is on it's way everywhere it wasn't.
For gitolite, I think the packaging attrs take care of this in all branches. Can you comfirm?
The patch to correct this is here:
with further discussion here:
which in particular states:
"If you *are* affected, (i.e., you did a fresh install of gitolite
between fa06a34 and v3.5.3), merely upgrading will NOT fix the problem,
and you *must* do a one-time chmod fixup as described below. "
the chmod fixup is noted in the workaround section (which is probably useful information to have put here...)
- EXISTING INSTALLS: if it affects you (see next section for details),
you need to do a one-time 'chmod -R go-rwx' (or such) on
~/.gitolite.rc, ~/.gitolite, and ~/repositories/gitolite-admin.git
Finally, the commit that introduced this was fa06a34, which set the umask as early as possible and was committed on September 3 2013 (https://github.com/sitaramc/gitolite/commit/fa06a34) and as a result earlier versions are _NOT_ affected.
Given that gitolite 2.3.1 was released in early 2012, it's not affected.
(As an aside, please don't change the status on SRT bugs; they stay NEW until they are CLOSED. Thanks.)