Re: Upcoming OpenSSH vulnerability

From: Mark Rafn (dagon@dagon.net)
Date: 06/25/02 

From: dagon@dagon.net (Mark Rafn)
Date: 25 Jun 2002 18:10:02 GMT

>> http://www.mindrot.org/pipermail/openssh-unix-dev/2002-June/013664.html

Steven Cardinal <nospam.scardinal@yahoo.com> wrote:
>Does anyone at least know if this 'flaw' is exploitable by someone who
>doesn't have a login?

Someone knows, but is apparently not talking. The clear implication
is that there is a remotely exploitable root hole in all installations of
openssh that do not have privelege seperation.

Unfortunately, Theo de Raadt completely missed the boat when publishing
this warning. There's not enough information in it to actually evaluate
the risk and know whether it's real or completely theoretical.

The information currently available is:
1) Theo de Raadt claims there is a potential remote root hole
in all versions of openssh, and that privelege seperation prevents it
being exploited.

2) Nobody has posted here, the openssh lists, or bugtraq any
confirmation of this.

3) the "warning" was oddly combined with a screed against
vendors/repackagers of openssh. To me, this reduces it's credibility.

My opinion and recommendation:
WAG: there is in fact a bug, but it's both very obscure and difficult
to exploit. I expect some installations are vulnerable, but most are
not.

Recommend: upgrade to 3.3p1 and use privelege seperation if you can,
wait for the real advisory if it's difficult. In any case, turn on
logging of port 22 in your firewall and watch for any unexplained
connections to sensitive machines.

>We use ssh on numerous systems with RSA keys. No passwords, no root logins,
>etc. Those of us with keys installed on the systems are trusted (we already
>know the root password so we can su to get things done). So I'm not worried
>about a local user getting greater access.

Based on the proposed workaround, I'd guess the flaw is in the
authentication phase (the part that privsep runs in the chroot). It
seems very likely that it would NOT require a valid login to exploit,
but I can't say for sure. 

--
Mark Rafn    dagon@dagon.net    <http://www.dagon.net/>

Relevant Pages

  • Re: Upcoming OpenSSH vulnerability
    ... openssh that do not have privelege seperation. ... Theo de Raadt claims there is a potential remote root hole ... seems very likely that it would NOT require a valid login to exploit, ...
    (comp.security.ssh)
  • Re: [RFC][PATCH 0/9] Network receive deadlock prevention for NBD
    ... openssh or some other priveledge separation protocol to the machine due ... if there is any remote management that we absolutely require to be ... the time being since we don't actually know of any such mandatory login ... unix sockets require page sized allocation frequently which will endup ...
    (Linux-Kernel)
  • Expired password, openssh not invoking password change.
    ... We have an OpenLDAP backend for user authentication and everything is ... When I attempt to login I get this: ... You are required to change your LDAP password immediately. ... OpenSSH isn't calling the passwd application when the users password is ...
    (comp.security.ssh)
  • Signal 1, Name stays on "who" list under Linux
    ... I'm not too sure if this is off topic, it might be a bug in sshd which is ... OpenSSH v3.4p1, SSH protocols 1.5/2.0 ... 1> connect to the linux box via SSH client and login as any user ... To get past step 2 you have to enter root password, ...
    (comp.security.ssh)
Quantcast