[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BAY105-F14E4399C35BBC4A3118DE1FDFC0@phx.gbl>
Date: Thu, 12 Jul 2007 22:09:28 +0200
From: "Frank Dittrich" <frank_dittrich@...mail.com>
To: john-users@...ts.openwall.com
Subject: Re: Strange bug when testing --format=ssha
Solar Designer wrote:
>On Thu, Jun 21, 2007 at 11:26:26PM +0200, Frank Dittrich wrote:
> > Benchmarking: Netscape LDAP SSHA MMX [salted SHA1]... FAILED
>(get_hash[0])
>
>Yes, this thing is buggy. I recall that prior to me adding the multi-
>vs. single-salt benchmarks in -all-7, --test for this hash type would
>succeed, but an actual cracking run would report self-test failure.
>The generic code (non-MMX/SSE) for this hash type works fine.
>
>I did not bother trying to get it debugged and fixed. After all, it's
>just a contributed patch (what a good excuse).
The reason I posted this wasn't that I needed this hash algorithm.
I just noticed it when compiling JtR with the jumbo patch applied,
and I didn't find anything related to this issue in the mailing list
archives.
So the intend was more along the lines of *documenting* that a
problem exists.
The only closely related posting I found was this one:
http://article.gmane.org/gmane.comp.security.openwall.john.user/155
It contains a link to the bigpatch status:
http://www.banquise.net/misc/patch-john.html
Here, the status for Netscape LDAP Salted SHA1 is "OK (*)",
with "(*)" meaning:
"this cipher has not been toroughly tested.
It might not work on non x86 architectures."
In September, 2005, the page probably looked more like this:
http://web.archive.org/web/20060317000104/http://www.banquise.net/misc/patch-john.html
So, the warning
"There are many known bugs"
was missing.
> > Then I discovered that the test fails or succeeds depending on
> > which of the two CPUs runs the test.
> > If I run two tests in parallel, one of them fails,
> > the other succeeds.
>
>I cannot confirm this. For me, the test fails or succeeds "randomly",
>regardless of what CPU it runs on and whether there's another instance
>running. Sometimes both instances would fail, sometimes just one, and
>in other cases both would succeed.
Probably I didn't run enough tests to verify the behaviour.
(I didn't automate the tests, but I probably ran about 20 tests startet
manually.
Booting Knoppix I noticed the test which I expected to fail didn't fail,
but then I realized the other one failed.
I repeated the test a few times, and got the same results.
(The CPU on which the test failed was always the same, but it was the one
which "worked correctly" when using the opensuse kernel.)
Probably just coincidence, which I could have found out with better
test automatization.
> > Since john runs a benchmark for many salts and for a single salt,
> > I suspect the bug is triggered immediately after switching
> > the number of salts to test.
>
>Yes, this appears to be the case.
As we know now, thanks to your investigation and your patch,
this guess was wrong as well.
> > (On this box, it's harder to tell which of the CPUs is occupied,
> > because they can't be clocked down individually.)
>
>In "top" from procps 3.x, hit "f", then "j", then Enter. For procps 2.x,
>it's "y" instead of "j". With either version, you can also use "s", "1",
>Enter to have the process list updated every second.
I should have known this. You can't just mention a "problem" which is
totally unrelated to JtR or password security without expecting a helpful
reply.
You are so helpful that you even ignore what's actually on-topic here ;)
I almost feeled somewhat ashamed (I don't find a better term).
I was just too lazy to find out how to solve the "problem", by
googling, or reading the man pages for top, ps or related commands.
Next time, if you feel you really have to compensate for my laziness,
a "man top" would be fine.
Testing --format=krb5 on x86_64 also produces either
failing tests or segfaults, depending on which individual test cases I
comment out or activate.
Running the 32bit x86 binary on the same system works, however.
But on my Intel Core Duo laptop, I get the same problem
running john --test from the Sabayon Linux 3.4 loop3 DVD,
which includes a JtR version with the Jumbo patch applied.
Other people do have similar problems when testing
Kerberos v5 TGT, see:
http://thread.gmane.org/gmane.comp.security.penetration/13622
(I don't think just compiling john with -fno-stack-protector,
as suggested in that thread, really solves the issue.
It might, however avoid the core dump.)
Searching the john-users mailing list archive,
the problem has been reported before:
http://thread.gmane.org/gmane.comp.security.openwall.john.user/1254/
(I don't care whether or not this get fixed.)
Oh, BTW:
I don't know for how long I'll continue posting
to this mailing list, because the German government currently
is creating new stupid laws at a speed I wouldn't have imagined
back in 1989 when the Berlin wall came down...
The latest advances are aimed at "fighting computer criminality".
Nobody knows yet how paranoid you have to be, whether the
current development is more scary or ridiculous:
http://nrrd.de/dasbuch/hadez/now_theyve_done_it_just_owning_hacker_tools_illegal_germany
Sorry if this is too off-topic.
Frank
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
--
To unsubscribe, e-mail john-users-unsubscribe@...ts.openwall.com and reply
to the automated confirmation request that will be sent to you.
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.
