Actually, it is a problem with any suid program that brings remote things down
to a local machine. In essence, you need to know the remote machine is not
compromised and trust the remote system and that the local suid program is well
written. If the program is well written (as all suid ones should be) then it
will only stay suid root as long as it takes to open the local end of the
socket, then set itself back to the invoking user (slightly later for ssh, but
early enough, see below). In this case, your exposer is limitted and only to
the local machine. If the program stays suid root when connecting remotely,
then you leave yourself open to the problem stated.
Note, for all people using scp with rhosts and rhosts rsa authentication and not
DSAauthentication and RSAauthentication, this is the same as setting
UsePrivilegedPort to no in the ssh_config file and has the same problems,
noteably rhosts and RSA rhosts authentication won't work.
Personally, I don't see the need to do this after looking at the code for
OpenSSH v2.2.0p4. ssh.c is very careful about the suid nature of the process
and drops it as soon as it can. This is just after the connection, but before
the ssh login. It is done here instead of after the socket creation since it has
to read the private host key, from what I gather from the source. The private
key is even cleared as soon as it is not needed. Since this is before the
login, no files will even be copied before suid is dropped, so even if the
remote machine is compromised, only files owned by the current user can be
overwritten. Of course, if the current user is root you are on your own. of
course, removing suid doesn't even help in that case. So I guess you should be
real sure of the remote machine before using scp as root...
Anyway, look at ssh.c in the OpenSSH v2.2.0p4 source if you are interested in
this.
--Dave
>Date: Thu, 12 Oct 2000 15:53:33 +0200
>From: Markus Friedl <[EMAIL PROTECTED]>
>To: Pierre Abbat <[EMAIL PROTECTED]>
>Cc: [EMAIL PROTECTED]
>Subject: Re: Mandrake ssh security alert
>Mime-Version: 1.0
>Content-Disposition: inline
>User-Agent: Mutt/1.2.5i
>
>sorry, but this does not make sense to me.
>the problem is in scp/rcp not in ssh.
>
>On Thu, Oct 12, 2000 at 01:23:51AM -0400, Pierre Abbat wrote:
>> http://linuxtoday.com/news_story.php3?ltsn=2000-10-10-018-04-SC-MD
>>
>> Problem Description:
>>
>> A problem exists with openssh's scp program. If a user uses scp to move files
>> from a server that has been compromised, the operation can be used to replace
>> arbitrary files on the user's system. The problem is made more serious by
>> setuid versions of ssh which allow overwriting any file on the local user's
>> system. If the ssh program is not setuid or is setuid to someone other than
>> root, the intrustion is limited to files with write access granted to the
owner
>> of the ssh program. In either case, files can be overwritten with code
allowing
>> others access to the system unexpectedly. While no fix has been provided for
>> openssh as of yet, the versions of openssh available for Linux-Mandrake 7.0
and
>> 7.1 were setuid root. This update removes the setuid bit from the ssh program
>> and limits the exploitability of scp somewhat. All users of Linux-Mandrake
are
>> encouraged to upgrade to these latest openssh builds. Linux-Mandrake 7.0
users
>> will also need to upgrade openssl in order to use the 7.0 update of openssh.
>>
--
David Knight French
Black Mountain Computer Consulting
Voice: (858)279-4862
Email: [EMAIL PROTECTED]
