*** This bug is a security vulnerability ***
You have been subscribed to a public security bug by Jamie Strandboge
(jdstrand):
Binary package hint: gdm
In Hardy (was ok in Gutsy and previous releases) with gdm 2.20.x, if
VTAllocation=false in gdm.conf (i.e. to allow to run a permanent Xvfb
server for several days or at least enough time to fix heavy bugs in a
user's profile while letting the user work paralelly on it's normal
display), at GDM startup in the middle of the boot sequence, display :0
starts on tty1 (or 2, I don't remember) instead of tty7, leaving the
user just the time to type half of his password, then the keyboard
suddenly stops responding while the mouse continues to behave gently on
the greeter (login) screen.
I suspect that the reason for this is that the boot sequence reaches its
end and that a getty spawned (so late, why ?) on the same tty1 (or 2),
so that, now, all the keystrokes silently end up on the hidden tty
(actually, if you switch vt, using chvt being logged from another host,
you can even see them written on the dumb tty, including his password,
of course, in white on black ;-)
The solution is pretty obvious: put VTAllocation=true again in gdm.conf
and stop using Xvfb if you did (there are anyway other means to
graphically work on a user's workstation while letting the user work as
well at the same time) or write an XVfb wrapper which ignores the 'vt
0x' options and pass the other options to Xvfb.real.
I filed a bug upstream requesting that 'vt xy' is not inserted anymore
on command lines of Xvfb servers, whatever the value of VTAllocation
would be, so that one can keep this option to true even when one wishes
to temporarily use an Xvfb server: this is 538625. But, anyway, I
thought I'll share this issue with you as well because the symptoms are
highly surprising, and it looks like there are a lot of reports of
keyboards not responding, which might be related (why not do an openvt
of tty1 to 6 very early in the boot sequence, even if getty's start
later, so that one is sure about the absence of conflicts in tty
allocation ?)
Just in case, I tag this as a security issue, because it allows with an
easy manipulation on a machine prepared for maintenance to decrypt a
user's password ( actually there are other means than the one described
above to switch to the vt showing the decrypted password without being
able to become root) but the chances of occurences of such a situation
appear to me very, very low, so, feel free to remove this tag.
Cheers.
** Affects: gdm (Ubuntu)
Importance: Undecided
Status: New
--
Keyboard suddenly stops reacting on login screen
https://bugs.launchpad.net/bugs/240456
You received this bug notification because you are a member of Ubuntu Bugs,
which is a direct subscriber.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
