|Summary:||CVE-2018-16883 sssd: Information leak in infopipe due to an improper uid restriction|
|Product:||[Other] Security Response||Reporter:||Doran Moppert <dmoppert>|
|Component:||vulnerability||Assignee:||Red Hat Product Security <security-response-team>|
|Status:||NEW ---||QA Contact:|
|Version:||unspecified||CC:||abokovoy, apo, cheimes, grajaiya, jhrozek, lslebodn, mzidek, pbrezina, rcritten, rharwood, sbose, security-response-team, ssorce, sssd-maint, tscherf|
|Fixed In Version:||sssd 2.0.0||Doc Type:||If docs needed, set a value|
sssd, versions 1.13.0 to before 2.0.0, did not properly restrict access to the infopipe according to the "allowed_uids" configuration parameter. Sensitive information could be inadvertently disclosed to local attackers if it was stored in the user directory.
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:||1660687, 1660688|
Description Doran Moppert 2018-12-17 04:24:55 UTC
It was discovered that sssd versions prior to 2.0.0 did not properly restrict access to the infopipe according to the "allowed_uids" parameter. If sensitive information were stored in the user directory, this could be inadvertently disclosed to local attackers.
Comment 1 Doran Moppert 2018-12-17 04:24:57 UTC
Acknowledgments: Name: Christian Heimes (Red Hat)
Comment 3 Doran Moppert 2018-12-17 05:39:38 UTC
Mitigation: This vulnerability is only exposed if the infopipe service is enabled (enabled by default in Red Hat Enterprise Linux 7, disabled by default in Red Hat Enterprise Linux 6), and `[ifp].allowed_uids` is relied upon to protect sensitive information in the user directory.
Comment 4 Doran Moppert 2018-12-19 01:13:54 UTC
This flaw was first present in sssd upstream release 1.13.0, and fixed in 2.0.0 as the result of re-factoring related code.
Comment 5 Doran Moppert 2018-12-19 01:23:15 UTC
Created sssd tracking bugs for this issue: Affects: fedora-all [bug 1660688]
Comment 7 Markus Koschany 2018-12-20 14:47:52 UTC
Could you tells us what specific commit fixed CVE-2018-16883?
Comment 8 Jakub Hrozek 2018-12-20 19:26:24 UTC
(In reply to Markus Koschany from comment #7) > Could you tells us what specific commit fixed CVE-2018-16883? yes, but it's not going to be useful: fbe2476a3dd9be83ffa85c29dca26f734618d72d As you can see, the CVE was fixed 'by accident' as part of a large refactoring. We'll provide fixes for this CVE for older branches in early January. Nonetheless, by default, the ifp interface only exposes the same attributes getpw* and getgr* expose, so I don't think the issue is really critical.
Comment 9 Markus Koschany 2018-12-20 19:49:07 UTC
Thank you for the quick response.
Comment 10 Doran Moppert 2019-10-28 23:01:52 UTC
Statement: The information exposed by this vulnerability is typically not highly sensitive. By default, it is only those fields returned by getpwent() and getgrent().