Subject: Re: setuid ssh
To: Luke Mewburn <lukem@cs.rmit.edu.au>
From: Andrew Brown <atatat@atatdot.net>
List: tech-security
Date: 10/18/2000 22:46:14
  by mail.netbsd.org with SMTP; 19 Oct 2000 02:47:07 -0000
	by noc.untraceable.net (8.11.1/8.11.1/bonk!) id e9J2kEE06445;
	Wed, 18 Oct 2000 22:46:14 -0400 (EDT)
Date: Wed, 18 Oct 2000 22:46:14 -0400
From: Andrew Brown <atatat@atatdot.net>
To: Luke Mewburn <lukem@cs.rmit.edu.au>
Cc: sommerfeld@orchard.arlington.ma.us, Atsushi Onoe <onoe@sm.sony.co.jp>,
   cjs@cynic.net, tech-security@netbsd.org
Subject: Re: setuid ssh
Message-ID: <20001018224614.B6338@noc.untraceable.net>
Reply-To: Andrew Brown <atatat@atatdot.net>
References: <20001018141630.AE17D2A2A@orchard.arlington.ma.us> <200010190159.MAA09821@wombat.cs.rmit.edu.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200010190159.MAA09821@wombat.cs.rmit.edu.au>; from lukem@cs.rmit.edu.au on Thu, Oct 19, 2000 at 12:58:59PM +1100
Return-Receipt-To: receipts@daemon.org

>> > i believe they can, but am placing the difficulty level a little
>> > higher than breaking into a machine via some other means and obtaining
>> > root privs (so as to steal all the keys).
>> 
>> If an attacker gets root privs, "game over"... they can replace the
>> kernel and change the rules of the game.
>
>i think the difference is this:
>	- with .shosts on the target machine, the target machine
>	  controls who can access. you can prevent access by changing
>	  ~/.shosts on the target machine (once).
>	  to spoof, you need to have a copy of the private host key from a
>	  source machine and spoof the ip address. this can be much harder
>	  if you have reasonable router rules and people are attacking from
>	  an `off site' machine

yep...

>	- with a passphraseless key, someone can compromise any machine
>	  with that key, and use that whenever they like until you
>	  change that key on every host with that key, no matter where
>	  they are.

and double yep.

>sure, if they get root on the target machine you're stuffed in both
>cases...

more or less, yeah.

>i have `more secure' machines having the ability to ssh as root
>to `less secure' machines as root using ~root/.shosts, and
>sshd.config options such as:
>	IgnoreRootRhosts	no		# allow ~root/.shosts
>	IgnoreRhosts		yes		# ignore ~/.shosts
>	RhostsAuthentication	no
>	RhostsRSAAuthentication	yes
>	IgnoreUserKnownHosts	yes

hmm...the rhosts/shosts thing *really* works like that?  i thought
they were both enabled/disabled with the same option, but separate so
that you could use .shosts without confusing rsh/rlogin (as if you
were actually using them).

>does ssh actually *need* a privleged port if you're using
>RhostsRSAAuthentication? what am i missing?

yes, it does.  it uses the fact that it has a privileged port (which
requires root) and the host's key (which it needs root to read for rsa
authentication, as with your own key) to authenticate itself.  it's
basically the client *machine* authenticating itself to the server
*machine*.  and trusting root on the remote machine.  root can, with
this auth method, pretend to be anyone on the client machine.  of
course.

it does require that server have the client machine's host key in
/etc/known_hosts.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."