Bug 1498173 (CVE-2017-12173) - CVE-2017-12173 sssd: unsanitized input when searching in local cache database
Summary: CVE-2017-12173 sssd: unsanitized input when searching in local cache database
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2017-12173
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: impact=moderate,public=20171003,repor...
Depends On: 1499353 1499354 1499355 1499658 1499659 1507435
Blocks: 1493575
TreeView+ depends on / blocked
 
Reported: 2017-10-03 15:59 UTC by Cedric Buissart 🐶
Modified: 2019-06-11 11:13 UTC (History)
28 users (show)

Fixed In Version: sssd 1.16.0
Doc Type: If docs needed, set a value
Doc Text:
It was found that sssd's sysdb_search_user_by_upn_res() function did not sanitize requests when querying its local cache and was vulnerable to injection. In a centralized login environment, if a password hash was locally cached for a given user, an authenticated attacker could use this flaw to retrieve it.
Clone Of:
Environment:
Last Closed: 2019-06-08 03:26:30 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2017:3379 normal SHIPPED_LIVE Moderate: sssd security and bug fix update 2017-12-05 06:11:14 UTC
Red Hat Product Errata RHSA-2018:1877 None None None 2018-06-19 04:49:58 UTC

Description Cedric Buissart 🐶 2017-10-03 15:59:09 UTC
SSSD stores its cached data in an LDAP like local database file using libldb. To lookup cached data LDAP search filters like '(objectClass=user)(name=user_name)' are used. However, in sysdb_search_user_by_upn_res(), the input is not sanitized and allows to manipulate the search filter for cache lookups.

This would allow a logged in user to discover the password hash of a different user.
The password hash would be cached after a successful authentication of the corresponding user.

Comment 4 Salvatore Bonaccorso 2017-10-05 04:13:07 UTC
Is there a reference to "upstream" issue and fixing commits?

Comment 7 Kurt Seifried 2017-10-06 19:44:36 UTC
Created sssd tracking bugs for this issue:

Affects: fedora-all [bug 1499354]

Comment 13 Cedric Buissart 🐶 2017-10-10 08:41:37 UTC
Acknowledgments:

Name: Sumit Bose (Red Hat)

