> >  -- 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.


It is static variable -- not auto variable.

That means that, on second execution of that code block,
variable last_kill_time have value which it got on line 5
on first execution. Line 2 is just initilazation of variable.
That does not apply to second execution of that code block
-- static variables are initialized when execution of program
starts.

> 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.

I'm afrain that your analyze assumes that variable is 'auto' instead
of 'static'.


(Another issue is that kill arguments are on wrong order as many
 is noticed.)

--
          /"\                           |  Kari
          \ /     ASCII Ribbon Campaign |    Hurtta
           X      Against HTML Mail     |
          / \                           |

Reply via email to