OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Andrew Brown (atatatATATDOT.NET)
Date: Sun Feb 11 2001 - 11:07:39 CST

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    > -- With the patch, the lifespan of the server key still does not go
    > below one minute. As mentioned in CORE SDI's advisory, the number
    > of server connections necessary to carry out the attack is
    > normally very large but "the number of connections given is for
    > the average case and specifics cases will fall below the
    > average". This suggests that is not entirely out of the question
    > for the attack to succeed within one minute. If that risk is not
    > appropriate in one's environment, then other measures (which may
    > include inetd/tcpserver but may also include desupporting use of
    > SSH protocol 1.5) are needed.

    1) {
    2) static time_t last_kill_time = 0;
    3) if (time(NULL) - last_kill_time > 60 && getppid() != 1)
    4) {
    5) last_kill_time = time(NULL);
    6) kill(SIGALRM, getppid());
    7) }
    8) fatal("Bad result from rsa_private_decrypt");
    9) }

    actually...if we look at the lines that the patch adds, i think it's
    pretty clear that the variable last_kill_time, declared at line 2 to
    be static and initialized to 0, will always be 0 at line 3 (since it
    can't get set to anything else from other code...it's static), which
    means that the kill (and setting the actual of last_kill_time to
    something other than 0) will almost always take place (now - 0 is
    usually a lot more than 60), and the fact that it finally get set
    doesn't mean anything to anyone, since the only process that recorded
    that the signal was sent immediately exits at line 8.

    unless i'm missing something, this turns the vulnerability from a
    possible (but difficult) theft of a session key to very easy denial of
    service attack. all i need to do is keep connecting and screwing up
    and your main sshd will churn on and on making itself new server keys.

    --
    |-----< "CODE WARRIOR" >-----|
    codewarriordaemon.org             * "ah!  i see you have the internet
    twofsonetgraffiti.com (Andrew Brown)                that goes *ping*!"
    andrewcrossbar.com       * "information is power -- share the wealth."