Bug 24210 - gitolite new security issue CVE-2018-20683
Summary: gitolite new security issue CVE-2018-20683
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 6
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
Whiteboard: MGA6-64-OK
Keywords: advisory, validated_update
Depends on:
Reported: 2019-01-19 17:47 CET by David Walser
Modified: 2019-01-31 23:56 CET (History)
6 users (show)

See Also:
Source RPM: gitolite-3.6.10-1.mga7.src.rpm
Status comment:


Description David Walser 2019-01-19 17:47:36 CET
openSUSE has issued an advisory on January 18:

The issue is fixed upstream in 3.6.11.

Mageia 6 is also affected.
David Walser 2019-01-19 17:47:57 CET

Whiteboard: (none) => MGA6TOO
CC: (none) => bruno

Comment 1 David Walser 2019-01-19 21:31:07 CET
gitolite-3.6.11-1.mga7 uploaded for Cauldron by Shlomi.

Version: Cauldron => 6
Whiteboard: MGA6TOO => (none)

Comment 2 Shlomi Fish 2019-01-20 11:26:04 CET
I submitted it to 6/updates-testing: http://pkgsubmit.mageia.org/
Comment 3 David Walser 2019-01-20 16:22:39 CET

Updated gitolite package fixes security vulnerability:

In commands/rsync in Gitolite before 3.6.11, if .gitolite.rc enables rsync,
mishandles the rsync command line, which allows attackers to have a "bad"
impact by triggering use of an option other than -v, -n, -q, or -P


Updated packages in core/updates_testing:

from gitolite-3.6.11-1.mga6.src.rpm

CC: (none) => shlomif
Assignee: shlomif => qa-bugs

Comment 4 Herman Viaene 2019-01-23 15:46:14 CET
MGA6-32 MATE on IBM Thinkpad R50e
No installation issues at first.
Ref to bug23680 Comment 5 for tests
$ ssh-keygen -t rsa -f gitolitekey
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in gitolitekey.
Your public key has been saved in gitolitekey.pub.
etc .....
$ gitolite setup -pk gitolitekey.pub
sh: git: opdracht niet gevonden i.e. command not found
This is a recently setup M6 installation with mostly only the default packages, so understandibly (in hindsight) git was not installed.
Went back to MCC and installed git plus its dependencies. Back to CLI:
$ gitolite setup -pk gitolitekey.pub
fatal: Not a git repository (or any of the parent directories): .git
Indeed. there is no .git folder in my home.
In other words: installing gitolite does not draw in git as a dependecy, and it does not get started if git on its own has not been used before on this machine. Right????

CC: (none) => herman.viaene

Comment 5 Herman Viaene 2019-01-23 15:59:24 CET
Tried to get any further:
$ git init
Initialized empty Git repository in /home/tester6/.git/
$ gitolite setup -pk gitolitekey.pub
FATAL: could not symlink /home/tester6/.gitolite/hooks/common/update to gitolite-admin.git/hooks
 at /usr/share/gitolite/lib/Gitolite/Conf/Store.pm line 374.
Comment 6 Lewis Smith 2019-01-23 20:47:17 CET
I was going to look at this, and had found your very good test routine. Do you know whether you had GIT already installed for that? I do have it (but never knowingly used).
Given that you are well started on this, I do not want simply to repeat the problems. Give a shout if I might help.
 "Gitolite allows you to setup git hosting on a central server, with
  fine-grained access control and many more powerful features."
Among its 'assumptions':
- You have a workstation.
- You have a server called server.

CC: (none) => lewyssmith

Comment 7 Herman Viaene 2019-01-24 08:54:26 CET
On testing bug 23680 I had git alreday installed before, most probably due to other update tests before. Since then I wiped M6 completely from the laptop and reinstalled it with just the default, only selection MATE as only desktop.
What you found from gitolite makes me think that one needs to setup a (be it empty) server before trying to use gitolite.
No promises, but I hope I can give it a try today.
Comment 8 Herman Viaene 2019-01-24 10:37:56 CET
Found a hint to create an empty git repos by
$ git init --bare
then added and committed a text file, but the result on the gitolite setup command remained the same.
By guessing I found out that by installing gotolite also a group gitolite had been created, so made my user member of this group, logged out and in again, but that made no difference.
Comment 9 Len Lawrence 2019-01-29 09:52:17 CET
Not intending to take this very far - just trying out the tutorial without running the update to see what happens.

Created a user called frodo with no home files 
$ cp ~/.ssh/id_rsa.pub /tmp/frodo
$ su
# su - git
# git clone https://github.com/sitaramc/gitolite
# cd $HOME
# mkdir -p bin
# gitolite/install -to $HOME/bin
# bin/gitolite setup -pk /tmp/frodo.pub

Back in user home:
$ git ls-remote git@difda:gitolite-admin
<some ssh warnings>
6d7d11ae017c364123b2b10886434d62f08000ff	HEAD
6d7d11ae017c364123b2b10886434d62f08000ff	refs/heads/master

