Connection caching?

[Jefferson Ogata]

John Davidorff Pell wrote:
> I agree with you, but in the interests of expanding my own 
> understanding, I'm going to play devil's advocate.

Fine.

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

> In order to hijack a "cached" connection, one must have (local) shell 
> access as user 'foo' (or root), to execute "ssh 
> bar at existing.conneciton". In order to hijack an existing, non-cached 
> connection, one must have local shell access as user 'foo', to execute 
> one of the many tools that can "hijack" a pty. At this point, there is 
> little-to-no expectation of security.

In order to hijack an existing, non-cached connection, an attacker needs a lot 
more resources, as I hope you can see from the example above.

> The difference? In one case the command is simple and obvious. In the 
> other, the attacker must use a command that takes over an existing pty, 
> which is sometimes already present on the system.

And if it's not present on the system, the admin should still be able to protect 
himself.

> specifically, I'm thinking of something like GNU Screen or even 
> something a little more specific. Something like that is not hard to 
> write, especially if we're talking about an insecure client system.

screen doesn't let you take over just any session -- the session has to be run 
under screen in the first place.

Again, as I've mentioned elsewhere in the thread: there are environments other 
than the traditional UNIX model with ptys owned by the user and the ability for 
user processes to inspect or modify the VM of a peer process. It is not 
reasonable when designing the protocol of what is supposed to be a "secure 
shell" program to make assumptions about how easy or hard it is to attack the 
process model of the host platform. It can be made hard, and the "secure shell" 
program shouldn't undermine one's efforts to harden the rest of the system.

> You're advocating security through obscurity. If the attacker does not 
> know how to hijack an existing pty, then he/she will likely not be able 
> to do any damage on the remote system besides obvious "lets screw with 
> foo's files" which he/she can do on the local system anyway. This is 
> foo's problem, not the server's. If the "hijacker" can hijack the pty, 
> then the server is in a much more vulnerable position and is in the same 
> position now as it would be after a 2nd shell "session" over the 
> already-authenticated connection.

I'm advocating doing whatever is possible to mitigate the spread of a 
compromise, or at least giving the sysadmin the tools he or she needs to do so.

-- 
Jefferson Ogata <Jefferson.Ogata at noaa.gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>