Florian Weimer <Weimer@CERT.Uni-Stuttgart.DE> writes:
> small overflow large overflow
> pre-0.9.6e no crash crash
> 0.9.6e crash crash
> 0.9.6g error error
When this bug first came out, I developed a somewhat similar tool, for
local use but I see different behavior than you suggest. In
particular, 0.9.6e and other compatible versions do not crash. Rather,
they generate an error locally and close the connections.
It's clear why this happens from examining the source code with the
relevant check (from 0.9.6e)
n2s(p,i); s->session->key_arg_length=i;
if(s->session->key_arg_length > SSL_MAX_KEY_ARG_LENGTH)
{
SSLerr(SSL_F_GET_CLIENT_MASTER_KEY,
SSL_R_KEY_ARG_TOO_LONG);
return -1;
}
s->state=SSL2_ST_GET_CLIENT_MASTER_KEY_B;
}
So, what happens is just that get_client_master_key returns -1 and the
connection terminates with a failure. On the wire, this looks like
a TCP FIN so is hard to tell from a crash, but it's not one.
On the other hand, the relevant code in OpenSSL 0.9.6g is:
n2s(p,i); s->session->key_arg_length=i;
if(s->session->key_arg_length > SSL_MAX_KEY_ARG_LENGTH)
{
ssl2_return_error(s,SSL2_PE_UNDEFINED_ERROR);
SSLerr(SSL_F_GET_CLIENT_MASTER_KEY, SSL_R_KEY_ARG_TOO_LONG);
return -1;
}
s->state=SSL2_ST_GET_CLIENT_MASTER_KEY_B;
}
Note the addition of the call to ssl2_return_error(). This is what
generates the "SSLv2 error", namely a return packet from the server
of:
80 03 00 00 00
When I run your code against 0.9.6e and 0.9.6g I see results
consistent with my own experience. Namely, 0.9.6e server
terminates the connection but does not crash.
Incidentally, it's quite unnecessary to test with a large overflow.
As your chart shows, a small overflow is differentially
diagnostic. Because a large overflow will actually crash vulnerable
survers, it's damaging to test them in this way. it's probably better
to remove this check entirely.
-Ekr
--
[Eric Rescorla ekr@rtfm.com]
http://www.rtfm.com/
