[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150815131613.GB11187@openwall.com>
Date: Sat, 15 Aug 2015 16:16:13 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: --test-full=0 crashes the Bitcoin format
Kai,
On Sat, Aug 15, 2015 at 04:39:04PM +0800, Kai Zhao wrote:
> There maybe at least 1 crash when you run 100 times. As to asan, I think
> it does not help. I have not see any asan error.
OK. The lack of ASan errors can help narrow down the search, too - when
you review the code, you won't need to spend time on potential issues
that would be expected to be detected by ASan.
For example, the memory overwrite might be inside calls into libcrypto
functions. Since you're only compiling JtR itself with ASan, those
would go undetected. And yes, compiling OpenSSL with ASan as well
might be a way to figure this out. Or just careful review of the code
will do, probably quicker.
> It can be reproduced separately almost 1~2 crash with 200 times. I create
> an issue:
>
> https://github.com/magnumripper/JohnTheRipper/issues/1667
In there, you wrote:
"If your bitcoin.max is not 64, I think you can not reproduce this bug.
Maybe you can reproduce it on super."
What's "bitcoin.max"? I can't find it:
[solar@...er src]$ fgrep -ri bitcoin.max .
[solar@...er src]$
Do you possibly mean this format's max_keys_per_crypt? If so, of course
you can make it 64 on your laptop as well: set OMP_NUM_THREADS=32 before
running john. Like this:
OMP_NUM_THREADS=32 ./john pwfile --format=bitcoin --wordlist=pwd.lst --skip-self-test
in your test script. Then it will likely trigger the issue even on your
laptop. You might need to give at least two logical CPUs to the VM, though.
> To my surprise, sometimes it reports other errors, such as:
>
> Using default input encoding: UTF-8
> Loaded 1 password hash (Bitcoin [SHA512 AES 128/128 AVX 2x])
> Will run 32 OpenMP threads
> Press 'q' or Ctrl-C to abort, almost any other key for status
> crypt_all(*pcount=64)
> openwall (?)
> *** glibc detected *** ./john: malloc(): memory corruption:
> 0x0000000002b04060 ***
> *** glibc detected *** ./john: malloc(): memory corruption:
> 0x0000000002b04060 ***
That's curious.
Kai, you're currently running two instances of john on super:
kai 28475 1159 0.0 2413324 7392 ? Sl 05:50 7207:40 ./john --test-full=0 --format=bitcoin
kai 31899 825 0.0 2413324 7360 ? Sl 06:29 4806:53 ./john --test-full=0 --format=bitcoin
bringing load average to 37.00. What are these trying to achieve?
Suppose one of them or both would crash, would this help in any way?
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.
