Bug 23381 - sssd new security issue CVE-2018-10852
Summary: sssd new security issue CVE-2018-10852
Status: RESOLVED FIXED
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
URL:
Whiteboard: MGA6-32-OK MGA6-64-OK
Keywords: advisory, validated_update
Depends on:
Blocks:
 
Reported: 2018-08-02 17:42 CEST by David Walser
Modified: 2018-08-24 01:36 CEST (History)
6 users (show)

See Also:
Source RPM: sssd-1.13.4-13.mga7.src.rpm
CVE:
Status comment:


Attachments

Description David Walser 2018-08-02 17:42:02 CEST
SUSE has issued an advisory on July 30:
http://lists.suse.com/pipermail/sle-security-updates/2018-July/004360.html

The upstream announcement has a commit fix link for 1.13.x:
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/XUCDLKDVH7HZKPSJ7GEJAVNZS5CW35EK/

Mageia 5 and Mageia 6 are also affected.
David Walser 2018-08-02 17:42:09 CEST

Whiteboard: (none) => MGA6TOO

Comment 1 Marja Van Waes 2018-08-02 18:36:55 CEST
Assigning to all packagers collectively, since there is no registered maintainer for this package.
CC'ing daviddavid

Assignee: bugsquad => pkg-bugs
CC: (none) => geiger.david68210, marja11

Comment 2 David Walser 2018-08-10 17:18:04 CEST
openSUSE has issued an advisory for this today (August 10):
https://lists.opensuse.org/opensuse-updates/2018-08/msg00071.html
Comment 3 David GEIGER 2018-08-13 10:59:22 CEST
Done for Cauldron and also for mga6!
Comment 4 David Walser 2018-08-13 20:01:05 CEST
Thanks David!

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

Updated sssd packages fix security vulnerability:

The UNIX socket that is used for communication between the sudo utility and the
sssd-sudo responder had its permissions set to world-readable and writable,
which means that anyone who can send a message using the same raw protocol that
sudo and SSSD use can read the sudo rules available for any user
(CVE-2018-10852).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10852
https://lists.fedoraproject.org/archives/list/sssd-users@lists.fedorahosted.org/message/XUCDLKDVH7HZKPSJ7GEJAVNZS5CW35EK/
https://lists.opensuse.org/opensuse-updates/2018-08/msg00071.html
========================

Updated packages in core/updates_testing:
========================
sssd-1.13.4-9.2.mga6
sssd-common-1.13.4-9.2.mga6
sssd-client-1.13.4-9.2.mga6
libsss_sudo-1.13.4-9.2.mga6
libsss_autofs-1.13.4-9.2.mga6
sssd-tools-1.13.4-9.2.mga6
python-sssdconfig-1.13.4-9.2.mga6
python3-sssdconfig-1.13.4-9.2.mga6
python-sss-1.13.4-9.2.mga6
python3-sss-1.13.4-9.2.mga6
python-sss-murmur-1.13.4-9.2.mga6
python3-sss-murmur-1.13.4-9.2.mga6
sssd-ldap-1.13.4-9.2.mga6
sssd-krb5-common-1.13.4-9.2.mga6
sssd-krb5-1.13.4-9.2.mga6
sssd-common-pac-1.13.4-9.2.mga6
sssd-ipa-1.13.4-9.2.mga6
sssd-ad-1.13.4-9.2.mga6
sssd-proxy-1.13.4-9.2.mga6
libsss_idmap-1.13.4-9.2.mga6
libsss_idmap-devel-1.13.4-9.2.mga6
libipa_hbac-1.13.4-9.2.mga6
libipa_hbac-devel-1.13.4-9.2.mga6
python-libipa_hbac-1.13.4-9.2.mga6
python3-libipa_hbac-1.13.4-9.2.mga6
libsss_nss_idmap-1.13.4-9.2.mga6
libsss_nss_idmap-devel-1.13.4-9.2.mga6
python-libsss_nss_idmap-1.13.4-9.2.mga6
python3-libsss_nss_idmap-1.13.4-9.2.mga6
sssd-dbus-1.13.4-9.2.mga6
libsss_simpleifp-1.13.4-9.2.mga6
libsss_simpleifp-devel-1.13.4-9.2.mga6
sssd-libwbclient-1.13.4-9.2.mga6
sssd-libwbclient-devel-1.13.4-9.2.mga6

