openssh unix dev - Sep 2008 - not being released

I've noticed a bug with even recent OpenSSH products, where if the host
disconnects during a certain period of time, the connection becomes frozen
causing possible expolit problems .

For example 

[root at portal ~] users
root
[root at portal ~] uptime -u (used to show how many users the box believes is
logged on)
2 Users
[root at portal ~]

In theory this trapped connection can and has proven to be used for expolits as
if the correct packet is sent to the box, using gathered information of course.
the attacker becomes assumed by the local host thru a remote host and appears to
be authenticated allowing executions based on the level of permission the frozen
login has

The example of this is:
root being the frozen user, the attacker expolits the frozen connection to be
assumed as them, and can execute all commands
where as

kevin being  a regular client, but also frozen (the box thinks there still
connected - but they arent) the attacker can only execute commands allowed by
user permissions.

The solution to the problem appears to be so far, making sure there are no
frozen connections caused by SSH so u
who -a, get the pid to the frozen connection, which removes that authenticated
frozen connection.

This bug has only been reproduced on the linux operating system, i havent used
any other OS to test it for them.

On Tue, 9 Sep 2008, Kevin Deveau wrote:
> I've noticed a bug with even recent OpenSSH products, where if the
> host disconnects during a certain period of time, the connection
> becomes frozen causing possible expolit problems .
>
> For example
> 
> [root at portal ~] users
> root
> [root at portal ~] uptime -u (used to show how many users the box believes
is logged on)
> 2 Users
> [root at portal ~]
>
> In theory this trapped connection can and has proven to be used for
> expolits as if the correct packet is sent to the box, using gathered
> information of course. the attacker becomes assumed by the local host
> thru a remote host and appears to be authenticated allowing executions
> based on the level of permission the frozen login has
It looks likes utmp is getting out of sync when sshd exits uncleanly.
I don't think this could be used for any real attacks, certainly not
the one that I think you are describing - there is no "frozen
connection",
just a missing record in utmp to indicate that a user has logged out.

-d

> -----Original Message-----
> From: openssh-unix-dev-bounces+scott_n=xypro.com at mindrot.org
> [mailto:openssh-unix-dev-bounces+scott_n=xypro.com at mindrot.org] On
> Behalf Of Kevin Deveau
> Sent: Tuesday, September 09, 2008 11:53 AM
> To: openssh-unix-dev at mindrot.org
> Subject: not being released
> 
> I've noticed a bug with even recent OpenSSH products, where if the
host
> disconnects during a certain period of time, the connection becomes
> frozen causing possible expolit problems .
> 
> For example
> 
> [root at portal ~] users
> root
> [root at portal ~] uptime -u (used to show how many users the box
believes
> is logged on)
> 2 Users
> [root at portal ~]
> 
> In theory this trapped connection can and has proven to be used for
> expolits as if the correct packet is sent to the box, using gathered
> information of course. the attacker becomes assumed by the local host
> thru a remote host and appears to be authenticated allowing executions
> based on the level of permission the frozen login has
> 
> The example of this is:
> root being the frozen user, the attacker expolits the frozen
connection
> to be assumed as them, and can execute all commands
> where as
> 
> kevin being  a regular client, but also frozen (the box thinks there
> still connected - but they arent) the attacker can only execute
> commands allowed by user permissions.
> 
> The solution to the problem appears to be so far, making sure there
are
> no frozen connections caused by SSH so u
> who -a, get the pid to the frozen connection, which removes that
> authenticated frozen connection.
> 
> This bug has only been reproduced on the linux operating system, i
> havent used any other OS to test it for them.
Have you done a "ps -ef" to confirm that the child sshd process is
still
running?

"Kevin Deveau" <kdeveau at cfassociate.com>
writes:
> In theory this trapped connection can and has proven to be used for
> expolits as if the correct packet is sent to the box, using gathered
> information of course. the attacker becomes assumed by the local host
> thru a remote host and appears to be authenticated allowing executions
> based on the level of permission the frozen login has
That's a *very* tall claim with no evidence to support it.

DES
-- 
Dag-Erling Sm?rgrav - des at des.no