Bugzilla – Bug 62001
VUL-0: CVE-2004-2658: normal user can fake local login for resmgr
Last modified: 2021-10-04 10:13:39 UTC
A normal user who is logged in from remote can tell resmgr that he is logged in via tty1 (or via :0). By the way: Many thanks to Daniel and Marcus who explained the resmgr to me! Without their help I would have never been able to do this. I think this is only a minor bug because I think only very few useres understand how the resmgr works ;-)
<!-- SBZ_reproduce --> Log in as normal user via ssh and then execute on the remote machine /sbin/resmgr login <user> tty1 If <user> is different from the user who executes the command, then it is not possible and /sbin/resmgr shows the message status code 502 server message follows: you are not allowed to do this A log what I did: (9.2-final is installed on nelson and on lavoisier) ----------------------------------------------------------------------- jsmeix@nelson:~> ssh jsmeix@lavoisier ... jsmeix@lavoisier:~> /sbin/resmgr list status code 200 server message follows: no devices available jsmeix@lavoisier:~> /sbin/resmgr login jsmeix tty1 success jsmeix@lavoisier:~> /sbin/resmgr list rw-- /dev/audio rw-- /dev/mixer rw-- /dev/dsp rw-- /dev/sequencer rw-- /dev/video rw-- /dev/modem rw-p /dev/cdrom rw-p /dev/cdrom1 rw-- /dev/cdrecorder rw-p /dev/dvd rw-p /dev/dvd1 rw-- /dev/sr0 rw-- /dev/sr1 rw-- /dev/sr2 rw-- /dev/sr3 rws- /dev/scanner r--- /dev/console rw-- /dev/pilot rw-- usb:any -----------------------------------------------------------------------
Only if you grant the desktop by default. meissner@westernhagen:~> /sbin/resmgr login meissner foobar success meissner@westernhagen:~> /sbin/resmgr list status code 200 server message follows: no devices available meissner@westernhagen:~>
<!-- SBZ_reopen -->Reopened by meissner@suse.de at Fri Oct 8 13:00:01 2004, took initial reporter jsmeix@suse.de to cc
meissner@westernhagen:~> /sbin/resmgr login meissner tty1 success meissner@westernhagen:~> /sbin/resmgr list rw-- /dev/audio rw-- /dev/mixer rw-- /dev/dsp rw-- /dev/sequencer rw-- /dev/video rw-- /dev/modem rw-p /dev/cdrom rw-p /dev/cdrom1 rw-- /dev/cdrecorder rw-p /dev/dvd rw-p /dev/dvd1 rw-- /dev/sr0 rw-- /dev/sr1 rw-- /dev/sr2 rw-- /dev/sr3 rws- /dev/scanner r--- /dev/console rw-- /dev/pilot rw-- usb:any hmmmm
hmm, not good. Olaf?
static void cmd_login(struct conn *conn, int argc, char **argv) { ... if (conn->cred.uid) { user = conn->ruser; if (strcmp(user->name, name)) { msg_log("User %s attempted to log in as %s\n", user->name, name); respond(conn, MSG_DENIED, "you are not allowed to do this"); return; } .. go on an do the login So the user is allowed to login himself/herself. This was a hack added explicitly to support sshd, because sshd runs the PAM session module as the user, not as root... (at least in privsep mode - does it still do this?) This is definitely a problem, because everyone could create a session for himself with a tty of ":0". But at the moment I don't know how to solve it (unless someone tells me current sshd runs the pam_resmgr session functions as root)
Perhaps the following proposal may lead to a solution: If I understand resmgr correctly then it works at the moment as follows: User logs in via console or KDM/XDM (or ssh) => PAM is started => depending on PAM config pam_resmgr.so is started => pam_resmgr.so does something like "resmgr login <user> :0" I think the last step does two seperated tasks mixed up in one: I think the first task is that PAM must notify resmgr that a user has logged in via a particular login-type (in resmgr the login-type is called "tty") but I think that it is a seperated second task what resmgr does after it was notified. I think any user should be allowed to notify resmgr about a login. I think any PAM module should notify resmgr about any login in any case. Then resmgr should decide what to do depending on what is configured for this login-type in /etc/resmgr.conf. I.e. there are new options needed in /etc/resmgr.conf to configure what resmgr should do when it was notified about a particular login. At the moment this is done by configuring PAM but I think it is not good to mix up PAM config and resmgr config. An example: I log in via console on my workstation. Then I start X by calling "startx -- -dpi 75 & exit". After this I am no longer logged in via console. I am only logged in via pts/* Therefore I cannot get any access via resmgr regardless what I set up in /etc/resmgr.conf because resmgr is not notified about a login via pts/*. I would like to be able to notify resmgr as normal user that I am logged in (e.g. via ~/.xinitrc) and configure resmgr as root in /etc/resmgr.conf to allow or deny access in this case.
Johannes, the whole problem is that you _are_ currently allowed to tell resmgr which device you're logged in on; and depending on that name, you're given certain privileges or not. The default configuration has only one level privilege, which can loosely be described as "local user". Anyone with a terminal matching "tty[0-9]*" or equal to ":0.0" will be given access to this group. This privilege check is performed once when you "log in" i.e. tell resmgrd you're there. After that, you can log in on /dev/pts/123 as well, and get the same privilege there. In other words, it doesn't matter in what window you start the application. What matters is there is some session where you're logged in via xdm on display :0, or on a local console. So your startx example above should not matter. If you can startx, you're logged into a virtual console, so you have all the rights you need. The problem is how resmgrd can verify the veracity of the information provided by pam_resmgr.
Created attachment 24846 [details] Proposed patch This patch should plug the hole, and at the same time allow pam_resmgr should continue to work with sshd if you add an auth line for it somewhere near the top of the list (at least before the first "sufficient" module): auth required pam_resmgr.so I will build a test package.
Regarding comment #8: a) The problem is not that I am allowed to tell resmgr that I am logged in but the problem is that I am allowed to lie to resmgr about the login-type. Because resmgrd is running as root I hope it can check whether the login-type is true. By default only root should be allowed to fake a login-type. By default normal users should be allowed to tell resmgr only the truth. According to "man resmgr" what seems to be the real "tty" is only a random string - therefore it seems at the moment resmgr itself does not check the real tty at all. If yes it is not surprising that someone can lie to the resmgr about the real login-type/tty. b) Why don't you simply try out my example? You would see that you don't get any access permissions after "startx -- -dpi 75 & exit" simply because of the "exit" there is no session where you are logged in via console. Of course when you switch to console with [Ctrl]+[Alt]+[F1] and log in again, then you have also resmgr permissions in all your pts/* sessions under X. I would really like to know what I must enter in /etc/resmgr.conf to get access even after "startx -- -dpi 75 & exit".
concerning a: no, resmgrd cannot verify this. Checking tty ownership is inherently unreliable, and verifying that your session is actually on display ":0" is virtually impossible. concerning b: I didn't notice the "& exit" part. This has never been supported, even with pam_devperm access to devices was revoked when you logged out.
Only for your information: I do the "& exit" for security reasons since I detected that [Ctrl]+[Alt]+[F1] is still possible even after I had "xlock"ed my display and then [Ctrl]+[C] would kill X and go back to my login shell. Marcus suggested to use "exec" instead and keep the session running on the console. Only for my information: What is the "tty" which is shown by "ps" and/or by "who"?
The tty info shown by ps and who is stored in /var/log/utmp, and it's put there by trusted applications (such as login, xdm, etc pp).
use startx -- -dpi 75 && exit just one & more
errr, exec startx -- -dpi 75 I mean
I started and mbuild job with the patch mentioned above. Id is bragg-okir-1250; please give this one a try and see if it a) fixes the vulnerability b) continues to work with kdm, login and sshd I tested it and it seems to work, but I would appreciate if someone else tested this fix on a real 9.2 installation
Job: bragg-okir-1251 Package: resmgr Dir: /work/built/mbuild/bragg-okir-1251 Distributions: - i386: succeeded Please test
No response - assigning back to submitter for testing.
Works for me with my way to log in. I.e. I can no longer fake tty as normal user. I think the real test of the various login possibilities must be done by QA. I.e. I do not approve the fix in general.
Olaf, can you submit update packages for older releases please. The bug is technically not critical but the resmgr is a central entity in our systems and it's code written by SUSE. I'll create patchinfo files and so on...
8.1/SLEC patched builds submitted 8.2 patched builds submitted 9.0 patched builds submitted 9.1/SLES patched builds submitted 9.2 patched builds submitted STABLE patched builds submitted Assigning back to security for patchinfo stuff and further tracking
laufzettel and patchfino files submitted.
http://w2d.suse.de/abuildstat/patchinfo/pending/cbbe5b141c99f4be09b1aa5818cedb9c http://w2d.suse.de/abuildstat/patchinfo/pending/fa6c6a3e792bf79b1d85821c689ea578
packages approved
CVE-2004-2658
CVE-2004-2658: CVSS v2 Base Score: 2.1 (AV:L/AC:L/Au:N/C:N/I:P/A:N)