On 10 June 2014 21:52, Kurt Roeckx <k...@roeckx.be> wrote:
>> As far as I can see this is SSLv3 only, and only about the Finish
>> message.
>>
>> So it seems that function return the length of the digest, and in
>> some error cases 0. We'll end up with a wrong value in
>> (peer_)finish_md_len.
>>
>> It should then result in this error:
>> if (i != n)
>> {
>> al=SSL_AD_DECODE_ERROR;
>> SSLerr(SSL_F_SSL3_GET_FINISHED,SSL_R_BAD_DIGEST_LENGTH);
>> goto f_err;
>> }
>>
>> So at first look there doesn't seem to be anything wrong with the
>> current code. But their patch doesn't do anything wrong either.
>
> So to clarify this a little more. ssl3_final_finish_mac() returns
> 0 on an internal error, or the length of the digest. In case of SSLv3
> it's both an MD5 and SHA1. In ssl3_final_finish_mac() they only
> get calculated and the length is returned. The check that they
> are correct happens just after the if I quoted above.
I can't see a way that this could be exploited. It is a bug though.
I've just pushed a fix:
https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=2f1dffa88e1b120add4f0b3a794fbca65aa7768d
Matt
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
