xscreensaver bug?

["Eugene M. Kim 김민성"]

(Redirected to chat@)

Terry Lambert wrote:

>"Eugene M. Kim" wrote:
>
>>Validating a root password is possible with other means in many cases, if not always.  OpenSSH sshd is a good example.  Even with PermitRootLogin set to no, the attacker can differentiate whether the password has been accepted or not.
>>
>
>That's because the software in question sucks, not because it's a
>natural property of all such software.
>

Sorry, but no matter how much sshd sucks, we currently have it.  It's 
even enabled by default. =)

The assumption that unprivileged users won't be able to verify the root 
password is therefore dangerous, unless the administrator took 
additional security precautions (e.g. disabling sshd).

>>If attacker is able enough, he could also run a hacked version of Xnest on port 6000+N and the real xscreensaver on :N.0 for a suitable N.  Attacker would feed the real xscreensaver with the captured password and see if the real xscreensaver releases the server grab.
>>
>
>Yeah, and any user on the system could put up a trojan that put up a window that pretended to be the login screen instead of a screen saver, since that would be much easier, and harvest passwords that
>way, instead, after pretending the first login failed.
>
>I don't really see your point... any time you have more than one user using the same console, it's possible to create a trojan.
>

My point is that the root password, or any replayable password, 
shouldn't be entered on such insecure terminals.  (Did someone say... 
OPIE? XD)

All in all, it does seem that the feature of xscreensaver (that lets the 
root password to unlock someone else's xscreensaver) is dangerous, 
because there's no such thing as someone else's xscreensaver that root 
can trust.

Eugene

P.S. The `Press Ctrl-Alt-Del to log on' feature of Windows 2000/XP is 
indeed one cool security feature.  It assures the user that the login 
window is not an unprivileged trojan. =)