Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060509215819.GA11262@openwall.com>
Date: Wed, 10 May 2006 01:58:19 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: john --format=NT segfaults when using wrong password file forma

On Tue, May 09, 2006 at 10:06:49PM +0200, Frank Dittrich wrote:
> Solar Designer wrote:
> >I'm afraid that this is not useful at all.  You'd need to rebuild with
> >debugging symbols (-g) and with frame pointers (drop -fomit-frame-pointer)
> >for the backtrace to be useful.
[...]

> You are right. I tried to do that, even wanted to switch off optimization,

FWIW, disabling optimizations usually doesn't help debugging, at least
not with gcc.  It merely results in unoptimal assembly code that is
harder to read, should this turn out to be the most straightforward way
to understand a problem (it sometimes is).  Disabling optimizations may
also make the problem "go away", which is undesired when the intent is
to find and fix the bug.

> A version with just the NT patch applied and
> CFLAGS = -c -Wall -g
> shows:
> 
> (no debugging symbols found)...(no debugging symbols found)...
> Program received signal SIGSEGV, Segmentation fault.
> 0x4009cc36 in strncpy () from /lib/i686/libc.so.6
> gdb>bt
> #0  0x4009cc36 in strncpy () from /lib/i686/libc.so.6
> #1  0x0805ba9f in strcpy ()

This is still wrong.  Perhaps the reason is that I forgot to mention
that you should adjust the LDFLAGS as well (drop the -s from there) and
indeed you did not do it.

> Obviously I was still missing something, otherwise I should
> have found ldr_split_line in the backtrace.

Exactly.

> The offending strncpy is in the patched loader.c
[...]
> This one fails:
>                                strncpy(*ciphertext,"$NT$",4);
> 
> 
> So the error seems to be caused by adjusting the ciphertext
> without verifying whether the format is valid or not.
> At least it indicates that the issue doesn't affect other
> hash algorithms, unless they mess with john's default way
> of doing things.

I'm not surprised.

Can you possibly communicate with Erik to get this fixed for the next
revision of the jumbo patch?

Thanks,

-- 
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.