Package: libcrack2
Version: 2.9.0-1
Severity: important

There appears to be something wrong with the current version
of libcrack that causes it to misbehave on each call to FascistCheck
after the first.  It occurs more commonly with small dictionaries.

Consider the following simple test program in C:

#include <crack.h>
#include <stdio.h>

int
main(int argc, char *argv[])
{
    const char *result;
    int i;
    static const char *const passwords[] = {
        "known good password", "password", "Password"
    };

    for (i = 0; i < 3; i++) {
        result = FascistCheck(passwords[i], argv[1]);
        printf("%s - %s\n", passwords[i], result == NULL ? "good" : result);
    }
    return 0;
}

This takes a cracklib dictionary as the first argument and attempts
three passwords with it.  Build a dictionary containing only the
word password.  FascistCheck should then accept the first password
but reject the next two.  But:

wanderer:~$ echo password | cracklib-format | cracklib-packer dictionary
1 1
wanderer:~$ ./test-cracklib dictionary
known good password - good
password - good
Password - good

This appears to somehow be based on the size of the dictionary.  It
seems to only fail with smaller dictionaries.  If I add 100 more words:

wanderer:~$ echo password > dictionary
wanderer:~$ cracklib-format dictionary | cracklib-packer dictionary
101 101
wanderer:~$ ./test-cracklib dictionary
known good password - good
password - it is based on a dictionary word
Password - good

Note that it's still accepting the last, like it couldn't find password
in the dictionary the second time.  But if I add all of the system
wordlist:

wanderer:~$ cat /usr/share/dict/words >> dictionary
wanderer:~$ cracklib-format dictionary | cracklib-packer dictionary
83926 83926
wanderer:~$ ./test-cracklib dictionary
known good password - good
password - it is based on a dictionary word
Password - it is based on a dictionary word

now it works properly.

This only happens when all of the tests are in the same program.  If I
only call FascistCheck once per program invocation, it works properly.
For instance, watch what happens if I go back to the single word
dictionary but move the known good password to the tail end of the array:

wanderer:~$ echo password | cracklib-format | cracklib-packer dictionary
1 1
wanderer:~$ ./test-cracklib dictionary
password - it is based on a dictionary word
Password - good
known good password - good

It looks like the first response is always correct, but then CrackLib
may just start returning success for all subsequent lookups unless the
dictionary is large.  (And it's possible that it still sometimes does it
with large dictionaries, as I suspect it depends on internal state.)

This makes me think that something in the algorithm of looking up words in
the dictionary is broken.  Looking at the code, the only static variable
that I see that could explain erroneous state held in the process is in
packlib.c in GetPW.  I strongly suspect something is incorrect about the
prevblock logic after the first call to FascistCheck.

The whole prevblock bit doesn't make any sense to me anyway, since that
static variable preserves state across entirely different dictionaries.
A different dictionary can be passed to FascistCheck each time, but the
check for prevblock == thisblock doesn't appear to even notice that the
dictionary has changed out from under it.

I suspect all of this prevblock logic should simply be removed.

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.10-2-686-pae (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libcrack2 depends on:
ii  libc6              2.17-92+b1
ii  multiarch-support  2.17-92+b1

Versions of packages libcrack2 recommends:
ii  cracklib-runtime  2.9.0-1

libcrack2 suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to