Red Hat Bugzilla – Bug 11165
Gnome panel, ssh can allow remote non-root users to halt,reboot
Last modified: 2008-05-01 11:37:55 EDT
If you have a headless server that serves remote X sessions via xdm, kdm, gdm, etc., it's possible for an unprivileged Gnome desktop user to shutdown or reboot the server. Here's the formula: 1. ssh into the server, allowing ssh to establish a secure forwarded X connection. If no one else is using display number 0, you'll end up with a DISPLAY value of "host:0.0". 2. Invoke "Xnest -query localhost" on the remote machine. 3. Log in, starting a Gnome session. 4. From the Gnome panel, select "logout". You'll be presented with the option of shutting down or rebooting the server. This seems to work because Gnome is using the DISPLAY value to decide whether to present these extra options, and assuming that if it's host:0.0 you're sitting at the console.
I just noticed that this doesn't depend on the display number. It seems to work as long as the display node is the local host.
Hmm - interesting. Perhaps /etc/security/console.perms should only consider :0.0 a console display, and we should ensure gdm only allocates from :1.0 and up. It definitely seems buggy to allow a user to log in remotely using gdm, then give that user full console permissions!
Does PAM actually allow you to reboot if you click on the options, or is the bug just that non-working reboot options are presented?
Yes, it actually works. I just tried it again to verify. If I do the following (where 'elvis' is my generic unprivileged user account): ssh remotehost -l elvis Xnest -query localhost :1 I can log in, select Logout -> reboot and reboot the machine. Before the reboot happens, a dialog box pops up asking for elvis's password. After typing the password, the machine reboots. Note the ":1" in the example above. If other people have used Xnest on this machine before, you may need to fish around for an unused display number. This is true because Xnest doesn't clean up after itself, and leaves behind 2 lock files owned by the last person who used Xnest on a particular display number. The files have names like /tmp/.X1-lock and /tmp/.X11-unix/X1.
OK, for me I only get the reboot/shutdown options if I'm _also_ logged in at the console. That is, the consolehelper stuff just checks whether the user is logged in at the console; it doesn't check whether they are actually using the console in order to do the reboot. If I log out of all X sessions and virtual terminals at the console, then I can't reboot via the Xnest. If you can reboot via ssh/Xnest with no open console sessions, then please reopen the bug (and try to send more info, I can't reproduce this behavior).
I think I can guess where our configurations differ. I'm using kdm as the display manager, instead of gdm. I've just tried the experiment again with gdm, kdm and xdm. With Kdm and xdm, gnome displays the behavior I've described, but with gdm it doesn't. (Gdm won't even display in the Xnest window when Xnest is invoked this way.) So, it looks like this is mainly only a problem for folks who use kdm or xdm, and allow their users to use gnome as one of the available desktop environments. There's still a subset of this problem that effects gdm users, though. Above, hp@redhat.com said: "That is, the consolehelper stuff just checks whether the user is logged in at the console; it doesn't check whether they are actually using the console in order to do the reboot." This implies that all the remote intruder needs to do (once he's sniffed or cracked a legitimate user's password) is wait until the user logs on at the console. Is there a way to turn off this reboot/shutdown functionality for all users? I'm not comfortable with unprivileged users (even legitimate ones) being able to shut down machines from anything other than a real console session.
User shutdown capabilities can be disabled by removing the "usermode" package, which provides the wrappers that allow non-root users to call the shutdown command in its multiple guises. Please reconfigure your sshd server to include "X11DisplayOffset 10" until I get a good fix into pam_console.
Upon closer examination, this can be exploited by telnet users as well, so just ignore that SSH-specific directive. I *think* that adding a check to pam_console to make sure that the tty being passed in is either a character device or a socket owned by "root" will stop this from happening. A test package whith this change (pam-0.72-16) is going out to http://people.redhat.com/nalin/; if anyone wants to give it a spin and verify the problem as fixed before I look to releasing it as an errata, that would be a good thing. The problem really is a misconfiguration in /etc/security/console.perms, but there's no simple way to have the configuration be correct without knowing whether a display manager is running or not....
Pushing this one out as an errata.
Thanks for looking into this. One final observation: under KDE, the shutdown/reboot buttons are displayed on the KDM login window. Since KDM (and GDM) knows whether it's running at the console or not, the issues described above don't arise. Would this be a possible solution for Gnome, too?