Bug 62001 (CVE-2004-2658)

<!-- 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)