Comment 15 Cedric Buissart 🐶 2017-10-10 11:01:05 UTC
(In reply to Salvatore Bonaccorso from comment #4)
> Is there a reference to "upstream" issue and fixing commits?

We're still waiting for the patch to be committed. I ll drop a link here as soon as it is done. 

Versions prior to sssd-1.12.0 are not affected (affected commit: 7ecb5ae)

Comment 16 Simo Sorce 2017-10-10 13:19:13 UTC
Cedric in the doc text add something to the effect "but only if that data was previously locally cached", note that passwords hases are not always cached locally even if other user info is.

Comment 17 Cedric Buissart 🐶 2017-10-10 13:23:42 UTC
(In reply to Simo Sorce from comment #16)
> Cedric in the doc text add something to the effect "but only if that data
> was previously locally cached", note that passwords hases are not always
> cached locally even if other user info is.

but can't an attacker simply try to log in once as the target to force hash to be cached locally ?

Comment 18 Stephen Gallagher 2017-10-10 13:28:54 UTC
(In reply to Cedric Buissart from comment #17)
> (In reply to Simo Sorce from comment #16)
> > Cedric in the doc text add something to the effect "but only if that data
> > was previously locally cached", note that passwords hases are not always
> > cached locally even if other user info is.
> 
> but can't an attacker simply try to log in once as the target to force hash
> to be cached locally ?

No, the way that password-caching works in SSSD does not allow SSSD to retrieve the hashes from the remote server. Instead, SSSD gets the password from the user and tries it against the authentication source. If it succeeds, SSSD will salt and hash the successful password and store it locally.

So the only passwords that could be leaked are from those who have previously performed a successful login on the local system.

Also note that switching to `cache_credentials = False` is insufficient to mitigate this, as it will not remove the existing cached credentials from the system; it will only stop new ones from being added to the cache. If you want to purge the cache, you must remove the cache file (I don't think the `sss_cache` tool can eliminate the cached credentials today, but that might be a good RFE for the future).

Comment 19 Cedric Buissart 🐶 2017-10-10 15:50:39 UTC
Mitigation:

It is possible to disable manually credential caching :
* Stop the sssd service
* Delete the cache (rm -f /var/lib/sss/db/* /var/log/sssd/*) or manually remove the hashes for the database
* In the sssd configuration file, change cache_credentials to False for each domains
* start the sssd service again

However, tools such as realmd & ipa-client-install might enable credential caching, and should be used with care.

Comment 20 Cedric Buissart 🐶 2017-10-10 15:53:19 UTC
In reply to comment 18:
> (In reply to Cedric Buissart from comment #17)
> > (In reply to Simo Sorce from comment #16)
> > > Cedric in the doc text add something to the effect "but only if that data
> > > was previously locally cached", note that passwords hases are not always
> > > cached locally even if other user info is.
> > 
> > but can't an attacker simply try to log in once as the target to force hash
> > to be cached locally ?
> 
> No, the way that password-caching works in SSSD does not allow SSSD to
> retrieve the hashes from the remote server. Instead, SSSD gets the password
> from the user and tries it against the authentication source. If it
> succeeds, SSSD will salt and hash the successful password and store it
> locally.
> 
> So the only passwords that could be leaked are from those who have
> previously performed a successful login on the local system.
Thanks! updated description & doc.

Comment 24 Salvatore Bonaccorso 2017-10-11 18:49:56 UTC
Hi Cedric
(In reply to Cedric Buissart from comment #15)
> (In reply to Salvatore Bonaccorso from comment #4)
> > Is there a reference to "upstream" issue and fixing commits?
> 
> We're still waiting for the patch to be committed. I ll drop a link here as
> soon as it is done. 
> 
> Versions prior to sssd-1.12.0 are not affected (affected commit: 7ecb5ae)

Thanks a lot!

Comment 25 Fedora Blocker Bugs Application 2017-10-24 12:54:24 UTC
Proposed as a Freeze Exception for 27-final by Fedora user lslebodn using the blocker tracking app because:

 sssd-1.15.3-5.fc27 contains only fix[1,2] for "moderate" CVE-2017-12173.

As you can see it in bodhi update[2]. It would get to stable before final freeze(8 days ago). But I did not notice a notification from bodhi.
And update was pushed to batched -> stable to late.
 
[1] https://src.fedoraproject.org/rpms/sssd/c/4a8ad4c17440622010ce0dc138ca2042eb3eadb1?branch=f27
[2] https://bodhi.fedoraproject.org/updates/FEDORA-2017-39c5f8cd7e

Comment 26 Stephen Gallagher 2017-10-24 13:04:21 UTC
+1 FE

It's a security fix in critical software and contains no other changes, so the risk is minimal.

Comment 27 František Zatloukal 2017-10-24 13:12:27 UTC
+1 FE

Fix for CVE...

Comment 28 Lukas Brabec 2017-10-24 13:12:52 UTC
+1 FE

Comment 29 Kamil Páral 2017-10-24 15:05:47 UTC
Marking as accepted freeze exception.

Comment 30 Andrej Nemec 2017-10-25 08:20:47 UTC
(In reply to Kamil Páral from comment #29)
> Marking as accepted freeze exception.

Please, use to relevant fedora tracking bug for these kind of information, we need the whiteboard syntax to stay within our vulnerability process needs.

Comment 31 Lukas Slebodnik 2017-10-25 08:31:58 UTC
(In reply to Andrej Nemec from comment #30)
> (In reply to Kamil Páral from comment #29)
> > Marking as accepted freeze exception.
> 
> Please, use to relevant fedora tracking bug for these kind of information,
> we need the whiteboard syntax to stay within our vulnerability process needs.

Sorry it was my fault.

I used wrong BZ when proposing for f27 exception on page.
https://qa.fedoraproject.org/blockerbugs/propose_bug

Comment 32 Kamil Páral 2017-10-25 13:47:45 UTC
(In reply to Lukas Slebodnik from comment #31)
> Sorry it was my fault.
> 
> I used wrong BZ when proposing for f27 exception on page.

Well then, I'll remove the nomination of this bug and please nominate the correct bug, if you want to push it through freeze. Please note that our tools rely on the whiteboard, so if you want to use it exclusively for your purposes, you need to create a new bug for the FE nomination.

Comment 33 Lukas Slebodnik 2017-10-25 16:13:21 UTC
(In reply to Kamil Páral from comment #32)
> (In reply to Lukas Slebodnik from comment #31)
> > Sorry it was my fault.
> > 
> > I used wrong BZ when proposing for f27 exception on page.
> 
> Well then, I'll remove the nomination of this bug and please nominate the
> correct bug, if you want to push it through freeze. Please note that our
> tools rely on the whiteboard, so if you want to use it exclusively for your
> purposes, you need to create a new bug for the FE nomination.

There are two bugs attached in bodhi update
https://bodhi.fedoraproject.org/updates/FEDORA-2017-39c5f8cd7e

This one and fedora version of CVE-2017-12173 (BZ1499354)
And I had to copy wrong one when I created request for f27 freeze exception.

Comment 35 Kurt Seifried 2017-11-04 11:40:05 UTC
Statement:

This issue affects the versions of sssd as shipped with Red Hat Satellite version 6.0. More recent versions of Satellite no longer ships sssd. This issue is not currently planned to be addressed in future updates. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.

Comment 36 errata-xmlrpc 2017-12-05 01:11:43 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2017:3379 https://access.redhat.com/errata/RHSA-2017:3379

Comment 37 errata-xmlrpc 2018-06-19 04:49:48 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6

Via RHSA-2018:1877 https://access.redhat.com/errata/RHSA-2018:1877


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