Very Computer

Hello,

Theo de Raadt is alerting the Vendors that ISS will publish an remote
exploit for OpenSSH and that 3.3p1 is able to limit the scope of the exploit
due to privsep.

Some vendors like Debian have already reacted and new versions of openssh
available, unfortunatelly the new openssh veriosn does not work pretty wel
with kerberos, pam or linux 2.0/2.2

Read all about it here: http://www.eckes.org/article.php?sid=73

Greetings
Bernd
--
www.eckes.org - Home of a Geek
www.freefireorg - The Freefire Project - Firewalling with Open Source

followup to Bernd Eckenfels:

Quote:> Hello,

> Theo de Raadt is alerting the Vendors that ISS will publish an remote
> exploit for OpenSSH and that 3.3p1 is able to limit the scope of the exploit
> due to privsep.

PrivSep has apparently nothing to do with this whatsoever.

OpenSSH is vulnerable only if one of these two conditions meet:

BSD Auththentication is compiled in and enabled (probably only when
running on BSD Systems)
or
SKEY Authentication is compiled in and enabled.

So the Fix would be to eigther disable these two options or to upgrade
to OpenSSH 3.4, which has just been released on http://www.openssh.org/

Quote:> Some vendors like Debian have already reacted and new versions of openssh
> available, unfortunatelly the new openssh veriosn does not work pretty wel
> with kerberos, pam or linux 2.0/2.2

Theo de Raadt's "fix" is horribly broken on everything that is not
OpenBSD.

Ignore Theo's rants about other Systems and read the ISS advisory on
their Website. PrivSep is broken in Portable relase of OpenSSH. It
breaks PAM, Compression and other thing. Some People have even locked
themselve out of remote systems following Theo's advice.

Disable ChallengeResponseAuthentication in sshd-config when running
non-BSD Unix systems (Linux, Solaris, HP/UX...) and be fine.
Upgrade to OpenSSH 3.4. (especially when running any *BSD)

BTW: Theo de Raadt's advice only prevents instant-root-shell, but
still leaves attackers with a remote shell on the server, with the
ability to run further attacks from there. (i.e. against 127.0.0.1
or other hosts).

Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
This is it. Nothing more to come. There is no more text. It's the
end

Quote:> PrivSep has apparently nothing to do with this whatsoever.

Privsep does limit the impact (no remote root exploit)

Quote:> So the Fix would be to eigther disable these two options or to upgrade
> to OpenSSH 3.4, which has just been released on http://www.openssh.org/

According to the Advisory it is not enough to only turn  the options off,
because there are more problems in the 3.4 patch solved which could be also
exploited:

At least PAMAuthenticationViaKbdInt  needs to be disabled, too. (openssh
advisory)

openssh.org:
The 3.4 release contain 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.

Quote:> Disable ChallengeResponseAuthentication in sshd-config when running
> non-BSD Unix systems (Linux, Solaris, HP/UX...) and be fine.

nope

Greetings
Bernd

Quote:> At least PAMAuthenticationViaKbdInt  needs to be disabled, too. (openssh
> advisory)

At least on my RedHath 7.2 and 7.3 boxes ( OpenSSH 2.9 and 3.1
respectively ), PAMAuthenticationViaKdbInt is "no" by default and
you have to explicitly enable it in sshd_config. So if you haven't
mucked with defaults too much and turn off the challenge/response
authentication option ( or, as on RedHat, have a build of OpenSSH
compiled without any of the C/R auth options ), you close the hole
without the other uncertainties involved in a rushed upgrade to
a radically different codebase ( especially one like the privsep
code that's known to not play well with PAM and such on non-BSD-based
systems ).

--
Safety hint, dude ... never, ever get up to go to the john at night unless
you can actually feel your body.
                                -- Sonya Marie Gildencrantz