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.
Acknowledgments: Name: Christian Heimes (Red Hat)
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.
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.
Created sssd tracking bugs for this issue: Affects: fedora-all [bug 1660688]
Could you tells us what specific commit fixed CVE-2018-16883?
(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.
Thank you for the quick response.
Statement: The information exposed by this vulnerability is typically not highly sensitive. By default, it is only those fields returned by getpwent() and getgrent().