Re: CHROOT patch openssh3.4p1

From: Nico Kadel-Garcia (
Date: 07/24/02

From: "Nico Kadel-Garcia" <>
Date: Wed, 24 Jul 2002 02:35:43 GMT

"Raymond Morsman" <> wrote in message
> > Oh, great, another one. Please hop over to
> > my notes on this. There's a 3.1p1 compatible patch, that also adds
> > to the script and has a widget for building new chroot
> That's fun. It doesn't work on 3.4p1 does it? So I think there's a
> need for a more recent patch. A lot has changed in 3.4 and your patch
> will most likely fail. I've been to your site, what could I find there
> that could be of any use for OpenSSH 3.4p1?

I've got some submitted patches: I haven't spent the time to really test
them out, due to a new job.

I've got the configurable chroot-cage tarball builder, I've attributed the
patches to the original authors, and I've put modifications in
to make '--with-chroot' a configure option instead of a default.

> There are very valid reasons to upgrade to the most recent version of
> OpenSSH. People who want to use the chrooted environment (like the
> company I'm working for) can benefit of my patch instead of finding it
> out on theirself.

There are precisely three reasons, near as I can tell, to go to 3.4p1.

    1: The discovered buffer overflow bug, which has published fixes for
3.1 -> 3.3 releases and was only a hole if you compiled for and allowed the
use of other authentication techniques like PAM or S/Keys.

    2: Privilege Separation, which is theoretically pretty cool but has
turned out not to work with all sorts of systems and to be quite unstable.
It doesn't work with compression, it doesn't play nice with chrooted SSH
target directories, it's entirely incompatible in its current release with a
large variety of operating systems and configurations, and it should (IMHO)
be disabled as a default until a lot more people have actually worked with

    3: A belief, not founded in this case, that the newest version of things
is bound to be better. It's pretty clearly only better, so far, in a
theoretical way.

Also, adding another new user (for the sshd root cage) requires co-evolution
of tools like tripwire to actually monitor the damn thing correctly, lest
someone succeed in taking advantage of the chroot target for a locally
enabled root exploit.

I've got better things to do with the time.

Relevant Pages