$ su - git
# git clone git@difda:gitolite-admin
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 6 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (6/6), done.
# ls -A gitolite-admin
conf/  .git/  keydir/
# cd gitolite-admin
# ls -A conf keydir .git

branches/  description  hooks/  info/  objects/     refs/
config     HEAD         index   logs/  packed-refs

# cat conf/gitolite.conf
repo gitolite-admin
    RW+     =   frodo

repo testing
    RW+     =   @all

<Really got lost at this point>

# git add conf; git commit -m 'new repo foo'; git push

*** Please tell me who you are.

CC: (none) => tarazed25

Comment 10 Herman Viaene 2019-01-29 10:34:41 CET
I see you run the gitolite setup as root, pointing to the key of your normal user. Did you get that from the tutorial.
I failed this (I guess now), because I run this command as the normal user, as it worked for me in the older release. Could you cheeck that??
Comment 11 Len Lawrence 2019-01-29 10:52:10 CET
@Herman: Yes, I followed the tutorial slavishly.  It is badly written in the sense that the author does not distinguish clearly enough which are user commands and which root.  The convention is to use '$ command' for the user and '# command' for superuser.  I was very confused about users anyway in that tutorial  nor is it apparent to me what purpose gitolite serves.

I do understand why the git commit/push commands failed.  There is nothing in the tutorial about how to tell github who is calling.  There is an implicit understanding that gitolite users will already be completely familiar with git.  Trying to learn the two in parallel is a bit of a nonsense.
Comment 12 Len Lawrence 2019-01-29 11:09:01 CET
Looking at comment 6, what does "git hosting on a central server" actually mean?
Comment 13 Len Lawrence 2019-01-29 11:19:21 CET
Re comment 12:
Thinking about it, the nearest I can get is "spinning your own independent github".
Comment 14 Herman Viaene 2019-01-29 11:27:25 CET
About Comment 12: my understanding is that git can be completely installed (executables and data) on a server, whether this one is in the same LAN or remote w.r.t the workstations.
And to Comment 13: that's my understanding as well. I cann't imagine myself having a real client/server configuration available for QA testing. It would get too complicated.
Comment 15 Len Lawrence 2019-01-29 18:15:41 CET
Regarding CVE-2018-20683, logged in to user git:
$ su
# su git
# cd $HOME
# grep -i rsync .gitolite.rc
According to https://github.com/sitaramc/gitolite/commit/5df2b817255ee919991da6c310239e08c8fcc1ae

this means that we are not affected by the security issue.  Any line enabling rsync needs to be commented out.
This is before the update by the way.
Comment 16 Len Lawrence 2019-01-29 20:22:34 CET
Rereading the tutorial page for the nth time I noticed the suggestion about reading the concepts page.  That does very little to enhance one's understanding.  It mentions something called a "hook" without any clear explanation but, taking a wild guess, is that what redirects the git command to the local host instead of sending it out on the internet?  If so how is it set up?  How do we ensure that it is invoked?  These pages also indicate that one should be completely familiar with git terminology and operations, so see you in six weeks time. :-;
Comment 17 Len Lawrence 2019-01-29 21:12:23 CET
From whatis.com:
In programming, a hook is a place and usually an interface provided in packaged code that allows a programmer to insert customized programming. For example, a programmer might want to provide code that analyzed how often a particular logic path was taken within a program.
Comment 18 Lewis Smith 2019-01-29 21:26:24 CET
@Len: you have pushed this far. Ignore the hook business. If the update goes OK and the system 'works' as before, OK!
I am unsure about Herman not getting it to work now, when it used to.
I am willing to add something if I can, already having GIT installed at least. But we should be careful about trying too much on this.
From your toils (both), can you say whether this should work on the same machine? I was not sure from looking at the comments, old & new; nor not always what user you were doing things from. Did you both follow:
and which 'tutorial' is referred to, the original:
or the other:
From your experience, do you have to set up SSH access to root as stated somewhere?
Comment 19 Len Lawrence 2019-01-29 21:59:22 CET
I did not know about 23680.  Followed the tutorial at http://gitolite.com/gitolite/fool_proof_setup

I could have tried this on two machines but since many people are not in this position have tried to implement it on one machine.  It should work.

I am still trying to get my head round this user Ron business - frodo in my case.
I suspect that that is a red herring.

Your last question; don't know nuffink about that guv.
If it is the case then I have not done it.
Comment 20 Len Lawrence 2019-01-29 22:17:16 CET
Have had a quick look at the step-by-step tutorial and decided to scrap everything on this machine and set up gitolite on another machine, but not tonight.  There is a bug in a production program of mine which needs to be fixed so I shall be incommunicado for a day or two, possibly.
Comment 21 Len Lawrence 2019-01-30 13:24:01 CET
Moving to another machine was not very successful.  Tried the step-by-step instructions and hit many snags.  The tutorial is for Ubuntu who seem to have different versions of system commands like useradd.  Gave up on that and returned to difda.  Reestablished the git server id as gitter.  Followed the "fool-proof" utorial as far as
$ git clone gitter@difda:gitolite-admin
$ git ls-remote gitter@difda:gitolite-admin
Warning: Permanently added 'difda,' (ECDSA) to the list of known hosts.
X11 forwarding request failed on channel 0
81f2ce4a37bf437370ed2ba6b962aed5511370e4	HEAD
81f2ce4a37bf437370ed2ba6b962aed5511370e4	refs/heads/master

