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.