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:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED ERRATA	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	unspecified	CC:	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:	2021-10-20 10:42:43 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
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!