gitolite-admin ended up in the user directory.

At no time have I seen any reference to generating a keypair for root.  su is needed for access to the server directory but otherwise does not seem to be involved.  The git commands are run as the user.

Back on the server:
$ cat .ssh/authorized_keys 
# gitolite start
command="/home/gitter/bin/gitolite-shell lcl",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa ..........
........ lcl@difda
# gitolite end

The "no-agent-forwarding" looks a bit worrisome.  Needs an expert's opinion.
Harking back to hooks, this file might be the way they are implemented.
Anyway it has every appearance of being crucial to the whole thing.
Comment 22 Lewis Smith 2019-01-31 21:41:51 CET
Flogging M6/64 on a single box.

1. Installed gitolite-3.6.10-1.mga6

2. From my *normal* user, created an SSH key:
 [lewis@localhost ~]$ ssh-keygen
and both lost the O/P to record, and unwisely accepted its choice of key file
which presumably overwrote what was there before...

3. Created a new user 'gituser' (from MCC, but useradd would have been fine).

4. Found then followed /usr/share/doc/gitolite/gitolite-README-fedora

5. copy your admin user's ssh public key to /tmp/gituser.pub
 [lewis@localhost ~]$ cp .ssh/id_rsa.pub /tmp/gituser.pub
Not knowing what key it is talking about, however.

6. run "su - gitolite" to get a login shell on the gitolite user
 [lewis@localhost ~]$ su - gituser

7. run "cp /tmp/gituser.pub ."
 [gituser@localhost ~]$ cp /tmp/gituser.pub .

8. run "gitolite setup -pk ~/gituser.pub"
 [gituser@localhost ~]$ gitolite setup -pk ~/gituser.pub 
Initialized empty Git repository in /home/gituser/repositories/gitolite-admin.git/
Initialized empty Git repository in /home/gituser/repositories/testing.git/

This user ends up with a directory tree called repositories and containing gitolite-admin.git & testing.git among a great deal more.

[Up to here, like https://bugs.mageia.org/show_bug.cgi?id=23680#c5]

9. all done, exit the gitolite user shelll
 [gituser@localhost ~]$ exit              *not* Ctrl/D

10. From the 'fool-proof' guide, as normal user, tried:

 [lewis@localhost ~]$ git ls-remote gituser@localhost:gitolite-admin
/home/lewis/.ssh/config line 6: Unsupported option "compressionlevel"
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
Please contact your system administrator.
Add correct host key in /home/lewis/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/lewis/.ssh/known_hosts:2
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.
Agent forwarding is disabled to avoid man-in-the-middle attacks.
X11 forwarding is disabled to avoid man-in-the-middle attacks.
3f7c2946deabec0b7976857d273ea5e75090768d	HEAD
3f7c2946deabec0b7976857d273ea5e75090768d	refs/heads/master

and if nothing else, the last two lines are right! Clearly I have messed my SSH keys.

 [lewis@localhost ~]$ git clone gituser@localhost:gitolite-admin
Cloning into 'gitolite-admin'...
/home/lewis/.ssh/config line 6: Unsupported option "compressionlevel"
 [same error O/P as above]
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 6 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (6/6), done.
 which looks OK:
 [lewis@localhost ~]$ tree gitolite-admin/
├── conf
│   └── gitolite.conf
└── keydir
    └── gituser.pub

Back to Herman's earlier test URL above:
 [lewis@localhost ~]$ su - gituser
 [gituser@localhost ~]$ gitolite list-users
 [gituser@localhost ~]$ gitolite list-repos
 [gituser@localhost ~]$ gitolite query-rc -a
 which is what Herman got then.
AFTER update: gitolite-3.6.11-1.mga6.noarch     [Note the noarch]
All the commands (valid or not) behaved the same as before:

[lewis@localhost ~]$ git ls-remote gituser@localhost:gitolite-admin
[lewis@localhost ~]$ git clone gituser@localhost:gitolite-admin

[gituser@localhost ~]$ gitolite list-users
[gituser@localhost ~]$ gitolite list-repos
[gituser@localhost ~]$ gitolite query-rc -a

We have spent overtime on this. OK, validating, advisory comment 3.

Keywords: (none) => advisory, validated_update
Whiteboard: (none) => MGA6-64-OK
CC: (none) => sysadmin-bugs

Comment 23 Mageia Robot 2019-01-31 23:56:42 CET
An update for this issue has been pushed to the Mageia Updates repository.


Resolution: (none) => FIXED

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