Red Hat Bugzilla – Bug 1498173
CVE-2017-12173 sssd: unsanitized input when searching in local cache database
Last modified: 2018-07-09 18:17:07 EDT
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.
Is there a reference to "upstream" issue and fixing commits?
Created sssd tracking bugs for this issue: Affects: fedora-all [bug 1499354]
Acknowledgments: Name: Sumit Bose (Red Hat)
(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)
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.
(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 ?
(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).
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.
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.
Patch is available at https://pagure.io/SSSD/sssd/c/1f2662c8f97c9c0fa250055d4b6750abfc6d0835?branch=master
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!
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
+1 FE It's a security fix in critical software and contains no other changes, so the risk is minimal.
+1 FE Fix for CVE...
+1 FE
Marking as accepted freeze exception.
(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.
(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
(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.
(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.
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/.
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
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