Bug 874

Summary:	sudo commands being permitted without password prompt when user kerberos account expired
Product:	Sudo	Reporter:	Mick <mbarry>
Component:	Sudo	Assignee:	Todd C. Miller <Todd.Miller>
Status:	ASSIGNED ---
Severity:	normal
Priority:	low
Version:	1.8.23
Hardware:	All
OS:	Linux

Description Mick 2019-03-12 06:22:37 MDT

We use Kerberos for auth. And we have had this reported to us. We are running sudo v1.8.23 on Centos 7 - kernel 3.10.0-957.1.3.el7.x86_64.

When a user attempts to run a sudo command, they get prompted for their Kerberos password. When they enter it, it's all good. And sudo then 'caches' that person's ability to run commands via sudo for a period of time.

But in the case we have here, the user attempted to run a sudo command. Sudo checks with Kerberos, but instead of the usual response, i.e. good/bad password, in this case the user's account had expired. So sudo got this response:

[user1@server1 ~]$ sudo su -
[sudo] password for user1:
Warning: password has expired.
sudo: Account or password is expired, reset your password and try again
Changing password for user1.
(current) UNIX password:
sudo: unable to change expired password: Authentication token manipulation error
[user1@server1 ~]$

So, the user then goes to an internal portal we have for setting your kerberos password to fix the expiry issue.

They return to server1 and run their sudo command.

This time the sudo command runs, but they are not prompted for their password. The behaviour is as if the user had 'cached sudo perms'.

This is what we think is happening, in terms of a sequence of events:

Password expired:
1. sudo command run
2. sudo checks for local sudo user permission 'cache', i.e. has the user successfully run a sudo command in the previous X minutes?
3. If yes - then confirm with kerberos that user is valid and permit command without password
4. if not, then prompt for password and await Kerberos response.
- this is where it starts to go wonky:
5. kerberos responds that password has expired - this is not a fail response and so I think sudo, in the background, has started the 'cached permission' clock.
6. You go to the portal and change your password, and come back before X minutes has elapsed.
7 you return to the box and re-enter your sudo command.
8. sudo checks for local sudo user permission 'cache', i.e. has the user successfully run a sudo command in the previous X minutes?
9. In this case, the permission cache exists, so it checks Kerberos to see if your user is ok.
10. Kerberos responds that you exist
11 command is run.

Comment 1 Todd C. Miller 2019-03-12 09:04:16 MDT

The timestamp is updated before the PAM session functions are called which is why you see this behavior.  Changing that is somewhat complicated since the session code runs much later.  It may be possible to reorganize things such that the timestamp record is not updated until after the session checks.

Comment 2 Mick 2019-03-13 02:48:51 MDT

(In reply to Todd C. Miller from comment #1)
> The timestamp is updated before the PAM session functions are called
> which is why you see this behavior.  Changing that is somewhat
> complicated since the session code runs much later.  It may be
> possible to reorganize things such that the timestamp record is not
> updated until after the session checks.

Todd, 

We're going to do some further testing here. In our scenario, the method used to change the password requires you to use an rsa or yubikey device to change your password. So in order for someone to take advantage of this scenario in our company, we are replacing one auth method (kerb password) with another (rsa/yubikey). So that person still has to be 'that person'.

I'm not sure if you guys feel this is a bug, or just a quirk of the behaviour. We will probably pass this off to our Security Assurance team who will review it, after we've done some further testing and make our own decision as to whether this behaviour constitutes an actual risk or not. 

Would appreciate your thoughts on this all the same, is this something you feel needs rectification or not? 

Thanks

Comment 3 Todd C. Miller 2019-03-13 06:49:07 MDT

This doesn't really seem like a security issue since the user has successfully verified their identity with sudo.  I don't think it is significantly different from a user authenticating with sudo and then changing their password manually.  Sudo will not prompt for a password even though the user's password has changed.