Bug 1046227 - (CVE-2013-7203) CVE-2013-7203 gitolite: world writable files for fresh installs
CVE-2013-7203 gitolite: world writable files for fresh installs
Status: NEW
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=low,public=20131223,reported=2...
: Security
Depends On: 1046228 1046230 1046231 1046232
Blocks:
  Show dependency treegraph
 
Reported: 2013-12-24 02:03 EST by Ratul Gupta
Modified: 2015-07-31 03:14 EDT (History)
3 users (show)

See Also:
Fixed In Version: gitolite 3.5.3.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ratul Gupta 2013-12-24 02:03:06 EST
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.

References:
http://seclists.org/oss-sec/2013/q4/542
Comment 1 Ratul Gupta 2013-12-24 02:05:00 EST
Created gitolite tracking bugs for this issue:

Affects: fedora-all [bug 1046228]
Affects: epel-all [bug 1046231]
Comment 2 Ratul Gupta 2013-12-24 02:05:04 EST
Created gitolite3 tracking bugs for this issue:

Affects: fedora-19 [bug 1046230]
Affects: epel-6 [bug 1046232]
Comment 3 Gwyn Ciesla 2013-12-24 09:15:37 EST
This is fixed in gitolite3 3.5.3.1, 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?
Comment 4 Vincent Danen 2013-12-24 10:46:55 EST
The patch to correct this is here:

https://github.com/sitaramc/gitolite/commit/3dad4f8e3214d6ab5f71823019a624fa48b055a3

with further discussion here:

https://groups.google.com/forum/#!topic/gitolite/Tu1sjaf7A4A/discussion

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.)
Comment 5 Gwyn Ciesla 2013-12-24 10:47:49 EST
Ok, thanks!

Note You need to log in before you can comment on or make changes to this bug.