A CVE has been assigned for a security issue in slock: http://openwall.com/lists/oss-security/2016/08/18/24 This is yet another case of an application failing to account for the fact that crypt() can return NULL (due to a change in glibc a few years ago). A suggested solution was described in the thread, but no actual patch was given.
CC'ing Dan who last updated this and may have an interest.
CC: (none) => danWhiteboard: (none) => MGA5TOO
Assigning to all packagers collectively, since there is no registered maintainer for this package.
CC: (none) => marja11Assignee: bugsquad => pkg-bugs
Fedora has issued an advisory for this on September 9: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/RZPEJQNVODYSI4WQXM5GQKXRO7TPK2VG/ Patched packages uploaded for Mageia 5 and Cauldron. Dan, there is a version 1.3 available if you're interested in updating it again. Advisory: ======================== Updated slock packages fix security vulnerability: The slock utility is susceptible a crash when verifying a password for a user without a valid shadow hash entry (CVE-2016-6866). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6866 https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/RZPEJQNVODYSI4WQXM5GQKXRO7TPK2VG/ ======================== Updated packages in core/updates_testing: ======================== slock-1.1-5.1.mga5 from slock-1.1-5.1.mga5.src.rpm
Version: Cauldron => 5Assignee: pkg-bugs => qa-bugsWhiteboard: MGA5TOO => (none)
Trying x64, but to others - beware. I can find no useful information about how to use it. http://tools.suckless.org/slock/ says "Simple X display locker. This is the simplest X screen locker we are aware of" and "Slock is configured via config.h" and "Slock can be started after a specific period of user inactivity using xautolock. The command syntax is: xautolock -time 10 -locker slock Simpler alternatives to xautolock might be xssstate or xss". None of these 3 x commands are installed on my box. There is no man entry for slock, installed pre-update slock-1.1-5.mga5 . Do NOT try (as I did) # slock which immediately blanked the screen, and I had no idea how to get out of that. No likely keystrokes did anything. Had to do Ctrl/Alt/Backspace/Backspace to re-start X. Worse, after re-logging in, response to the root password after '$ su' has become extremely long. I suspect the [shadow] password system was affected. I hope this is not permanent.
CC: (none) => lewyssmith
(In reply to Lewis Smith from comment #4) > Trying x64 > Do NOT try (as I did) > # slock > which immediately blanked the screen, and I had no idea how to get out of > that. No likely keystrokes did anything. Had to re-start X. > Worse, after re-logging in, response to the root password after '$ su' has > become extremely long. I suspect the [shadow] password system was affected. > I hope this is not permanent. Luckily, it is not. After a re-boot, this aspect is back to normal.
MGA5-32 on Acer D620 Xfce No installation issues. Google is your friend: typed in "slock help" and first item found says: "in blank screen type your user password". There is no prompt. Tested that way and behaves OK.
CC: (none) => herman.viaene
Whiteboard: (none) => MGA5-32-OK
(In reply to Herman Viaene from comment #6) > "in blank screen type your user password". There is no prompt. Excellent, thank you Herman. You would think that would be on its site... Tested M5 x64 real h/w. BEFORE update: slock-1.1-5.mga5 $ slock works as noted above. The blanked screen turns bluish when password is typed. AFTER update: slock-1.1-5.1.mga5 Same behaviour; OK. Update validated, advisory to follow.
Keywords: (none) => validated_updateWhiteboard: MGA5-32-OK => MGA5-32-OK MGA5-64-OKCC: (none) => sysadmin-bugs
Advisory uploaded.
Whiteboard: MGA5-32-OK MGA5-64-OK => MGA5-32-OK MGA5-64-OK advisory
An update for this issue has been pushed to the Mageia Updates repository. http://advisories.mageia.org/MGASA-2016-0308.html
Status: NEW => RESOLVEDResolution: (none) => FIXED
*** Bug 19838 has been marked as a duplicate of this bug. ***
CC: (none) => youpburden