Bug 1046227 (CVE-2013-7203) - CVE-2013-7203 gitolite: world writable files for fresh installs
Summary: CVE-2013-7203 gitolite: world writable files for fresh installs
Keywords:
Status: NEW
Alias: CVE-2013-7203
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1046228 1046230 1046231 1046232
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-24 07:03 UTC by Ratul Gupta
Modified: 2019-09-29 13:11 UTC (History)
3 users (show)

Fixed In Version: gitolite 3.5.3.1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)

Description Ratul Gupta 2013-12-24 07:03:06 UTC
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 07:05:00 UTC
Created gitolite tracking bugs for this issue:

Affects: fedora-all [bug 1046228]
Affects: epel-all [bug 1046231]

Comment 2 Ratul Gupta 2013-12-24 07:05:04 UTC
Created gitolite3 tracking bugs for this issue:

Affects: fedora-19 [bug 1046230]
Affects: epel-6 [bug 1046232]

Comment 3 Gwyn Ciesla 2013-12-24 14:15:37 UTC
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 15:46:55 UTC
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 15:47:49 UTC
Ok, thanks!


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