Bug 9027 - sssd new security issues CVE-2013-0219 and CVE-2013-0220
: sssd new security issues CVE-2013-0219 and CVE-2013-0220
Status: RESOLVED FIXED
Product: Mageia
Classification: Unclassified
Component: Security
: 2
: i586 Linux
: Normal Severity: normal
: ---
Assigned To: QA Team
:
: http://lwn.net/Vulnerabilities/537247/
: MGA2-64-OK MGA2-32-OK
: validated_update
:
:
  Show dependency treegraph
 
Reported: 2013-02-10 18:42 CET by David Walser
Modified: 2014-05-08 18:06 CEST (History)
6 users (show)

See Also:
Source RPM: sssd-1.9.3-1.mga3.src.rpm
CVE:
Status comment:


Attachments

Description David Walser 2013-02-10 18:42:37 CET
Fedora has issued an advisory on February 1:
http://lists.fedoraproject.org/pipermail/package-announce/2013-February/098434.html

These issues are fixed in 1.9.4, so the Cauldron package should be updated.
https://fedorahosted.org/sssd/wiki/Releases/Notes-1.9.4

The issue also effects the 1.8.x branch and was fixed in 1.8.6:
https://fedorahosted.org/sssd/wiki/Releases/Notes-1.8.6

It is not immediately clear if 1.7.0 (in Mageia 2) is affected, as that branch only had the 1.7.0 release and is not maintained upstream.
Comment 1 David Walser 2013-02-14 23:44:48 CET
FYI, Mageia 2 isn't vulnerable to CVE-2013-0220 as the affected code isn't present.  It is vulnerable to CVE-2013-0219.
Comment 2 David Walser 2013-02-15 01:30:31 CET
For Cauldron, 1.9.4 doesn't build, giving this error:

src/util/sss_krb5.c:1006:38: warning: 'struct krb5_trace_info' declared inside parameter list [enabled by default]
src/util/sss_krb5.c:1006:38: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
src/util/sss_krb5.c: In function 'sss_child_krb5_trace_cb':
src/util/sss_krb5.c:1013:5: error: dereferencing pointer to incomplete type
src/util/sss_krb5.c: In function 'sss_child_set_krb5_tracing':
src/util/sss_krb5.c:1019:5: warning: passing argument 2 of 'krb5_set_trace_callback' from incompatible pointer type [enabled by default]
In file included from ./src/util/sss_krb5.h:30:0,
                 from src/util/sss_krb5.c:27:
/usr/include/krb5/krb5.h:7968:1: note: expected 'krb5_trace_callback' but argument is of type 'void (*)(struct _krb5_context *, const struct krb5_trace_info *, void *)'
Comment 3 David Walser 2013-02-15 01:31:49 CET
For Mageia 2, I got a rediffed patch through some ugly means, and it builds, but I have no idea if it works.  It might be better to just upgrade to 1.8.6, as 1.8 is a long-term maintained release upstream.
Comment 4 David Walser 2013-02-15 02:23:04 CET
OK, got it to build in Cauldron with some patches from Fedora.

Freeze push requested.
Comment 5 David Walser 2013-02-15 18:33:20 CET
Patched package uploaded for Mageia 2.

Advisory:
========================

Updated sssd packages fix security vulnerability:

A TOCTOU (time-of-check time-of-use) race condition was found in the way SSSD,
System Security Services Daemon, performed copying and removal of (user)
directory trees.A local attacker, with permissions to write into directory of
the victim, being actively / currently copied / removed via the sssd daemon
facility, could use this flaw to conduct symbolic link attacks, leading to
their ability to alter / remove directories outside of originally intended, to
be modified, directory tree (CVE-2013-0219).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0219
https://fedorahosted.org/sssd/ticket/1782
http://lists.fedoraproject.org/pipermail/package-announce/2013-February/098434.html
========================

Updated packages in core/updates_testing:
========================
sssd-1.7.0-2.1.mga2
sssd-client-1.7.0-2.1.mga2
sssd-libipa_hbac0-1.7.0-2.1.mga2
sssd-libipa_hbac-1.7.0-2.1.mga2

from sssd-1.7.0-2.1.mga2.src.rpm
Comment 6 claire robinson 2013-02-18 13:05:52 CET
No public PoC's
Comment 7 claire robinson 2013-02-18 13:20:07 CET
Testing mga2 64

Not sure this is even working.

