Observed in openssh-5.1p1.tar.gz.

This is a theoretical bug based on my reading of RFC 4419, and
implemented in kexgexs.c.

RFC 4419 addresses the Diffie Helman exchange.  RFC 4419, section 3,
requires a hash to be calculated over several items including

  uint32  min, minimal size in bits of an acceptable group
  uint32  n, preferred size in bits of the group the server will send
  uint32  max, maximal size in bits of an acceptable group

The min, n and max values have been previously sent from the client to
server in a SSH_MSG_KEY_DH_GEX_REQUEST message.

The corresponding section of code is in function
kexgex_server in kexgexs.c:

   case SSH2_MSG_KEX_DH_GEX_REQUEST:
        debug("SSH2_MSG_KEX_DH_GEX_REQUEST received");
        min = packet_get_int();
        nbits = packet_get_int();
        max = packet_get_int();
        min = MAX(DH_GRP_MIN, min);
        max = MIN(DH_GRP_MAX, max);
        break;


The bug is that, if the client sends values of 512 and 8192 for min
and max in the SSH_MSG_KEY_DH_GEX_REQUEST message, then the client
will expect the server to use these same values when calculating the
hash.  But the server will actually use DH_GRP_MIN for min,
which have the value 1024.



There is a related problem: (based of a review of kexgexs.c) If the
client specifies (in the SSH_MSG_KEY_DH_GEX_REQUEST message)
  min        512
  nbits      768
  max       8192
then the client will expect the server to reply with a 
suitable group. Actual behaviour is that:

   min will be increased to DH_GRP_MIN = 1024

and then nbits will be smaller than min, which will trigger

   if (max < min || nbits < min || max < nbits)
        fatal("DH_GEX_REQUEST, bad parameters: %d !< %d !< %d",
              min, nbits, max);