from sssd-1.13.4-9.2.mga6.src.rpm

Whiteboard: MGA6TOO => (none)
Version: Cauldron => 6
Assignee: pkg-bugs => qa-bugs

Comment 5 Len Lawrence 2018-08-14 20:09:46 CEST
Mageia 6, x86_64

Looks like I tried sssd in 2017 but got nowhere with it.

Tried it again before trying to update anything.
Installed all packages and enabled sssd.service then started it.  It failed with an instruction to examine the journal.

$ sudo journalctl -xe | grep sssd
-- Subject: Unit sssd.service has begun start-up
-- Unit sssd.service has begun starting up.
Aug 14 18:32:26 difda sssd[31754]: NSCD socket was detected and seems to be configured to cache some of the databases controlled by SSSD [passwd,group,netgroup,services]. It is recommended not to run NSCD in parallel with SSSD, unless NSCD is configured not to cache these.
Aug 14 18:32:26 difda sssd[31754]: Configuration file: /etc/sssd/sssd.conf does not exist.
Aug 14 18:32:26 difda systemd[1]: sssd.service: Control process exited, code=exited status=4
-- Subject: Unit sssd.service has failed

# systemctl stop nscd.service
Warning: Stopping nscd.service, but it can still be activated by:
  nscd.socket
# systemctl disable nscd
Removed /etc/systemd/system/sockets.target.wants/nscd.socket.
Removed /etc/systemd/system/multi-user.target.wants/nscd.service.

That did not help, still no sssd.conf.

Found an example at github with most of the entries commented out.
Tried enabling some of the lines without having any clue as to what was
required and ran the start command again.  It failed, as expected.

-- Subject: Unit sssd.service has begun start-up
-- Unit sssd.service has begun starting up.
Aug 14 18:55:30 difda sssd[2125]: Cannot read config file /etc/sssd/sssd.conf. Please check that the file is accessible only by the owner and owned by root.root.
Aug 14 18:55:30 difda systemd[1]: sssd.service: Control process exited, code=exited status=4
# ll /etc/sssd/sssd.conf
-rw-r--r-- 1 root root 1894 Aug 14 18:55 sssd.conf

My example config file:
[sssd]
config_file_version = 2
services = nss, pam
# SSSD will not start if you do not configure any domains.
# Add new domain configurations as [domain/<NAME>] sections, and
# then add the list of domains (in the order you want them to be
# queried) to the "domains" attribute below and uncomment it.
domains = LDAP

[nss]

[pam]

# Example LDAP domain
[domain/LDAP]
id_provider = ldap
auth_provider = ldap
# ldap_schema can be set to "rfc2307", which stores group member names in the
# "memberuid" attribute, or to "rfc2307bis", which stores group member DNs in
# the "member" attribute. If you do not know this value, ask your LDAP
# administrator.
ldap_schema = rfc2307
ldap_uri = ldap://ldap.mydomain.org
ldap_search_base = dc=mydomain,dc=org
# Note that enabling enumeration will have a moderate performance impact.
# Consequently, the default value for enumeration is FALSE.
# Refer to the sssd.conf man page for full details.
; enumerate = false
# Allow offline logins by locally storing password hashes (default: false).
; cache_credentials = true

I suspect that I am too far out of my depth here - probably have to drop it.

CC: (none) => tarazed25

Comment 6 Herman Viaene 2018-08-18 11:42:03 CEST
MGA6-32 MATE on IBM Thinkpad R50e
No installation issues at first sight, but
# systemctl -l status sssd
● sssd.service - System Security Services Daemon
   Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: enabled)
   Active: inactive (dead)
That is OK
# systemctl start sssd
Job for sssd.service failed because the control process exited with error code.
See "systemctl status sssd.service" and "journalctl -xe" for details.
# journalctl -xe | grep sss
-- Subject: Unit sssd.service has begun start-up
-- Unit sssd.service has begun starting up.
aug 18 11:22:55 mach6.hviaene.thuis sssd[11824]: Configuration file: /etc/sssd/sssd.conf does not exist.
# rpm -qf /etc/sssd
sssd-common-1.13.4-9.2.mga6
Checked in MCC on the sssd-common package, this lists
       /etc/sssd
‎        /etc/sssd/sssd.conf
Checked in file system: the folder /etc/sssd is created, but is empty.

