Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 27 Jun 2012 14:47:04 +0530
From: Dhiru Kholia <dhiru.kholia@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: SSH format crashes when built using "linux-x86-clang-debug"

On Wed, Jun 27, 2012 at 1:51 PM, Solar Designer <solar@...nwall.com> wrote:
> On Wed, Jun 27, 2012 at 12:04:24PM +0530, Dhiru Kholia wrote:
>> SSH format crashes when built using "linux-x86-clang-debug".
>>
>> $ ../run/john -format=ssh -t
>> Benchmarking: SSH RSA/DSA (one 2048-bit RSA and one 1024-bit DSA key)
>> [32/32]...
>> ==5844== ERROR: AddressSanitizer global-buffer-overflow on address
>> 0x0832f51f at pc 0x816a88b bp 0xbff25f58 sp 0xbff25f50
>
> Can you provide a little bit of disassembly around this place?
>
>> READ of size 1 at 0x0832f51f thread T0
>
> Notice "size 1".
>
>> $ addr2line -a 0x816a88b  -e ../run/john
>> 0x0816a88b
>> /home/dsk/magnum-jumbo/src/bench.c:150
>>
>> bench.c line 150 ==> two_salts[index] = mem_alloc(format->params.salt_size);
>
> I think this is wrong.  Maybe you ran addr2line on a different version
> of the john binary or something.  That line should not involve any
> "size 1" access.

Binary was same across run and resolution. However, someone told me to
use llvm/projects/compiler-rt/lib/asan/scripts/asan_symbolize.py
script instead of addr2line program. Using it tells me the following,
(binary is different this time),

$ ~/llvm/projects/compiler-rt/lib/asan/scripts/asan_symbolize.py < log
Benchmarking: SSH RSA/DSA (one 2048-bit RSA and one 1024-bit DSA key) [32/32]...
==7052== ERROR: AddressSanitizer global-buffer-overflow on address
0x0833051f at pc 0x816b42b bp 0xbfcb22b8 sp 0xbfcb22b0
READ of size 1 at 0x0833051f thread T0
    #0 0x816b42b in benchmark_format /home/dsk/magnum-jumbo/src/bench.c:164
    #1 0x816bec1 in benchmark_all /home/dsk/magnum-jumbo/src/bench.c:453
    #2 0x818ba6a in john_run /home/dsk/magnum-jumbo/src/john.c:873
    #3 0x818521c in main /home/dsk/magnum-jumbo/src/john.c:1093
    #4 0xb72d73d5 in __libc_start_main ??:0
0x0833051f is located 30 bytes to the right of global variable
'has_been_cracked (pdf_fmt.c)' (0x8330500) of size 1
  'has_been_cracked (pdf_fmt.c)' is ascii string ''
==7052== ABORTING
Stats: 0M malloced (1M for red zones) by 3262 calls
Stats: 0M realloced by 11 calls
Stats: 0M freed by 150 calls
Stats: 0M really freed by 0 calls
Stats: 32M (8196 full pages) mmaped in 8 calls
  mmaps   by size class: 8:16383; 9:8191; 10:4095; 11:2047; 12:1024;
13:512; 14:256; 17:32;
  mallocs by size class: 8:3209; 9:22; 10:3; 11:12; 12:5; 13:3; 14:1; 17:7;
  frees   by size class: 8:109; 9:22; 10:3; 11:10; 12:5; 13:1;
  rfrees  by size class:
Stats: malloc large: 7 small slow: 13
Shadow byte and word:
  0x210660a3: f9
  0x210660a0: 01 f9 f9 f9
More shadow bytes:
  0x21066090: 00 00 00 00
  0x21066094: 00 00 00 00
  0x21066098: 00 00 00 f9
  0x2106609c: f9 f9 f9 f9
=>0x210660a0: 01 f9 f9 f9
  0x210660a4: f9 f9 f9 f9
  0x210660a8: 00 00 00 00
  0x210660ac: 01 f9 f9 f9
  0x210660b0: f9 f9 f9 f9

The offending line seems to be  memcpy(two_salts[index], salt,
format->params.salt_size); this time. I can see no problem with it. I
commented it out and ssh format runs fine. (but this solution can't be
correct!).

-- 
Cheers,
Dhiru

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.