Re: Authentication failed suddenly

From:
Date: 09/21/02 

Date: Sat, 21 Sep 2002 13:50:30 GMT

"Per Hedeland" <per@hedeland.org> wrote in message
news:amhmda$2j1o$2@hedeland.org...
> In article <pJji9.13900$t%6.3967@nwrddc02.gnilink.net> "Nico
> Kadel-Garcia" <nkadel@bellatlantic.net> writes:
> >
> >One more time: Stay *AWAY* from openssh 3.4p1 until it's settled down and
> >gotten more robust, unless you want to be the one to make it robust.
>
> You keep saying things like this, but perhaps you could be a bit more
> specific? The only problem I've observed is that privilege separation
> and compression won't function together on some platforms - as noted in
> the documentation, i.e. this is not really a bug but a limitation of the
> current implementation. And of course nothing forces you to use
> privilege separation just because you run a version that has it, just
> turn it off and you have the same functionality in this respect as the
> 3.1p1 that you advocate. And if you turn neither privsep nor compression
> off on such a platform, sshd dutifully prints

Some kernels don't support it, it doesn't compile correctly out of the box
on a lot of platforms it used to work on (Solaris was an adventure, as was
Tru64 with undocumented gcc version dependencies, the new spec files don't
work with older RPM versions for RedHat, it depends an a bleeding edge
version of autoconf to be able to modify the configure.ac/configure files,
etc.), and it broke the available chroot tools. It's just nasty if you're
the poor bugger who has to work out the full details for it. The enabling of
PrivSep fails, if it's going to fail, at daemon start time, so if you're
installing it remotely and accidentally enable it with an inappropriate
setup (such as compression on some platform, inappropriate sshd or
/var/empty on other platforms, etc.), you lose your active ssh daemon onless
you've stashed an old one and left it running on another port.

Those are the obvious failures: they're enough to keep even expert people
away from it unless they like the bleeding edge dripping all over them.

> Someone else reported that full logging of failed login attempts didn't
> happen with privsep on - I can't reproduce that on RedHat 6.2, it works
> just fine there, and I would expect it to since there is an un-chrooted
> "monitor" process that does the logging (otherwise one could suspect the
> well-known problem with syslog() from a chrooted process being unable to
> access the Unix domain socket that syslogd listens on - which also has
> well-known solutions). But again, in case it really fails on some
> platforms, and you can't accept that, you can just turn privsep off.

It never should have been put in the code until it had a lot more testing.
The code is clearly not mature, which is a bad sign in a high-security tool.
It may work well for OpenBSD, the source platform for OpenSSH, but elsewhere
it should be taken out and run through a Roto-Rooter drain cleaner testing
cycle.....

> Also, some people have apparently been confused by an utterly minor
> issue in the Makefile, basically a missing '@' - it does an 'id' command
> to check that the privsep user exists, but the error message that should
> be printed if it doesn't gets printed even if it does (but only once
> instead of twice), due to the default "print every command" behaviour of
> make. Obviously this does not affect the build nor the runtime behaviour
> in any way.

It should *FAIL* in this case, not issue a quiet error message. But of
course, if you're compiling an RPM, you don't necessarily have the sshd user
setup on the compilation machine.

> As for RedHat's choice to just fix their 3.1p1-based RPM instead of
> pulling in 3.4p1, that's just plain good software management (even RH
> can do that sometimes...) - I haven't found any information to the
> effect that they have evaluated 3.4p1 and found it to be "not robust".

True. I'm sure they follow this group, and the failures reported here have
been many and varied. They have put 3.4p1 on the rawhide site for testing:
you can play with that one if you like, but it has a lot of library
dependencies, and I'd recompile from the SRPM.

> They obviously need to do more testing than the average tarball-
> compiling user to make sure that the new RPM fits smoothly into the
> general setup of their distribution, in particular if it should use
> privsep (e.g. a new user needs to be added, which I'd guess is not
> entirely trivial/uncontroversial to do as part of an RPM install).

Actually, it is trivial. RPM supports post-installation shell scripting, and
an "id sshd" could be done. There's a set of serious questions of what to do
if an sshd user is already present, published on the local network via NIS,
etc.

> And since the security hole needed to be fixed immediately, the proper
> thing for them to do was to just apply a patch, since it was trivial to
> do. Actually it seems to be a general policy with RedHat (and probably
> many other "vendors") to as far as possible stick to the original "base
> version" + patches when upgrading RPMs that are based on third-party
> software.
>
> Personally, I will pay much more attention to the note on the OpenSSH
> web page:
>
> The 3.4 release contains many other fixes done over a week long audit
> started when this issue came to light. We believe that some of those
> fixes are likely to be important security fixes. Therefore, we urge an
> upgrade to 3.4.
>
> - combined with the fact that it has now been out for almost two months
> without being "superseded". If it was chock-full of bugs like you claim,
> I'm sure the good folks developing/maintaining OpenSSH and the portable
> version would have a bugfixed version out by now.
>
> --Per Hedeland
> per@hedeland.org

The bugs are platform compatibility bugs. Near as I can tell, they don't
occur under OpenBSD. And they're waiting, not surprisingly, for us to find
those bugs and fix them: they don't have a big lab with dozens of OS's to
play with and lots of engineer time to do it with.

Relevant Pages

  • Re: Authentication failed suddenly
    ... >gotten more robust, unless you want to be the one to make it robust. ... And if you turn neither privsep nor compression ... platforms, and you can't accept that, you can just turn privsep off. ... compiling user to make sure that the new RPM fits smoothly into the ...
    (comp.security.ssh)
  • building binary rpms for other platforms.
    ... My company builds s'ware that runs on many platforms (linux, aix, ... solaris, windows) and we typically build pkgs in rpm, pkg, tgz, and msi ...
    (comp.os.linux.development.apps)