Re: CVE request: Cyrus-sasl NULL ptr. dereference

[Sebastian Krahmer <krahmer () suse de>]

Hi,

Even if it won't be a DoS, it could potentially be an
auth bypass. What if you can alloc so much memory in
one of the threads that one alloc would return
(and actually alloc space at) NULL which
you could fill with your own pwd struct? I am not so deep
in the glibc heap to know whether this could still work
(also to mention mmap_min_addr).

Sebastian

On Fri, Jul 12, 2013 at 07:35:07PM +0400, Solar Designer wrote:
> On Fri, Jul 12, 2013 at 03:27:18PM +0000, mancha wrote:
> > Starting with glibc 2.17 (eglibc 2.17), crypt() fails with
> > EINVAL (w/ NULL return) if the salt violates specifications.
> > Additionally, on FIPS-140 enabled Linux systems, DES/MD5-encrypted
> > passwords passed to crypt() fail with EPERM (w/ NULL return).
> >
> > When authenticating against Cyrus-sasl via mechanisms that use
> > glibc's crypt (e.g. getpwent or shadow auth. mechs), and this
> > crypt() returns a NULL as glibc 2.17+ does on above-described
> > input, the client crashes the authentication daemon resulting
> > in a DoS.
>
> Does this really crash the entire daemon process rather than just one of
> its children (where a new one would be spawned for another request)?
>
> I think this needs to be clarified, and the answer will affect whether
> we have a security issue (CVE-worthy) or not.
>
> Alexander

-- 

~ perl self.pl
~ $_='print"\$_=\47$_\47;eval"';eval
~ krahmer () suse de - SuSE Security Team