[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 30 Aug 2005 01:43:39 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: trivial parallel processing (4 CPUs)
On Mon, Aug 29, 2005 at 10:08:55AM +0200, Michael Behrisch wrote:
> You can simply create a named pipe (Linux: "mkfifo johnpipe")
> and let one instance of john write the password candidates into:
> Step 2:
> john --stdout -w=words.lst -rules > johnpipe
> Step 3:
> john --stdout -inc > johnpipe
>
> Then you can create an arbitrary number of real cracking sessions which
> read the candidates from the pipe:
> ./john -se=w1 --stdin passwd < johnpipe
> ./john -se=w2 --stdin passwd < johnpipe
> ...
>
> That's it. No hacks, no patches not even a change to the configuration files.
Unfortunately, while this would be an elegant solution, it does not work
reliably. John uses stdio to read wordlists (including from stdin), and
of course stdio makes no attempt to ensure it reads whole lines out of
the file descriptor. Whenever one of the real cracking instances of
John would happen to read a block of data ending in the middle of a
line (and this would happen most of the time!), the next instance to
read data out of the pipe would get a partial line instead of a full one -
and would check a wrong candidate password, missing the one that it was
meant to check. With 4 KB stdio buffers and lines consisting of 10
characters on average, about 0.5% of candidate passwords would not be
checked because of this problem alone (and it's not the only problem!),
resulting in John possibly missing even the weakest passwords.
Another problem is that standards such as the Single Unix Specification
do not require serialization of reads/writes from/to file descriptors.
Whenever two or more threads read off the same fd simultaneously, the
behavior is undefined. Some Unix-like kernels actually happen to
serialize reads/writes (for some or all file types), some don't. Linux
doesn't, except with Openwall patches for 2.4.x kernels where I've
enforced serialization to fight a class of potential security-relevant
in-kernel race conditions (but this hardening measure has no chance to
be accepted upstream). With small reads off pipes things happen to work
"as desired" in practice most of the time, though.
Finally, with the proposed approach, it is impossible to reliably
recover interrupted sessions - even if the problems I've explained above
wouldn't exist.
> A further advantage of this approach is that you can dynamically add
> and remove sessions just by aborting / starting them
Each time you abort a real cracking session, you miss up to a few
hundred of candidate passwords (typical) that this session had buffered
(in the stdio I/O buffer and in John's own data structures). No other
instance of John would pick those since they would have already been
read off the pipe.
> P.S: I did not invent this method, but I forgot where I read this first.
I had seen it before, too. In fact, I've been toying with the idea to
enhance John to actually make a similar method work reliably, -- but I
never actually did that (it's far from trivial).
--
Alexander Peslyak <solar at openwall.com>
GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments
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.