Something strikes me as strange : many daemon have the /etc conf files in the daemon package itself, not so here. But that cannot be a reason why the conf file is missing after installation???

CC: (none) => herman.viaene

Comment 7 David Walser 2018-08-18 13:36:27 CEST
You have to create the config file with the appropriate settings for your environment.
Comment 8 Len Lawrence 2018-08-19 01:10:12 CEST
Yeah - figured that out in the end but it does not help without some experience of the subject.  It does not help if you have no idea what the local settings should be.  What does domain mean for instance?  Or ldap_search_base?  The suggestion that you ask your LDAP administrator is laughable.  The man page for sssd.conf is completely opaque.  "A domain is a database containing user information" so presumably that has to be created somehow.  So it is simply not doable without a six-month induction course.
Comment 9 David Walser 2018-08-19 02:02:48 CEST
A domain is Active Directory or an LDAP domain.  So you have to have a server set up to use one of those.  I think you can also set up sssd to basically be a cache of the local users database.
Comment 10 Herman Viaene 2018-08-21 15:20:33 CEST
Found example of conf file at https://gist.github.com/lashtear/e39ca0c5ac2ade6cc5b024d7780d842f
Brought it (guessing) to a minimum as:
[sssd]
domains = local
services = pam
config_file_version = 2
#debug_level = 6

[pam]
#debug_level = 6

[domain/local]
id_provider = local
auth_provider = local
chpass_provider = local
#debug_level = 6
After making sure the permissions are correct:
ls -als /etc/sssd/sssd.conf
4 -rw------- 1 root root 202 aug 21 14:54 /etc/sssd/sssd.conf
I could finally
# systemctl start sssd
# systemctl -l status sssd
● sssd.service - System Security Services Daemon
   Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: enabled)
   Active: active (running) since di 2018-08-21 14:56:04 CEST; 6s ago
  Process: 5260 ExecStart=/usr/sbin/sssd -D -f (code=exited, status=0/SUCCESS)
 Main PID: 5265 (sssd)
   CGroup: /system.slice/sssd.service
           ├─5265 /usr/sbin/sssd -D -f
           └─5266 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files

aug 21 14:56:03 mach6.xxx.yyy systemd[1]: Starting System Security Services Daemon...
aug 21 14:56:03 mach6.xxx.yyy sssd[5265]: Starting up
aug 21 14:56:04 mach6.xxx.yyy sssd[pam][5266]: Starting up
aug 21 14:56:04 mach6.xxx.yyy systemd[1]: Started System Security Services Daemon.
Looking up things in bug21917 I tried:
# sss_useradd prutser
[root@mach6 ~]# sss_groupshow prutser
Magic Private Groep: prutser
GID nummer: 1000
Lid gebruikers: 
Is lid van: 
Lid groepen: 
Seems to work after all, and thatś how far my knowledge goes.
Note: if you want to know what "prutser" means, google translator helps.

Whiteboard: (none) => MGA6-32-OK

Comment 11 Len Lawrence 2018-08-21 17:34:50 CEST
A good guess too Herman.  Modified the config file along your lines and it worked.  No idea what it all means.
Re prutser: Aren't we all?
translate-shell helps also -
$ trans nl:en prutser
............

# systemctl start sssd
[root@difda etc]# systemctl status sssd
● sssd.service - System Security Services Daemon
   Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset:
   Active: active (running) since Tue 2018-08-21 16:00:10 BST; 9s ago

It looks like this is old ground.  Thanks for the 21917 reference Herman.  We seem to have done a lot of work that time but who has three days to spare any more?

# sss_useradd frodo
# sss_groupshow frodo
Magic Private Group: frodo
GID number: 1002
Member users: 
Is a member of: 
Member groups: 

Leaving it there - not satisfactory perhaps, but there it is.

OK for 64-bits.
Len Lawrence 2018-08-21 17:35:27 CEST

Whiteboard: MGA6-32-OK => MGA6-32-OK MGA6-64-OK

Len Lawrence 2018-08-23 10:54:36 CEST

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

Thomas Backlund 2018-08-24 00:24:59 CEST

Keywords: (none) => advisory
CC: (none) => tmb

Comment 12 Mageia Robot 2018-08-24 01:36:06 CEST
An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2018-0350.html

Resolution: (none) => FIXED
Status: NEW => RESOLVED


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