De: "Frank Tobin" À: Objet: S/Key keyinit(1) authentication (lack thereof) + sudo(1) Date : lundi 3 septembre 2001 07:49 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/