scp not tolerant of extraneous shell messages

[Dan Kaminsky]

>
>
>No. I don't see the connection to macro virii.
>  
>
My apologies, I thought it was more obvious.

I open a file.  I want to read what it has to say.  I want to see its 
images, understand its material, possibly modify it myself.

I don't want it to read what *I* have to say, though.  I don't want it 
to see my images, my material, and absolutely not modify my material.

By sending a mail onto this mailing list, I inserted myself into 
hundreds, maybe thousands of file systems throughout the world.  For 
good or bad, I've been granted the capability to write to a limited 
subset of the data stores of others.  I suspect that ability would be 
revoked quite rapidly if I could execute arbitrary commands with it.

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.

>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.

How bout a web server?  Yes, web servers do allow execution through 
shells.  That's essentially CGI, which isn't mandatory, isn't enabled by 
default, and is always kept a separate and vaguely dangerous segment of 
the system.

For good reason.

>Yes, users can shoot their feet and legs off if you let them.
>
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.  

>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.)

>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.

>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?

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.

--Dan