7028460 2001-09-02 13:16 -0500 /115 rader/ Frank Tobin <ftobin@neverending.org>
Sänt av: joel@lysator.liu.se
Importerad: 2001-09-03 07:48 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <19038>
Ärende: S/Key keyinit(1) authentication (lack thereof) + sudo(1)
------------------------------------------------------------
From: Frank Tobin <ftobin@neverending.org>
To: <bugtraq@securityfocus.com>
Message-ID: <Pine.BSF.4.33.0109021247510.34551-100000@palanthas.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/
(7028460) /Frank Tobin <ftobin@neverending.org>/(Ombruten)
7035330 2001-09-03 10:18 -0400 /72 rader/ Derek Martin <ddm@pizzashack.org>
Sänt av: joel@lysator.liu.se
Importerad: 2001-09-04 05:48 av Brevbäraren
Extern mottagare: Frank Tobin <ftobin@neverending.org>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <19054>
Kommentar till text 7028460 av Frank Tobin <ftobin@neverending.org>
Ärende: Re: S/Key keyinit(1) authentication (lack thereof) + sudo(1)
------------------------------------------------------------
From: Derek Martin <ddm@pizzashack.org>
To: Frank Tobin <ftobin@neverending.org>
Cc: bugtraq@securityfocus.com
Message-ID: <20010903101857.A10616@pizzashack.org>
On Sun, Sep 02, 2001 at 01:16:18PM -0500, Frank Tobin wrote:
> 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.
This isn't really true. While I don't think adding authentication is
a bad idea, where compromises occur via this mechanism, your real
problem is different from what you outline. You DO need to have
access to a root level terminal, albeit through sudo. This means you
need either:
- have permission from the admin team to run sudo
- have compromised the account of a system adminstrator or other
person who has root priviledges through sudo
In the first case, you're either a system administrator, or you should
have very restricted access to what you can run with sudo. If you're
a malicious user AND you're a system administrator, and/or you have
unrestricted root priviledges, as we all know the system's already
screwed, as there is no protection from a malicious root user. If
they don't steal your account this way, they'll find any one of a
hundred other ways to do it.
In the second case, the administrators have not done a good job of
securing their environment. Any account which has privileges to run
programs as root should be treated as requiring the same security as
the root account itself. If the account is an actual admin account,
shame on the admin! Admins should realize that their account is just
as important to secure as the root account.
If the account is some non-administrator with sudo priviledges, the
admins have not adequately limited what that user can run with sudo,
and have not done a good job in educating that user how to keep their
own account secure. The user with root privileges (like all users,
actually) has the responsibility to use good passwords and not share
them with others, lock his terminal when he leaves it, etc. in order
to keep his account secure. It should be stressed to all users who
are given sudo priviledges that these things are especially important
for them, as failing to do it can get your whole network compromised.
The malicious user also needs to know WHO has sudo priviledges.
Keeping the sudoers file non-readable by regular users will help a bit
here, though in general it's probably safe to assume that the admin
team uses it, if it's installed.
So again, while adding authentication is not a bad idea, your real
problem here is teaching your users and/or admins to safeguard their
accounts and configure sudo properly. If you don't do this, then
authentication in keyinit is really irrelevant, as malicious users
will find lots of other ways to accomplish their goals.
--
---------------------------------------------------
Derek Martin | Unix/Linux geek
ddm@pizzashack.org | GnuPG Key ID: 0x81CFE75D
Retrieve my public key at http://pgp.mit.edu
(7035330) /Derek Martin <ddm@pizzashack.org>/-------
7044254 2001-09-04 10:48 -0400 /39 rader/ Wietse Venema <wietse@porcupine.org>
Sänt av: joel@lysator.liu.se
Importerad: 2001-09-05 08:06 av Brevbäraren
Extern mottagare: Frank Tobin <ftobin@neverending.org>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <19073>
Kommentar till text 7028460 av Frank Tobin <ftobin@neverending.org>
Ärende: Re: S/Key keyinit(1) authentication (lack thereof) + sudo(1)
------------------------------------------------------------
From: wietse@porcupine.org (Wietse Venema)
To: Frank Tobin <ftobin@neverending.org>
Cc: bugtraq@securityfocus.com
Message-ID: <20010904144839.53239BC06C@spike.porcupine.org>
If an operator leaves his/her terminal unattended, then a miscreant
can plant any number of trojan horses to gain future root access.
The possibilities for getting future root access are not limited
to skeyinit + sudo. To begin with, any trojan horse will suffice
that captures the operator's plain-text password. Then there are
cron and at, which give the equivalent of operator terminal access.
Therefore, adding a password challenge to skeyinit is not sufficient.
The fix, at least for today's versions of FreeBSD, is for operators
not to leave their terminal unattended.
Wietse
Frank Tobin:
> 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.
(7044254) /Wietse Venema <wietse@porcupine.org>/----
Kommentar i text 7044383 av Frank Tobin <ftobin@neverending.org>
7044383 2001-09-04 17:06 -0500 /23 rader/ Frank Tobin <ftobin@neverending.org>
Sänt av: joel@lysator.liu.se
Importerad: 2001-09-05 08:29 av Brevbäraren
Extern mottagare: Wietse Venema <wietse@porcupine.org>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <19077>
Kommentar till text 7044254 av Wietse Venema <wietse@porcupine.org>
Ärende: Re: S/Key keyinit(1) authentication (lack thereof) + sudo(1)
------------------------------------------------------------
From: Frank Tobin <ftobin@neverending.org>
To: Wietse Venema <wietse@porcupine.org>
Cc: <bugtraq@securityfocus.com>
Message-ID: <Pine.BSF.4.33.0109041703110.39912-100000@palanthas.neverending.org>
Wietse Venema, at 10:48 -0400 on Tue, 4 Sep 2001, wrote:
If an operator leaves his/her terminal unattended, then a miscreant
can plant any number of trojan horses to gain future root access.
However, trojans can theoretically be avoided given the right
user-environment setup. They also require action to be taken by the
victim, which increases the time it takes to execute the attack. The
attack I describe is not a trojan, and needs no vicitim action.
The importance of needing user action is important, because
increasing the length of time from the start of the attack to the
finish of it increases the possibility of the trojan being detected
by some means.
--
Frank Tobin http://www.neverending.org/~ftobin/
(7044383) /Frank Tobin <ftobin@neverending.org>/(Ombruten)