scp not tolerant of extraneous shell messages

[Nicolas Williams]

On Tue, Jul 02, 2002 at 11:06:54AM -0700, Dan Kaminsky wrote:
> The separation between document and executable goes down to psychology 
> -- that which I learn is not that which I do.  Microsoft wrote large 
> portions of their "knowledge exchange system"(Word) in an executable 
> language; it's why the platform is quite virus ridden now.  They're 
> suffering similarly using Internet Explorer as their default viewer in 
> Outlook Express.

SFTP-SERVER won't be executing any of your files just because it's
executed by SSHD with an intermediary shell. If you don't want to allow
users to modify ~/.profile and do nasty things then don't (see my
comment re: restricted shells). So there is no connection to macro
virii.

> >A lot of things work this way. As long as the shell command
> >line is built securely and the shell setup (including
> >/etc/profile and ~/.profile) is secure there is nothing wrong.
> >  
> >
> Oh?
> 
> Name an FTPD that does.  Just one.

I didn't claim that FTPD was one. Just that many things are started with
"/bin/sh -c ..." (because it's useful).

> Unfortunately, users are trying to shoot my feet and legs off.  They 
> modify their .profile to run an exploit that hacks my file server and 
> trojans my data.  

Don't let them. I don't see why you'd let them just because you're only
letting them do SFTP!

> >Use a restricted shell if you must.
> >  
> >
> Restricted shells have always been somewhat irrelevant; they fail in 
> Windows due to excess complexity and they fail in Unix because 
> everything and its mother can open subshells(lynx, vi, emacs, 
> sftp-server, etc.)

Sure, but you're already talking about doing SFTP only. So the shell
escapes you mention wouldn't be an issue.

> >Perhaps SSHD should be configurable with respect to how sub-
> >systems are started - in fact, I don't why why it shouldn't be
> >so (though someone is bound to complain about code and config
> >option bloat...).
> >  
> >
> Secure by default.

*shrug*

I'm not an OpenSSH developer.

> >You can't detect the client's intention to run SFTP until
> >after the SSHv2 connection setup, which kinda means you must
> >run SSHD first.
> >  
> >
> Well, it's obvious now that SFTP fails to live up to its first initial 
> as is, so that leaves us with:
> 
> 1) SFTP on a different port
> 2) SFTP detected during client negotiation
> 
> Incidentally, if you don't believe my conclusion about SFTP, I offer you 
> the following thought experiment:  Would you rather give me access to an 
> account through wu-ftpd or sftp?

I just wouldn't give you an account :)

SFTP. And I'd use a restricted shell, and a forced command and you'd
never be allowed an interactive shell and you might not even have an
account as such but access to a special account for this purpose, like
an anonymous FTP setup say. Oops, that brings up chroot - different
thread - one of the answers given there was essentially (paraphrasing)
"write a user shell which does the chrooting ..." and I think the same
applies here.

> There are issues, incidentally, with making it easier to define sets of 
> users that are allowed to sftp in and others that can sftp and ssh in. 
>  Maybe we can do something interesting with AllowGroups.

Agreed.

I think it would be nice to be able to configure sub-systems in
interesting ways through sshd_config... And if you could ask that SFTP
be exec()ed without a shell intermediary, fine - as long as the other
option remains available.

> --Dan
> 

Cheers,

Nico
-- 
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.