# service sssd start
Starting sssd (via systemctl):  Job failed. See system journal and 'systemctl status' for details.
# systemctl status sssd.service
sssd.service - LSB: System Security Services Daemon
          Loaded: loaded (/etc/rc.d/init.d/sssd)
          Active: failed (Result: exit-code) since Mon, 18 Feb 2013 12:15:51 +0000; 3s ago
         Process: 24334 ExecStart=/etc/rc.d/init.d/sssd start (code=exited, status=4/NOPERMISSION)
          CGroup: name=systemd:/system/sssd.service

Found in /etc/sssd/sssd.conf that it fails to start is no domains are configured so edited it and uncommented and set domains = LOCAL and uncommented the [domain/LOCAL] stanza.

It still fails with the same error NOPERMISSION.

# ll /etc/init.d/sssd
-rwxr-xr-x 1 root root 2668 Mar 20  2012 /etc/init.d/sssd*
Comment 8 claire robinson 2013-02-18 13:21:48 CET
Same after updating.
Comment 9 claire robinson 2013-02-18 13:23:31 CET
Some docs to test it with: http://jhrozek.fedorapeople.org/sssd/1.8.5/man/

sss_useradd etc
Comment 10 Dave Hodgins 2013-03-01 00:05:53 CET
Found Vincent's document at
http://linsec.ca/Using_OpenLDAP_for_User_Authentication
Comment 11 Bill Wilkinson 2013-03-03 00:20:32 CET
Fedora has a test procedure at:
http://fedoraproject.org/wiki/Category:SSSD_Test_Cases

