New Subsystem criteria for Match option block in OpenSSH server

[John Olsson M]

> #2 has obvious security implications, but #1 can too.
> For example: do you allow the user to write to the
> chroot directory itself?

If you mean chroot directory == "/" then root owns that directory ofcourse. You have the same problem as you describe below with the existing chroot directive, right?

If not, please explain why chroot:ing per subsystem creates a security hole.


> ChrootDirectory), then a second shell session to execute the setuid
> binary which will load the backdoored libc from the chroot and do something 
> nasty.

It is here I get lost. The chroot is configured per subsystem. So if you have the following hypothetical construct in SSHD config

Match Subsystem SFTP
  ChrootDirectory /foo/bar

You will only end up in the /foo/bar (as the new root) when you connect to the SFTP subsystem.

Thus you can't suddenly choose if you want to have a plain vanilla SSH to be chrooted or not. The idea was that the construct affects the whole subsystem, so how can you get a chroot:ed shell and do something nasty? Or what is it that I am missing? I want to understand. :)


/John

-----Original Message-----
From: Darren Tucker [mailto:dtucker at zip.com.au] 
Sent: den 23 maj 2012 07:54
To: Nicola Muto
Cc: dtucker at zip.com.au; Nicola Muto; openssh-unix-dev at mindrot.org; John Olsson M; Hans Insulander
Subject: Re: New Subsystem criteria for Match option block in OpenSSH server

On Tue, May 22, 2012 at 06:01:17PM +0200, Nicola Muto wrote:
> Darren Tucker write:
> >I'm not convinced this is a good idea
> 
> Why not? I'd like to understand what kind of problems you have with 
> the current implementation.

I have two sets of problems with the patch.  The lesser of the two were the implementation things I mentioned in my previous email.

The larger and thornier set is whether or not this is a sensible thing to do at all.
1) right now, the Match rules do not change the behaviour after the
   username is supplied (very early in the logon process).  The proposed
   patch allows a whole bunch of things to change at run time in possibly
   unanticipated ways.
2) it doesn't (and can't work) with ChrootDirectory+PrivilegeSeparation,
   which negates a whole lot of the safety features in sshd.

#2 has obvious security implications, but #1 can too.  For example: do you allow the user to write to the chroot directory itself?

You shouldn't (and there's a reason why there's a check for this), but if you do, having ChrootDirectory on the list makes the exploit easy:
in a single SSH session, open one shell session where you hardlink a setuid binary into the chroot, then use sftp to upload, say, a backdoored libc into the chroot (and thereby activating ChrootDirectory), then a second shell session to execute the setuid binary which will load the backdoored libc from the chroot and do something nasty.

--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3ou do  86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.