Connection caching?

[Peter Stuge]

On Wed, May 05, 2004 at 02:27:25AM -0400, Jefferson Ogata wrote:
> Peter Stuge wrote:
> >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.

I'll think this over, lots of things going on right now. Thanks for the
example nevertheless!


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

Right. Do you have any suggestions for how it should look w.r.t. channels?

Should PAM be involved? (ssh-session, ssh-x11, ssh-forwarded-tcpip,
ssh-direct-tcpip service names?)


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

Right.


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

Ouch, yes, I'm sorry, I got the terminology wrong. :( I wrote session
but meant connection. Connections carry channels, a channel has four
standardized uses where one is "session" which is intended to run
one single program on the server, be it a shell, a subsystem or some
other command. (Using "shell", "subsystem" or "exec" channel requests
respectively.)

I'm repeating this for myself and others on the list that don't know
the protocol by heart (yet).. :)


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

Well, the client can be made to open more channels over the connection
already, using the escape commands, right?


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

Hm? ssh-session-agent should've been ssh-connection-agent and I meant
the future agent that did connection caching. :)


> >On Tue, May 04, 2004 at 03:27:12AM -0400, Jefferson Ogata wrote:
> >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.

I think we're actually agreeing on this. I'm not completely convinced,
but I see your point.


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

No, nothing demands this. There's even an error code called
SSH_OPEN_ADMINISTRATIVELY_PROHIBITED for the CHANNEL_OPEN request.


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

Yes.


> >Publish a system policy and kick the bozo out after a day. :)
> 
> If only... :^)

That's what policies are for, no? :)


> Still -- one day attack window.

Yes. No good.


> >It's not a bug, it's a feature, hehe.
> 
> That's what they all say. :^)

Would be nice to allow more control, yes. Would also be nice to do so
without adding very much code.


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

Thanks. I'll try rereading my own wording twice before the next time I
post messages complaining about the terminology of others!


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

Each port forward has it's own channel, so the code probably goes into
the CHANNEL_OPEN handler server_input_channel_open().


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

Well, not neccessarily, it could be implemented with a custom shell or
a wrapper before the shell. Everything in sessions is run by the user's
shell, IIRC.


Anyway, a quick way to impose the restriction you want is to change
#define MAX_SESSIONS 10 in session.c circa line 106 to 1. Other channels
will still be opened though.


//Peter