Hi Kim, On Wed, 04 Dec 2013 11:12:21 -0500 Kim Vandry <van...@tzone.org> wrote:
> Hello Stefan, > > I was revieweing your patch, and I was concerned about passing > data.dptr directly to crypt(). Are you sure it's safe? I cannot find > any reference in the db documentation as to whether or not the datum > returned by dbm_fetch is guaranteed to be NUL-terminated, but I > believe it isn't. Certainly crypt() expects a normal C > zero-terminated string. http://pubs.opengroup.org/onlinepubs/009695399/functions/crypt.html > The first two characters of this string may be used to perturb the > encoding algorithm. For the basic interface NUL-termination is not required, only that the string has (at least) 2 characters from a limited character set. If the characters are not from this limited set, especially if the first character is '$', then the Glibc crypt() expects '$' + id + '$' + real-salt + '$'. Glibc shouldn't require NUL-termination as long as there is a 3rd '$'. So the lazy check would be to check for a terminating (3rd) '$' for the Glibc extension. The clean way would be passing a NUL-terminated (probably copied if dbm_fetch doesn't NUL-terminate) string if the first 2 characters are not from the limited set . The Glibc API limits real-salt to 16 bytes, and id is so far at most 2 bytes long, so the NUL-terminated salt should fit into 22 bytes (making it 32 shouldn't hurt). In any case I think my patch improves the code - as `char salt[2];' doesn't look like a NUL-terminated 2-character string to me, and passing a not NUL-terminated '$2' string to crypt() sounds dangerous. Thanks for looking into this! regards, Stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
