[22528] in bugtraq
Re: S/Key keyinit(1) authentication (lack thereof) + sudo(1)
daemon@ATHENA.MIT.EDU (Wietse Venema)
Wed Sep 5 02:04:47 2001
In-Reply-To: <Pine.BSF.4.33.0109021247510.34551-100000@palanthas.neverending.org>
"from Frank Tobin at Sep 2, 2001 01:16:18 pm"
To: Frank Tobin <ftobin@neverending.org>
Date: Tue, 4 Sep 2001 10:48:39 -0400 (EDT)
Cc: bugtraq@securityfocus.com
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20010904144839.53239BC06C@spike.porcupine.org>
From: wietse@porcupine.org (Wietse Venema)
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.
