not being released - openssh

This is a discussion on not being released - openssh ; 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@portal ~] users root [root@portal ~] uptime -u (used ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: not being released

  1. 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@portal ~] users
    root
    [root@portal ~] uptime -u (used to show how many users the box believes is logged on)
    2 Users
    [root@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.
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  2. Re: not being released

    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@portal ~] users
    > root
    > [root@portal ~] uptime -u (used to show how many users the box believes is logged on)
    > 2 Users
    > [root@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
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  3. RE: not being released



    > -----Original Message-----
    > From: openssh-unix-dev-bounces+scott_n=xypro.com@mindrot.org
    > [mailtopenssh-unix-dev-bounces+scott_n=xypro.com@mindrot.org] On
    > Behalf Of Kevin Deveau
    > Sent: Tuesday, September 09, 2008 11:53 AM
    > To: openssh-unix-dev@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@portal ~] users
    > root
    > [root@portal ~] uptime -u (used to show how many users the box

    believes
    > is logged on)
    > 2 Users
    > [root@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?

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  4. Re: not being released

    "Kevin Deveau" 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@des.no
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev

+ Reply to Thread