Connection caching?

John Davidorff Pell johnpell at mac.com
Thu May 6 11:45:38 EST 2004


I hadn't considered this scenario. Good points. At this point, however, 
we're not talking about an untrusted client so you can just as easily 
disable connection caching on the client (gateway) side as well.

Either way, there should be options to restrict the number of streams 
over a single connection, as you suggest.

Good communicating with you. :-)

JP


On 5 May 2004, at 01:31, Jefferson Ogata wrote:
>> If the client is compromised, then the attacker can easily use the 
>> existing shell channel: by breaking into the ptys, by hijacking the 
>> process, or by taking control of the actual physical terminal, among 
>> other ways. Some require advanced attacks, some require strolling 
>> over to the so-and-so's desk before so-and-so's screen saver picks 
>> up. At this point, one command can easily add an alternate 
>> private-key to the remote account, and thus provide outside, 
>> unrestricted, unmonitored access. One can also issue one command to 
>> do immediate damage ("rm -rf ~ &").
>
> You're making a lot of assumptions.
>
> Let's go through one more scenario, and please read and understand 
> this carefully:
>
> Suppose we set up ssh as a secure gateway. sshd is chrooted with the 
> only writable filesystem (/tmp) mounted noexec. Users' home 
> directories are read-only. No one can add binaries to the system, and 
> users can execute only the programs I provide in the chroot hierarchy. 
> Once a user logs in to the chrooted sshd, he can ssh from there to a 
> secure system, but has to authenticate a second time to do so.
>
> Now suppose an intruder somehow intercepts a user's password or 
> private key for accessing the gateway, and then logs in to the 
> gateway. Without "connection caching", the intruder can go no further. 
> He can play around on the gateway with the few commands available, but 
> he doesn't have a pty-hijacking program and there's no way for him to 
> add one. The user's home directory is read-only so he can't modify the 
> user's .profile to alias ssh to something else. So the intruder can't 
> get onto the secure system, and the compromise is contained.
>
> Now you add connection caching, and the compromise is no longer 
> contained. If the user is legitimately logged from the gateway into 
> the secure system, the intruder can now log in to the secure system, 
> as many times as he likes.

--
John Davidorff Pell
johnpell at mac.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2426 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040505/dd87ed67/attachment.bin 


More information about the openssh-unix-dev mailing list