IETF-SSH archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: OpenSSH/scp ->> F-Secure SSH server Problems
[ On Wednesday, March 14, 2001 at 09:49:55 (+0100), Markus Friedl wrote: ]
> Subject: Re: OpenSSH/scp ->> F-Secure SSH server Problems
>
> you could use a "exec" request as well,
Exactly.
> but then you need to have
> sftp-server in the path or know the full pathname on the remote host
"In the path" or by way of any other suitable platform-specific
mechanism to find an appropriate administrator-defined program matching
the request.
> "subsystem"
> just allows an additional level of indirection.
That extra indirection has no benefit. First off since as yet there's
no registry set up (or even hinted at) to define these names there's
inevitably going to be conflict because any name can mean anything
(unless perhaps it's defined in some other approved and *referenced*
RFC). Only negative impact will result from these already visible
inter-operability problems without. Even with a proper subsystem name
registry (eg. through IANA) the the danger of such naming schemes in
higher level protocols are visible in numerous existing IETF approved
protocols (eg. MIME).
> it also allows easy
> restriction, e.g. a user is allowed to send request only for this
> and that subsystem.
I'm not sure there's any real security there, and my instinct says
there's not.... Unfortunately this is an implementation specific
problem and something the protocol specifications will have a hard time
mandating (you can mandate security all you want but unless the people
making it work are 101% successful your mandate is useless and turns
into a very dangerous false sense of security where there is in fact
none).
In any case given specific implementation details it's fairly likely
that one can imagine an exploit where damage of some sort can be done
even if the remote client user is restricted to using any given
"built-in subsystem". This is particularly true of a file transfer
style of application which permits arbitrary file types to be transfered
(or to which the real file type can be masked).
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwoods%acm.org@localhost> <robohack!woods>
Planix, Inc. <woods%planix.com@localhost>; Secrets of the Weird <woods%weird.com@localhost>
Home |
Main Index |
Thread Index |
Old Index