Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 30 Aug 2005 01:43:39 +0400
From: Solar Designer <>
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>
GPG key ID: B35D3598  fp: 6429 0D7E F130 C13E C929  6447 73C3 A290 B35D 3598 - bringing security into open computing environments

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