Home page logo
/

oss-sec logo oss-sec mailing list archives

Re: glibc crypt(3), crypt_r(3), PHP crypt() may use alloca()
From: Tomas Hoger <thoger () redhat com>
Date: Fri, 30 Mar 2012 19:56:39 +0200

On Tue, 15 Nov 2011 06:13:24 +0400 Solar Designer wrote:

Alternatively, crypt(3) and crypt_r(3) (and the reference code for
SHA-crypt?) could refuse to work on overly long key or/and salt
strings, but then the question is what they should do on error.
crypt(3) returning NULL and setting errno is SUSv2-compliant, but in
practice is unexpected by many programs.  Thus, I think the functions
would need to return a string that is guaranteed not to match the
salt string, e.g. with something like:

      buffer[0] = '*';
      buffer[1] = '0';
      buffer[2] = '\0';
      if (salt[0] == '*' && salt[1] == '0')
              buffer[1] = '1';

(but also need to check buflen).

Finally, we could use malloc() instead of alloca(), but this doesn't
eliminate the need to potentially handle an error condition (what if
malloc() returns NULL?)

FYI, a fix just got committed upstream, which makes glibc use malloc
instead of alloca for long inputs and hence possibly make crypt() return
NULL on errors:

http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=b8dc394ddfd58bc5d0fe9ecfc970fc42b789a9df

Upstream discussion:

http://sourceware.org/ml/libc-alpha/2012-03/msg01138.html
http://sourceware.org/ml/libc-alpha/2012-03/msg01158.html

-- 
Tomas Hoger / Red Hat Security Response Team


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]