GNOME Bugzilla – Bug 168809
No way to prove GDM authenticity/Spoofing Protection [ trusted path , secure attention key ]
Last modified: 2018-05-24 10:18:57 UTC
In a large public enviroment, it would be trivial and desireable to spoof the GDM login screen with a modified user binary, or complex script and access to the current GDM theme (usually publicly accessable anyway) in order to obtain user logins and passwords. For example: 1) Start trojan GDM as yourself. 2) Users attempt to log in. 3) Trojan GDM dumps usernames and passes to a text file. 4) Trojan GDM owner presses custom key combo or username/pass to quit GDM In a large company or university, at a public termnial, or other such enviroment this could be a bit hazardous. While yes, one solution is to always press ctrl+alt+bkspc, this can be faked if "no special keys" (if that's the proper option) in X is enabled, by a short resolution change. Now, I'll get grape shot with a cannon for this part, but mind, it's merely an example. Windows 2000 prevents this by requiring Ctrl+Alt+Del at login, and having the key combination explicitly bound by the system (thus preventing a user application from faking the login screen). Pressing it while logged in takes you to a sort of user dialoge box labeled "Windows Security". It may be a good idea to implement something like this, a key combo bound explicitly by GDM (if possible).
I don't think I understand exactly what you are suggesting. I'm also unsure if the fix you are suggesting is really a fix to gdm2 or a fix to the way gdm2 is integrated into various distributions. If the latter, I'm not sure this is the right place to report the bug. I use Windows XP and do not need to hit any special keys before seeing the login screen. Could you explain a bit more how requiring a key combination would resolve this problem? Further, it should work in "New Login"/"New Login in a Nested Window" (flexi) mode, and XDMCP mode, which might complicate things. I think the only way this sort of hack could be done is if a user had physical access to the machine and could run the trojan program and leave it running for the next person. Unless the machine has foolishly set up "xhost +", remote processes shouldn't be able to control the console. This issue could be resolved by setting up the system to automatically logout or lockscreen users who haven't been active at their terminal for a minute or so - which seems appropriate for the public terminal environments you describe. Also, at a public terminal, it would be somewhat foolish to allow users who log in to have write access to the filesystem (so they have the ability to download/build/install/run a trojan).
You probably use XP home edition. I think in Pro editon, there's a security option to turn it on. From what I understand about flexi mode, and XDMCP mode, flexi mode/window is used mostly for testing or users who which to use a different account under the same session (so no authenticity is nessecary) and flexi mode/new terminal just starts another X process. As for XDMCP, there's no need to prove authenticity as that relies on the remote user trusting the remote X display, and since no one but root can open ports <1024, that's not as much of an issue. Auto logout and lock is a bit difficult to enforce, since I belive xscreensaver is easily user controlled (and it's easy to fake not being idle). The issue of being able to download/build/install could be as simple as a static binary, or very well made perl/python/whatever script, further, GDM should be secure on it's own, by default, (or with a little adjustment) without requiring the administrator to prevent /home/* execution (which is a moot point anyway with perl and the like). As I said, the idea would be to use a key combination un bindable by the user, bound only by GDM to validate that it truly is GDM. This isn't so much of an integration issue, as it is a feature missing from GDM. As for the forthcoming "X is insecure, don't use it." arguements, the idea should be to make it as secure as possible, especially for large public use.
It seems that the feature you are asking for is reasonable. I only suggest some ways that systems could be made reasonably secure (setting up the system to logout inactive users, for example), not allowing users write access to the filesystem, etc. when the computer is used in public terminal settings. However, it seems that in order to move forward with this sort of change, it would involve defining the right key combination and also making it possible to define a key combination that is unbindable by the user in the session (for both GNOME and KDE). Does GNOME and KDE support this? If there is a specification for how this should work, I'll be happy to make sure gdm2 supports it.
Sadly IANAProgrammer, just a sysadmin, and thought it might be a good idea for a feature. Modifying AT-SPI slightly, or giving it a fixed binding of some kind might be one way of doing it, the only trick from there would be making sure said binding was forced upon the user sessions. Not sure what KDE uses to bind keys, but some co-operation with them might get the same results. XEvIE might provide a better way to do this when they have multi-client support in the future There's probably much better solutions than I can think of though. Sorry if it's a bit much of a puzzle.
I've been thinking about this a bit lately and I think this is a valid concern. Especially so given the way that we start up flexiserver greeters on new VTs and there is really not one canonical greeter to use. If we had a key combination that would always bring you to the VT running a greeter that would be a nice solution I think. This might be possible if we implemented something like what I describe in bug 343539 comment 2.
For lamers making simple full-screen non-priviledged applications plain old non-modified ctrl-alt-del oughta be enough. When you go further to more sophisticated scenarios you run fast into problems. The claim made by Microsoft that nothing can spoof the ctrl-alt-del has been proven wrong. Although the idea sounds good it can not even theory ever work reasonably reliably. If you are in with administrative priviledges you can always find a way to elevate your rights to re-catch those couple magic keys. That is true at least until you start using some TPM sort of hardware solution to guard dog the main operating system and even then the reliability can be doubted to some degree. Spooding loging screens is definitely a valid concern but it is also something that can not be thwarted at the symptom stage. It should be handled at the cause which means blocking the original attack vectors how the perpetrator got elevated rights. In really demanding environments if I really had to build something like this I would use something like SecurID + a backend server elsewhere and some rootkit alike security application taking care (well, tbh it can never be sure but it can make going around it a tedious task) that only the correct application can accomplish the whole dance required to get in. Or some other authentication type that does not rely primarily on passwords that are vulnerable to catching. (S/Key, smart cards, ... ?) Luckily for us the PAM can do those. It's the most viable way for solving the root problem described in this bug report, and doesn't even require anything from Gnome.org, at least as far as I can see. I would make this WONTFIX for sanity reasons.
"If you are in with administrative priviledges you can always find a way to elevate your rights to re-catch those couple magic keys." If you are in with administrative privileges, you already have complete access to the system, thus the login screen spoofing itself is unlikely to happen. The original question is about a fake login screen being displayed by an *unprivileged* account, which the "secure attention key" would prevent. It's sad that this report has been ignored for so many years. Various one-time-password protocols aren't a good replacement, since the attacker could still use the password for their own purposes.
I do think GDM should eventually get a trusted path / secure attention key sequence, but I don't think it will happen until wayland.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gdm/issues/1.