[lug] Openssh exploit

[Scott A. Herod]

BTW, I've been watching RedHat for an update from them.  It looks
like they're thinking about it.  A link on their errata pages keeps
coming and going, but when it's there, it points to a missing page
(error 404).

Scott

Neal McBurnett wrote:
> 
> On Fri, Mar 08, 2002 at 10:43:01AM -0700, Neal McBurnett wrote:
> > On Thu, Mar 07, 2002 at 10:42:48AM -0700, Scott A. Herod wrote:
> > > A root exploit to Openssh was just announced.  www.openssh.org
> > > has new rpms.  The exploit is reported as local only
> > >
> > > http://www.openbsd.org/advisories/ssh_channelalloc.txt
> > >
> > > Scott
> >
> > This "remote" vs "local" distinction is confusing in this case.
> >
> > The bottom line is that if someone has ssh access to any machine that
> > is connected, transitively over time, with your machine, your machine
> > could be at their disposal if they do a series of attacks.
> 
> Rereading that I think the "transitive" notion is a bit confusing.
> 
> Scenario: someone with an account at sourceforge attacks sourceforge,
> gets root and modifies their sshd (or perhaps even just stealthily
> attacks the running sshd process....).  A colleague connects to
> sourceforge and their id is compromised.  They (or an ssh worm)
> connects to your machine and your machine is compromised, etc.
> 
> I haven't heard of wild exploits, but it sure sounds like a
> potentially bigger risk than it might seem at first....
> 
> -Neal
> 
> > Here is a better description:
> >
> >     Joost Pol discovered an off-by-one bug in a routine in the openssh
> >     code for checking channel IDs. This bug can be exploited on the
> >     remote side by an already authenticated user, qualifying this bug
> >     as a local security vulnerability, and on the local side if a
> >     malicious server attacks the connected client, qualifying this bug
> >     as a remote vulnerability.  If the error is being exploited, it
> >     leads to arbitrary code execution in the process under attack
> >     (either a local ssh client, attacking the userID of the client
> >     user, or a remote secure shell daemon that has an authenticated
> >     user session running, attacking the root account of the remote
> >     system).
> >     Please note that the possible attack scenario is different from
> >     the usual attack scheme because "local vulnerability" refers to
> >     the remote side and vice versa.
> >
> >     There is no temporary workaround for this bug. If you comply to
> >     the following two conditions, the impact of the error is
> >     considerably small:
> >
> >         1) You only connect to hosts that you consider fully trusted
> >         and not compromised.
> >
> >         2) The users that connect to your servers are fully trusted
> >         (the users have root access, for instance).
> >
> > Neal McBurnett <neal at bcn.boulder.co.us>
> > http://bcn.boulder.co.us/~neal/
> > GPG/PGP signed and/or sealed mail encouraged.  Keyid: 2C9EBA60