See how fedorahosted compares to other vendors in security performance
File descriptor leak in cronie 1.4.8, when running in certain environments, might allow local users to read restricted files, as demonstrated by reading /etc/crontab.
Sebastian Krahmer discovered that it was possible to make sssd hang forever inside a loop in the pamparseindatav2() function of SSSD's PAM responder by using a carefully crafted packet to sssd. This could be exploited by a local attacker to crash sssd and prevent other legitimate users from logging into the system.
Acknowledgements:
Red Hat would like to thank Sebastian Krahmer for reporting this issue.
Race condition was found in the way vixie-cron and cronie used to set up timestamp (modification time) for crontab file of the individual user by editing the file. A local attacker could use this flaw to conduct unintended changes of timestamp (modification time) value against various system files, potentially leading to denial of their service.
Acknowledgements:
Red Hat would like to thank Dan Rosenberg for reporting this issue.
Heap-based buffer overflow in textbox.c in newt 0.51.5, 0.51.6, and 0.52.2 allows local users to cause a denial of service (application crash) or possibly execute arbitrary code via a request to display a crafted text dialog box.
Description of problem: If a user is added to the SSSD BE database, but no password is set. The user can ssh to the SSSD configured client and enter any password and get in.
TESTED CONFIGURATION
system-auth configuration:
auth required pamenv.so auth sufficient pamfprintd.so auth sufficient pamunix.so nullok auth sufficient pamsss.so usefirstpass auth requisite pamsucceedif.so uid >= 500 quiet auth required pamdeny.so
account required pamunix.so brokenshadow account sufficient pamsss.so account sufficient pamlocaluser.so account sufficient pamsucceedif.so uid < 500 quiet account required pampermit.so
password requisite pamcracklib.so tryfirstpass retry=3 password sufficient pamunix.so sha512 shadow nullok useauthtok password sufficient pamsss.so usefirstpass password required pamdeny.so
session optional pamkeyinit.so revoke session required pamlimits.so session [success=1 default=ignore] pamsucceedif.so service in crond quiet useuid session sufficient pamunix.so session required pamsss.so
sssd configuration:
[services] description = Local Service Configuration activeServices = nss, pam reconnectionretries = 3
[services/nss] description = NSS Responder Configuration filterGroups = root filterUsers = root debug-level = 4
[services/dp] description = Data Provider Configuration debug-level = 4
[services/pam] description = PAM Responder Configuration
[services/monitor] description = Service Monitor Configuration
[domains] description = Domains served by SSSD domains = LOCAL
[domains/LOCAL] description = LOCAL Users domain enumerate = 1 minId = 1000 maxId = 1010 legacy = FALSE magicPrivateGroups = TRUE provider = local
Version-Release number of selected component (if applicable): sssd-0.4.1-1.fc11.i586
How reproducible: always
Steps to Reproduce: 1. yum install sssd 2. edit system-auth (as above) and nsswitch.conf as required 3. modify /etc/sssd/sssd.conf as above 4. service start sssd 5. sssuseradd -u 1000 -h /home/myuser -b /bin/bash myuser 6. from a remote machine ssh to the sssd client machine sssh myuser 7. at password prompt enter anything you would like
Actual results: ssh session is successful and user allowed machine access
Expected results: password to be denied, user not allowed machine access
Additional info:
If you subsequently set the user password on the sssd client machine (passwd myuser) a bad password denies access and the correct password allows access.