[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3ecb9d2d67fa338e4077843b4f4e4cb1@smtp.hushmail.com>
Date: Sat, 30 Jun 2012 11:50:15 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: asan report
On 2012-06-30 10:53, Dhiru Kholia wrote:
> So far, I have found out that asan doesn't work with the following formats:
>
> Target : linux-x86-64-clang-debug
>
> $ clang --version
> clang version 3.1 (branches/release_31)
> Target: x86_64-unknown-linux-gnu
> Thread model: posix
I'm confused. I'm the author of most of these lines but I do not see
anything wrong with them.
> 1. xsha
>
> Benchmarking: Mac OS X 10.4 - 10.6 salted SHA-1 [128/128 SSE2
> intrinsics 8x]...
> =================================================================
> ==28010== ERROR: AddressSanitizer global-buffer-overflow on address
> 0x0000006b0240 at pc 0x4da4f4 bp 0x7fff9f71ff10 sp 0x7fff9f71ff08
> READ of size 4 at 0x0000006b0240 thread T0
> #0 0x4da4f4 in set_key /home/dsk/magnum-jumbo/src/XSHA_fmt_plug.c:304
> 0x0000006b0240 is located 0 bytes inside of global variable '.str12
> (formats.c)' (0x6b0240) of size 1
> '.str12 (formats.c)' is ascii string ''
>
> while((temp = *wkey++) & 0xff) { <== problematic code
> if (!(temp & 0xff00))
> {
> *keybuf_word = JOHNSWAP((temp & 0xff) | (0x80 << 8));
> len++;
> goto key_cleaning;
> }
This code does check for ending null. BTW, altering this optimized sse2
key setup is very likely to slow it down.
> 2. trip
>
> Benchmarking: Tripcode DES [128/128 BS SSE2-16]...
> =================================================================
> ==28647== ERROR: AddressSanitizer global-buffer-overflow on address
> 0x0000006b0240 at pc 0x4414c9 bp 0x7fff45bf30c0 sp 0x7fff45bf30b8
> READ of size 8 at 0x0000006b0240 thread T0
> #0 0x4414c9 in set_key /home/dsk/magnum-jumbo/src/trip_fmt.c:547
> 0x0000006b0240 is located 0 bytes inside of global variable '.str12
> (formats.c)' (0x6b0240) of size 1
> '.str12 (formats.c)' is ascii string ''
>
> static void set_key(char *key, int index)
> {
> memcpy(buffer[index].key, key, PLAINTEXT_LENGTH);
> }
>
> This code doesn't seem to check key's length.
But it uses PLAINTEXT_LENGTH. How is this an overflow? A strncpy would
be slower.
magnum
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.
