[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <281d6e57937abf626e2a42ed1f3c8c45@smtp.hushmail.com>
Date: Wed, 27 Jun 2012 21:46:25 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: RAR cmp_one(3) failures
On 2012-06-27 21:28, Solar Designer wrote:
> 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.
Well we have plain[16] and inlen is always 16 so I would consider that a
bug in OpenSSL. But their documentation is very poor so I might have
misunderstood something.
> 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).
Dang, I've been looking at the wrong place all the time. My comment in
the self-tests does not reflect the actual order (-m3 vs -m0)!
magnum
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.
