Bug 1046227 (CVE-2013-7203)

Summary: CVE-2013-7203 gitolite: world writable files for fresh installs
Product: [Other] Security Response Reporter: Ratul Gupta <ratulg>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: NEW --- QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: gwync, lkundrak, opensource
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
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: --- Target Upstream Version:
Bug Depends On: 1046228, 1046230, 1046231, 1046232    
Bug Blocks:    

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!