> I recommend turning off the setuid bit ('chmod u-s /usr/local/bin/ssh').
> until the posted code fix is installed and tested.
>
> In fact --unless you are willing to peruse source code for bugs and
> will always install patches asap when bug reports come in -- I'd
> recommend leaving the setuid bit off the ssh client executable for the
> long forseeable future just to be on the safe side.
Indeed. I always recommend removing the setuid bit from ssh. What is
lost in flexibility is insignificant compared to what is gained in security.
In high security environments, the 'features' provided by it are not usually
even desirable.
> It means that you
> will have to live (on Unix/Linux hosts) without passwordless
> connections (both the (1) ordinary 'rhosts' and the (2) 'RSA rhosts'
> authentication methods because (1) ssh won't be able to prove that it
> is running as a privileged process by opening up a connection from a
> port under 1024 on the local host via which to transmit the username of
> the current user, nor (2) will it be able to read the local host's
> private from the file /etc/ssh_host_key which is normally only readable
> by 'root').
In fact, I also recommed taking this step a little further. You can help
to ensure that ssh is not used with 'rhosts' or 'RSA rhosts' authentication
even if the setuid bit is set (or later reset), by configuring your router's
ACLs to only accept ssh source ports of 1024 and above. Of course, this
won't help connections that don't go through the routers, but it adds a
little bit of extra protection and even flexibility. For example, in an
environment with a medium internal trust level and low external trust level,
it might be desirable to allow 'rhosts' and/or 'RSA rhosts' authentication
internally and yet insure that this relaxed posture is not also a 'feature'
to the outside world. You could leave the ssh setuid bit on and configure
internal routers to accept ssh source ports of 1022 and above while
configuring border routers to only accept ssh source ports of 1024 and above.
You could then allow the more relaxed posture internally while not also
relaxing your trust of the outside world OR prohibiting more secure 'RSA
only' (augmented with S/Key, etc. if desired) ssh trafic from/to the outside
world. This could be especially usefull in complex transitive trust
environments.
But, as I say, I wouldn't allow these 'features' as a general rule either
and would even help to insure this by blasting their use at the routers as
well.
Best Regards,
Kyle
Kyle Amon email: amonk@labyrinth.cftnet.com
Unix Systems Administrator url: http://labyrinth.cftnet.com/kyle
Security Specialist phone: (203) 486-3290
IBM Global Services pager: 1-800-759-8888 PIN 1616512
KeyID 1024/173D96C9
Fingerprint = 90 4F 0B D4 2D 37 E7 61 1A 31 7B F2 72 04 66 1A