OpenSSH/scp ->> F-Secure SSH server Problems

[Greg A. Woods]

[ On Tuesday, March 13, 2001 at 22:37:21 (-0600), owner-ssh at clinet.fi wrote: ]
> Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems
>
> inetd must be ill-thought-out...  
> 
> CGI/Perl scripts that define out EXTACTLY what binary they want to use
> must be ill-thought-out.  
> 
> inittab must be ill-thought-out.
> 
> Do I need to go on?  There are more you just need to look around at
> a standard POSIX unix install.

Obviously you're missing the point.

That paths to binaries in all of your examples, and more importantly in
all but the inetd case the meaning of the service names, are
*administrator* defined.

The "built-in subsystem" wart on SSH introduces in a naming scheme that
the client and server must agree upon, just as they must agree upon
TCP/UDP port numbers.

At the very minimum a very strict and central naming registry must be
defined if this sillyness has any chance of resulting in inter-operable
implementations.

> Correct binary?!?  Are you telling me as the ADMIN of my box *I* don't
> know where *I* put sftp-server?!  Pish-posh.

Ah, I see you've taken my words in completely the opposite way I
intended them.

I mean specifically that without the "built-in subsystem" wart the
administrator of an SSH server, will have complete and total control of
what binary the client executes via either $PATH, chroot, or some other
scheme which controls the interpreter used by sshd for the given
client's connection.

The "built-in subsystem" idea makes sshd into something more like inetd
where you must intuit what an arbitrary client means when it gives you a
very small piece of information (the port number in the case of TCP/UDP,
and the subsystem name in the case of SSH).  Now suddenly the client is
totally authoritative in knowing how to name the service it wants
(barring the existance of a strict subsystem naming registry and
associated application protocol definitions).

Without the "built-in subsystem" feature the server is authoritative.
Yes this means that the client may be forced to adjust to a given
server, but this is a far better approach and leads to total
inter-operability.  With subsystems any two conflicting groups of
clients using subsystem names without agreeing on what service they
refer to will not be able to inter-operate equally with any given
server.

> Or are you suggesting that if OpenBSD connects to Solaris that I should
> run a different sftp-server then if Linux connects to Solaris? 

IMNSHO that should be up to the client, but restricted by the server
administrator.

> What hardcoded path?  There is no hardcoded paths for sftp-server in sshd
> unless NetBSD botched things (which I doubt).  Subsystems are defined in
> your sshd_config.  How is this configured 'hard coded in the sshd'?  Heck
> you can do:
> 
> subsystem myrenamedsftpserver  /path/to/sftp-server
> 
> then hack a sftp to launch ssh with 'myrenamedsftpserver' instead of
> 'sftp'.  How is this hardcoded?

OK, not hard-coded in the binary, but only by the installation.

> I don't get your arguments.  I personally would rather state where system
> services are instead of sshd randomly guessing where thing
> are.

I agree, but you've missed the fact that the client hard-codes the
service name, leading to either total chaos, or at best IANA mediated
chaos.

> Depending on $PATH for critical services *IS* a secure risk.  This is one
> of the first things drilled into first year Web/CGI developers.

You need to think harder about the total trust and risk relationships
between the SSH client and the server before you worry about $PATH.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods at acm.org>      <robohack!woods>
Planix, Inc. <woods at planix.com>; Secrets of the Weird <woods at weird.com>