oss-security - fusionforge CVE-2013-1423 multiple privilege escalations

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20130225132745.GA3202@alf.mars>
Date: Mon, 25 Feb 2013 14:27:47 +0100
From: Helmut Grohne <helmut@...divi.de>
To: oss-security@...ts.openwall.com
Cc: Roland Mas <lolando@...ian.org>
Subject: fusionforge CVE-2013-1423 multiple privilege escalations

Hello,

I am publicly disclosing fusionforge CVE-2013-1423 today. On the 25th of
January I reported one of these issues to the Debian security team and
the fusionforge maintainers. In the process of fixing the issue a number
of further issues surfaced. All of these issues currently covered by the
single CVE-2013-1423 have in common that they related to privileged
operations not properly checking their environment and thus leading to
privilege escalation. Let me give an easy to exploit example.

Quoting deb-specific/user_dump_update.pl (fusionforge 5.2-1):
|       $home_dir = $homedir_prefix.'/'.$username;
|       unless (-d $home_dir.'/incoming') {
|           mkdir $home_dir.'/incoming', 0755;
|       }
|
|       my $realuid=get_file_owner_uid($home_dir);
|       if ($uid eq $realuid){
|               system("chown $uid $home_dir/incoming");
|               system("chmod 0755 $home_dir/incoming");

This code is executed as root in a cron job. By replacing ~/incoming
with a hard link to some other file (.e.g. an .ssh/authorized_keys file
from a different user) an attacker can gain ownership of files.

The initial report related to plugins/scmcvs/cronjobs/ssh_create.php
which contained a chown to ~user/.ssh which is user controlled.

Most of the issues relate to usage of chown or chmod on objects
controlled by a user. These issues have been avoided carrying out
operations on user controlled files with the effective permission of the
user (seteuid). Another source was TOCTOU race conditions which have
been avoided by using O_EXCL which is file mode "x" in php. Also some
file permission were only fixed after closing the file (information
disclosure) which is now done at open time by using umask.

Roland Mas iteratively updated the sources with me giving feedback on
issues. The resulting patches have been commited to the respective git
branches. Please have a look at those patches for further details.

5.0: https://fusionforge.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=fusionforge/fusionforge.git;a=commitdiff;h=0cc51b3aca51fa915a35195fdf729bcdb903f2af
5.1: https://fusionforge.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=fusionforge/fusionforge.git;a=commitdiff;h=9937b9d94ab60ff67fe249c1b9a6c8e3fc1778ba
5.2: https://fusionforge.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=fusionforge/fusionforge.git;a=commitdiff;h=1fc730b97c797e03b89cd37823ab345d35286cf4

Here is a list of files affected:

contrib/gforge-3.0-cronjobs.patch (removed)
cronjobs/homedirs.php
deb-specific/fileforge.pl (removed)
deb-specific/group_dump_update.pl
deb-specific/ssh_dump_update.pl
deb-specific/user_dump_update.pl
plugins/scmbzr/common/BzrPlugin.class.php
plugins/scmcvs/common/CVSPlugin.class.php
plugins/scmcvs/cronjobs/cvs.php
plugins/scmcvs/cronjobs/ssh_create.php
plugins/scmgit/common/GitPlugin.class.php
plugins/scmsvn/common/SVNPlugin.class.php
plugins/wiki/cronjobs/create_groups.php
utils/cvs1/cvscreate.sh (removed)
utils/include.pl

Finally I would like to thank Roland Mas for his thorough work on these
issues, his quick reaction and the nice interaction.

Helmut

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.