Fedora has issued an advisory on October 19: http://lists.fedoraproject.org/pipermail/package-announce/2012-November/091108.html This is fixed upstream in 5.41 (in Cauldron). Patched packages uploaded for Mageia 1 and Mageia 2. Advisory: ======================== Updated xlockmore packages fix security vulnerability: A denial of service flaw was found in the way xlockmore, X screen lock and screen saver, performed passing arguments to underlying localtime() call, when the 'dlock' mode was used. An attacker could use this flaw to potentially obtain unauthorized access to screen / graphical session, previously locked by another user / victim (CVE-2012-4524). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-4524 http://lists.fedoraproject.org/pipermail/package-announce/2012-November/091108.html ======================== Updated packages in core/updates_testing: ======================== xlockmore-5.32-1.1.mga1 xlockmore-gtk2-5.32-1.1.mga1 xlockmore-5.38-2.1.mga2 xlockmore-gtk2-5.38-2.1.mga2 from SRPMS: xlockmore-5.32-1.1.mga1.src.rpm xlockmore-5.38-2.1.mga2.src.rpm
Whiteboard: (none) => MGA1TOO
I assume this is referring to "xlock -mode dclock", as there is no mode called dlock mode, and the patches in https://bugzilla.redhat.com/attachment.cgi?id=629482&action=diff are referring to dclock.c, however I'm unable to reproduce the crash in either Mageia 1 i586 or Mageia 2 x86-64. Haven't tested the update yet. Any idea how to trigger the crash?
CC: (none) => davidwhodgins
Thanks. We'll have to change dlock to dclock in the final advisory. Reading the post here: http://www.openwall.com/lists/oss-security/2012/10/17/10 I'm guessing it would require a user with access (remote or local) having the ability to change the time on the machine (depending on the configuration, this is sometimes allowed by KDE or drakconf I think), which could then cause xlock to crash for another user logged into the machine (probably locally, but possibly a remote X session). I'm also guessing that the attack is to change the date to a large value far in the future. If that's it, shouldn't be hard to reproduce.
Very strange. After locking the terminal using "xlock -mode dclock", switching to tty2, logging in as root and running date -s "2044-12-31 16:21:42", instead of crashing xlock, it activated the screensaver on tty2, locked with the tty1 user password. Trial and error shows the max date that can be set is date -s "2262-04-11 19:47:15" While I have not been able to get xlock on tty1 to crash, I have seen behavior that should not be happening. I'll test the update tomorrow.
Testing complete Mageia 1 and 2, i586 and x86-64. Could someone from the sysadmin team push the srpm xlockmore-5.38-2.1.mga2.src.rpm from Mageia 2 Core Updates Testing to Core Updates and the srpm xlockmore-5.32-1.1.mga1.src.rpm from Mageia 1 Core Updates Testing to Core Updates. Advisory: Updated xlockmore packages fix security vulnerability: A denial of service flaw was found in the way xlockmore, X screen lock and screen saver, performed passing arguments to underlying localtime() call, when the 'dclock' mode was used. An attacker could use this flaw to potentially obtain unauthorized access to screen / graphical session, previously locked by another user / victim (CVE-2012-4524). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-4524 http://lists.fedoraproject.org/pipermail/package-announce/2012-November/091108.html https://bugs.mageia.org/show_bug.cgi?id=8008
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugsWhiteboard: MGA1TOO => MGA1TOO MGA2-64-OK MGA2-32-OK MGA1-64-OK MGA1-32-OK
Update pushed: https://wiki.mageia.org/en/Support/Advisories/MGASA-2012-0328
Status: NEW => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED