scp not tolerant of extraneous shell messages

Nicolas Williams Nicolas.Williams at ubsw.com
Wed Jul 3 04:23:23 EST 2002


On Tue, Jul 02, 2002 at 11:27:21AM -0700, Dan Kaminsky wrote:
> >sftp.  Because the sftp setup I use forces the user to be chroot() into
> >their ~/WWW directory so they can not modify their ~/.ssh nor any dot
> >files within ~/.  Removing executing their shell gains you nothing if you
> >still let them play in the ~/.ssh/ section.
> >  
> >
> Well, I still get access to your network.  Potentially, I might be able 
> to hijack incoming SFTP connections, extract the passwords, and get into 
> other people's shells.

You clearly fail to understand SSHv2 and SFTP. And just because you
don't grant direct access to ~/.ssh/authorized_key doesn't means that
you cannot give your users any way to manage their authorized public
keys (see below).

Besides, I fail to see why giving you access using wu-ftpd wouldn't have
the same results if giving you access to sftp would have such results.

> Your solution does lock people to passwords, btw :-)  And it sure as 
> hell ain't as elegant as "you can write what you want, but we ain't 
> executing any of it from the file transfer system."

You can still give the users ways to manage their authorized keys, but
not let them edit ~/.ssh/authorized_keys (because you might want to
force commands or other things). SourceForge lets users manage auth keys
through a web interface - you can do the same too.

> You'd really take the (honestly) theoretical gain of crypto over the 
> very concrete loss of somebody else being able to run arbitrary code on 
> your machine?

Again, SFTP-SERVER won't be running client-sent files. It's your job to
adequately protect dot files.

> >I'm really interested in why you allow users to modify your login files
> >for your personal account.=)
> >  
> >
> Well, personally I equate executable permission with eventual root 
> compromise, but that's just a personal quirk.

See above.

> --Dan


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.




More information about the openssh-unix-dev mailing list