john-dev - Undefined behavior in bench.c (null pointer passed as argument 1 to memcpy)

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date: Wed, 06 May 2015 02:18:17 +0200
From: Frank Dittrich <frank.dittrich@...lbox.org>
To: john-dev@...ts.openwall.com
Subject: Undefined behavior in bench.c (null pointer passed as argument 1
 to memcpy)

Solar,

I first found this for bleeding jumbo, see
https://github.com/magnumripper/JohnTheRipper/issues/1253.

I dan reproduce it with the latest master commit.
This is with gcc 5.1.1 on Fedora 22 beta and libubsan installed:

 git diff
diff --git a/src/Makefile b/src/Makefile
index 3486bf4..47247b6 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -30,11 +30,11 @@ OMPFLAGS =
 #OMPFLAGS = -openmp
 # Sun Studio with OpenMP (set the OMP_NUM_THREADS env var at runtime)
 #OMPFLAGS = -xopenmp
-CFLAGS = -c -Wall -Wdeclaration-after-statement -O2
-fomit-frame-pointer $(OMPFLAGS)
+CFLAGS = -c -Wall -Wdeclaration-after-statement -O2
-fomit-frame-pointer -fsanitize=nonnull-attribute $(OMPFLAGS)
 # CFLAGS for use on the main john.c file only
 CFLAGS_MAIN = $(CFLAGS)
 ASFLAGS = -c $(OMPFLAGS)
-LDFLAGS = -s $(OMPFLAGS)
+LDFLAGS = -s -fsanitize=nonnull-attribute $(OMPFLAGS)
 OPT_NORMAL = -funroll-loops
 # Remove the "-Os" if you're using an ancient version of gcc
 OPT_INLINE = -Os -funroll-loops -finline-functions
[fd@...b src]$ make -s clean; make -s -j 8 linux-x86-64-avx
[fd@...b src]$ ../run/john --test --format=LM
Benchmarking: LM [DES 128/128 AVX-16]... bench.c:138:3: runtime error:
null pointer passed as argument 1, which is declared to never be null
DONE
Raw:    81235K c/s real, 81398K c/s virtual


bench.c line 138 is:

		memcpy(two_salts[index], salt, format->params.salt_size);

and, apparently, two_salts[index] is NULL here (and for other saltless
formats).

Since this is core code, magnum would obviously prefer a core change
over a jumbo specific change.


I tested jumbo with all -fsanitize=undefined options except
-fsanitize=alignment, which resulted in a huge number of false positives
for x86, and this was the only error I found for all the other
-fsanitize options related to undefined behavior.

For -fsanitize=alignment, there are error messages for MD5_std.c, lines
745-752: store to misaligned address ... for type "MD5_word', which
requires 4 byte alignment.

Frank

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.