[UNIX] S/Key Keyinit Authentication and Sudo Vulnerability
From: support@securiteam.comDate: 09/05/01
- Previous message: support@securiteam.com: "[NEWS] Gnutella Linux Client HTML Injection Vulnerability"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: support@securiteam.com To: list@securiteam.com Subject: [UNIX] S/Key Keyinit Authentication and Sudo Vulnerability Message-Id: <20010905065247.21999138C0@mail.der-keiler.de> Date: Wed, 5 Sep 2001 08:52:47 +0200 (CEST)
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -
S/Key Keyinit Authentication and Sudo Vulnerability
------------------------------------------------------------------------
SUMMARY
Keyinit's lack of authentication creates severe authentication issues,
especially when used in combination with programs such as sudo.
DETAILS
Vulnerable systems:
FreeBSD-stable
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 a denial of service attack on the victim by changing the
sequence
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).
Demonstration:
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
demonstration above
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 commonplace
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.
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
The information has been provided by <mailto:ftobin@neverending.org>
Frank Tobin.
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
- Previous message: support@securiteam.com: "[NEWS] Gnutella Linux Client HTML Injection Vulnerability"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
