Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 27 Jun 2012 23:28:29 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: RAR cmp_one(3) failures

On Wed, Jun 27, 2012 at 09:13:33PM +0200, magnum wrote:
> On 2012-06-27 19:35, Solar Designer wrote:
> > This line looks erroneous to me:
> > 
> > EVP_DecryptFinal_ex(&aes_ctx, cur_file->saved_ct + outlen, &outlen);
> > 
> > (potentially writing into cur_file->saved_ct, which is shared between
> > threads).  However, commenting it out does not appear to change
> > anything (is it a no-op under normal circumstances, perhaps?)
> 
> You are right. I changed it now (to &plain[outlen]) but AFAIK it's
> always a no-op.

BTW, what's there to prevent writing beyond the end of plain[]?  I think
this does not actually happen during self-tests now, so the problem
we're seeing is likely different, yet that code does not make me feel
confident.

As to the self-test failure, we're getting CRC mismatch here:

cracked[index] = !memcmp(crc_out, &cur_file->crc.c, 4);

crc_out changes between different failures, whereas cur_file->crc.c
stays the same.

rar_unpack29() is not invoked yet (it would be for index 4, but the
failure is at index 3), so I think the bug is either right in rar_fmt.c
or in simpler interfaces such as OpenSSL and the CRC-32 implementation
(would be weird).

Alexander

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.