test cases include ldap and kerberos
ldap and ldap authentication (3 ways)
local identity and authentication
Comment 12 David Walser 2013-03-03 00:29:20 CET
Thanks.  The affected functionality by the patch to fix is creating and removing home directories, so please try and find a test procedure that makes use of that functionality.
Comment 13 David Walser 2013-03-03 00:33:30 CET
(In reply to Bill Wilkinson from comment #11)
> Fedora has a test procedure at:
> http://fedoraproject.org/wiki/Category:SSSD_Test_Cases
> 
> test cases include ldap and kerberos
> ldap and ldap authentication (3 ways)
> local identity and authentication

The test for local identity and authetication doesn't make any sense, unless they're using that a baseline to make sure it works before adding sssd for LDAP authentication to see if that breaks anything.  I don't see any way their instructions for local authentication would actually make any use of sssd.
Comment 14 David Walser 2013-03-03 02:26:23 CET
A quick look at the documentation suggests that it can do local authentication using its own local binary database.  It sounds like the sssd service should be running, using an sssd.conf that defines a local domain.  The syntax for that might be this:
###
[sssd]
domains = LOCAL
services = nss, pam
config_file_version = 2

[nss]
filter_groups = root
filter_users = root

[pam]

[domain/LDAP]
id_provider = local
###

Then you can use the sss_useradd command with the -m option to create a user and their home directory, and the sss_userdel command with the -r option to delete that user and their home directory.  I haven't tested this, but this seems to be the idea.
Comment 15 Dave Hodgins 2013-04-05 00:43:35 CEST
Having trouble getting it to start.

systemctl status sssd.service
sssd.service - LSB: System Security Services Daemon
          Loaded: loaded (/etc/rc.d/init.d/sssd)
          Active: failed (Result: exit-code) since Thu, 04 Apr 2013 18:38:46 -0400; 5s ago
         Process: 22829 ExecStart=/etc/rc.d/init.d/sssd start (code=exited, status=4/NOPERMISSION)
          CGroup: name=systemd:/system/sssd.service

Trying it under strace shows
sendto(3, "<25>Apr  4 18:39:21 sssd: Cannot load configuration database"
but I don't see it trying to load anything. 

I'm using the config from comment 14
Comment 16 Dave Hodgins 2013-04-05 01:05:13 CEST
Tried adding a user, to see if that would init the db ...
# sss_useradd testuser1
(Thu Apr  4 19:03:10:565859 2013) [sss_useradd] [ldb] (0x0010): Unable to find backend for '/var/lib/sss/db/config.ldb' - do you need to set LDB_MODULES_PATH?
(Thu Apr  4 19:03:10:566124 2013) [sss_useradd] [confdb_init] (0x0010): Unable to open config database [/var/lib/sss/db/config.ldb]
Error initializing the tools

The directory /var/lib/sss/db/ does exist, but is empty.
Comment 17 Dave Hodgins 2013-04-05 01:48:35 CEST
I'm past that error, by installing ldb-utils
Comment 18 David Walser 2013-04-12 00:01:36 CEST
Updated to 1.8.6.  That was more work than I thought.  There are some packaging changes, but basically the same as was done in the mga3 package.

Advisory:
========================

Updated sssd packages fix security vulnerability:

A TOCTOU (time-of-check time-of-use) race condition was found in the way SSSD,
System Security Services Daemon, performed copying and removal of (user)
directory trees.A local attacker, with permissions to write into directory of
the victim, being actively / currently copied / removed via the sssd daemon
facility, could use this flaw to conduct symbolic link attacks, leading to
their ability to alter / remove directories outside of originally intended, to
be modified, directory tree (CVE-2013-0219).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0219
https://fedorahosted.org/sssd/ticket/1782
http://lists.fedoraproject.org/pipermail/package-announce/2013-February/098434.html
========================

Updated packages in core/updates_testing:
========================
sssd-1.8.6-1.mga2
sssd-client-1.8.6-1.mga2
sssd-tools-1.8.6-1.mga2
sssd-libipa_hbac0-1.8.6-1.mga2
sssd-libipa_hbac-1.8.6-1.mga2
libsss_autofs-1.8.6-1.mga2
libsss_sudo-1.8.6-1.mga2
libsss_sudo-devel-1.8.6-1.mga2

from sssd-1.8.6-1.mga2.src.rpm
Comment 19 Dave Hodgins 2013-04-30 02:26:56 CEST
Still needs to have a requires added for ldb-utils.

Edited /etc/sssd/sssd.conf
Added the line
domains = LOCAL

Uncommented the lines
[domain/LOCAL]
description = LOCAL Users domain
id_provider = local
enumerate = true
min_id = 500
max_id = 999

Edited /etc/nsswitch.conf and set
passwd:><------>files sss
shadow:><------>files sss
group:<><------>files sss

Rebooted

[root@i2v ~]# sss_useradd qasssd
[root@i2v ~]# passwd qasssd
passwd: Unknown user name 'qasssd'.
[root@i2v ~]# ll /home/qasssd/
total 4
drwx------ 2 dave dave 4096 Jan 11  2011 tmp/

So the home directory was created, but I don't see how to
assign the user a password.

[root@i2v ~]# sss_userdel qasssd
Cannot reset SELinux login context

And I can't delete the user.
Comment 20 David Walser 2013-05-01 20:08:05 CEST
It's not immediately obvious why ldb-utils would be needed.  It's not required in the Fedora 1.8.6 package or our Cauldron package.  Playing with this in Cauldron, that doesn't seem to cause any problems.  libldb is required.

There are a couple possible problems you're running into, which I did in my tests too.

First of all, you need to do:
systemctl stop nscd.service
systemctl stop nscd.socket

As nscd and sssd can't work at the same time, and getent will see the sss user you add, but id and ls and everything else won't.

Second, you need to make sure the user added by sss doesn't use the same UID as an existing user on the system.  So if you already have someone using UID 500 on the system, change this in sssd.conf: min_id = 501

So, testing this in Cauldron, that got me a little farther, but I still can't change the password of the user:
# passwd student
Changing password for user student.
passwd: Authentication token manipulation error

I also can't get sss_userdel to remove their home directory and mail file, even with the -r and -f options, and also see the SELinux message.
Comment 21 Guillaume Rousse 2013-05-03 16:39:53 CEST
What is required in ldb software is the backends, located in %{_libdir}/ldb,  previously shipped in ldb-utils package. and moved to main library package in 1.1.14-3.mga3 release.
Comment 22 David Walser 2013-05-03 17:58:16 CEST
(In reply to Guillaume Rousse from comment #21)
> What is required in ldb software is the backends, located in %{_libdir}/ldb,
> previously shipped in ldb-utils package. and moved to main library package
> in 1.1.14-3.mga3 release.

Ahh yes, I remember that now, thanks.

Do you have any idea about the other issues we're having (passwd not working and sssd_userdel not removing the home directory and mail spool file)?  Are we doing something wrong here, or is the software broken?
Comment 23 Guillaume Rousse 2013-05-06 21:40:14 CEST
No idea. I never used sssd local backend myself, and I'm quite doubtful about its interest over a plain old /etc/passwd file.
Comment 24 David Walser 2013-05-06 22:08:00 CEST
Thanks Guillaume.

Dave, I think this package is in as good of shape as the Cauldron version, and I feel more comfortable shipping this one than my previous 1.7.0 update candidate, as this one is all upstream code, rather than my hacked-together patch.  When we have more time we can come up with an LDAP-enabled testing procedure for this.

As for the ldb-utils issue, I think it's better to fix the packaging error in ldb.

I've submitted a fixed ldb to Mageia 2 updates_testing, and we can release a MGAA bugfix advisory for that one.

"A packaging error where files needed by the libldb library were in the
ldb-utils package instead of the library package itself has been fixed."

libldb1-1.1.4-1.1.mga2
ldb-utils-1.1.4-1.1.mga2
libldb-devel-1.1.4-1.1.mga2
python-ldb-1.1.4-1.1.mga2
libpyldb-util1-1.1.4-1.1.mga2
libpyldb-util-devel-1.1.4-1.1.mga2

from ldb-1.1.4-1.1.mga2.src.rpm
Comment 25 Dave Hodgins 2013-05-23 19:44:32 CEST
/usr/sbin/sss_useradd has been moved from sssd to sssd_tools, so
installing the update for sssd removes the command.

Should the updated sssd have a requires on sssd_tools?
Comment 26 Dave Hodgins 2013-05-23 20:00:04 CEST
Getting sssd to start, without installing ldb-utils, is working now.

Still can't figure out how to change the users password, and
trying to delete a user added with sss_user add still gets

sss_userdel -r qasssd
Cannot reset SELinux login context

I'm prepared to assume that's a configuration problem on my part,
so once the requires is added for sssd-tools, should be ready for
validation.
Comment 27 David Walser 2013-05-24 03:53:04 CEST
sssd doesn't need to require sssd-tools.
Comment 28 Dave Hodgins 2013-05-26 18:14:26 CEST
(In reply to David Walser from comment #27)
> sssd doesn't need to require sssd-tools.

I disagree.

With the prior version of sssd installed, but not configured ...
[root@x2v ~]# sss_userdel nosuchuser
(Sun May 26 12:10:43:527615 2013) [sss_userdel] [ldb] (0x0010): Unable to find backend for '/var/lib/sss/db/config.ldb' - do you need to set LDB_MODULES_PATH?
(Sun May 26 12:10:43:527733 2013) [sss_userdel] [confdb_init] (0x0010): Unable to open config database [/var/lib/sss/db/config.ldb]
Error initializing the tools

After installing the update ...
[root@x2v ~]# sss_userdel nosuchuser
-bash: sss_userdel: command not found

So installing the update, as is, removes the sss_user commands,
from an existing installation.
Comment 29 Guillaume Rousse 2013-05-26 19:10:45 CEST
The various sss_* commands are not mandatory to use sssd, they are only needed for directly accessing backends content AFAIK.
Comment 30 David Walser 2013-05-26 20:42:24 CEST
(In reply to Guillaume Rousse from comment #29)
> The various sss_* commands are not mandatory to use sssd, they are only
> needed for directly accessing backends content AFAIK.

Exactly, and they're probably really only useful with the local backend, which as we've seen doesn't even work that well, probably only exists for testing purposes, and yet actually doesn't even seem to be well tested.
Comment 31 Dave Hodgins 2013-05-27 03:53:23 CEST
I strongly disagree with moving commands into a new package, that
is not automatically installed with the update, therefore removing
them from existing systems, but won't hold this update any longer
due to that.

Could someone from the sysadmin team push the srpm
sssd-1.8.6-1.mga2.src.rpm
from Mageia 2 Core Updates Testing to Core Updates.

Advisory: Updated sssd packages fix security vulnerability:

A TOCTOU (time-of-check time-of-use) race condition was found in the way SSSD,
System Security Services Daemon, performed copying and removal of (user)
directory trees.A local attacker, with permissions to write into directory of
the victim, being actively / currently copied / removed via the sssd daemon
facility, could use this flaw to conduct symbolic link attacks, leading to
their ability to alter / remove directories outside of originally intended, to
be modified, directory tree (CVE-2013-0219).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0219
https://fedorahosted.org/sssd/ticket/1782
http://lists.fedoraproject.org/pipermail/package-announce/2013-February/098434.html

https://bugs.mageia.org/show_bug.cgi?id=9027
Comment 32 David Walser 2013-05-27 16:28:43 CEST
ldb is also a part of this update.  From Comment 24:
I've submitted a fixed ldb to Mageia 2 updates_testing, and we can release a MGAA bugfix advisory for that one.

"A packaging error where files needed by the libldb library were in the
ldb-utils package instead of the library package itself has been fixed."

libldb1-1.1.4-1.1.mga2
ldb-utils-1.1.4-1.1.mga2
libldb-devel-1.1.4-1.1.mga2
python-ldb-1.1.4-1.1.mga2
libpyldb-util1-1.1.4-1.1.mga2
libpyldb-util-devel-1.1.4-1.1.mga2

from ldb-1.1.4-1.1.mga2.src.rpm
Comment 33 Nicolas Vigier 2013-06-06 21:44:31 CEST
Packages have been pushed to updates.

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