[lug] Openssh exploit

[Neal McBurnett]

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
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug