S/Key keyinit(1) authentication (lack thereof) + sudo(1)

[Frank Tobin <ftobin () neverending org>]

Summary: keyinit(1)'s lack of authentication creates severe
         authentication issues, especially when used in combination
         with programs such as sudo(1).

Affected Systems: FreeBSD-stable (older?), and other systems that use
                  S/Key, especially in combination with sudo(1)

Solution Summary: Disable S/Key in favor of OPIE
                  or patch keyinit(1) to require authentication
                  or do not use sudo(1)

History:

I brought up this matter a few years ago on freebsd-security
(http://www.freebsd.org/cgi/getmsg.cgi?fetch=430991+433795+/usr/local/www/db/text/1999/freebsd-security/19990926.freebsd-security),
with no response, but at the behest of others during a demonstration I
gave recently, I'm prompted to bring this up again.


Problem Description:

keyinit(1) does not require any sort of authentication to initialize a
one-time password sequence.  This allows an attacker who has grabbed
temporary privileges as the victim to be able to run keyinit(1) (such as
grabbing the terminal for a moment) to:

*) use the newly-initialized-stream to repeatedly authorize the attacker's
   self to PAM.

*) perform denial of service to the victim by changing the sequence the

While ability to manipulate the authentication process without hindrances
is similar to modifying ~/.ssh/authorized_keys, ssh implementations are
primarily only used to gain the victim's privilege-levels.  The real
problem comes into play when other programs (such as sudo(1)) use the
ability to authenticate a user-level logon as equivalent to being allowed
higher system privileges (i.e., root).

Self-Demonstration of Impact:

1) Have sudo(1) installed on a machine, along with S/Key.

2) Login as a user with root-granted-by-sudo privileges, and get a
   terminal.

3) Run keyinit(1) to generate a new sequence, and use key(1) to get a list
   of OTP's.

4) Run sudo, and use the correct OTP to authenticate.

5) You now have root, without *ever* having to do anything besides be at a
   user-level terminal.


Example Impact:

A system using S/Key and sudo(1) could immediately have a root compromise
if a user who is granted root through sudo(1) ever has his or her
privileges stolen.


Analysis:

Programs such as sudo(1) which provide raised privileges based on a user's
ability to authenticate to normal-user privileges will allow such raised
privileges to the attacker.  In the extreme case of sudo(1), assuming the
victim has been given root privilege under sudo(1), an attacker is able to
authenticate through PAM to gain root privileges very easily (see
Self-Demonstration).

A key thing to note with sudo(1) is that the attacker has had to do
nothing besides run keyinit(1) with a victim's privileges to gain root
privileges; no action by the victim need be taken.

Another less serious impact could be with rlogin(1); an attacker could
login from a trusted machine, generate a sequence, and then user that
sequence to login from non-trusted machines.

Other impacts could be foreseen, depending on other programs that use PAM
for authentication to give raised privileges.  sudo(1) is a common-place
program, however, and its use is thought to generally improve the security
of a system.  However, the Self-Demonstration exhibits severe flaws in the
combination of keyinit(1) and sudo(1).


Proposed Solution:

One solution is to have keyinit(1) demand some form of authorization
before allowing the user to re-initialize the key sequence.  For instance,
require authentication through PAM to re-initialize the key sequence.  I
do not foresee any negative impact of this solution.

Another solution is to completely disable S/Key in favor of OPIE, another
one-time password implementation available in FreeBSD's -stable and
-current.

The real problem, however, is that sudo(1) assumes user-level privileges
should allow raised-level privileges.  While this may be a convenience in
using sudo(1), it is a security hazard.


Additional Information:

A long delay after mail to the FreeBSD Security officer (2001-04-02) and
some third-party channelling attempted to result in fixes.  However, at
the time of this announcement, no noticeable changes have occurred.

-- 
Frank Tobin             http://www.neverending.org/~ftobin/