In cyrus-sasl-2.1.25 there's a bug in gssapi.c that causes a segfault in function sasl_gss_encode. I discovered when it trying to use sssd against a samba4 server. A version built with the modification in the URL works fine. Reproducible: Steps to Reproduce:
Created attachment 4299 [details] Patch to cyrus-sasl-2.1.25 that fixes the segfault in sasl_gss_encode
Keywords: (none) => PATCH, TriagedCC: (none) => guillomovitch, luigiwalser
Thanks! Now I can push the other fix I recently committed to SVN for this as well. Advisory: ======================== Updated cyrus-sasl packages fix possible crashes: Several possible NULL pointer dereferences which could cause crashes (segfaults) in cyrus-sasl 2.1.25, including one in sasl_gss_encode() in gssapi.c and others due to the use of crypt() with glibc 2.17, have been fixed. References: http://www.spinics.net/lists/cyrus-sasl/msg02004.html http://seclists.org/oss-sec/2013/q3/99 ======================== Updated packages in core/updates_testing: ======================== cyrus-sasl-2.1.25-12.1.mga3 libsasl2-2.1.25-12.1.mga3 libsasl2-devel-2.1.25-12.1.mga3 libsasl2-plug-anonymous-2.1.25-12.1.mga3 libsasl2-plug-crammd5-2.1.25-12.1.mga3 libsasl2-plug-digestmd5-2.1.25-12.1.mga3 libsasl2-plug-plain-2.1.25-12.1.mga3 libsasl2-plug-scram-2.1.25-12.1.mga3 libsasl2-plug-login-2.1.25-12.1.mga3 libsasl2-plug-gssapi-2.1.25-12.1.mga3 libsasl2-plug-otp-2.1.25-12.1.mga3 libsasl2-plug-sasldb-2.1.25-12.1.mga3 libsasl2-plug-srp-2.1.25-12.1.mga3 libsasl2-plug-ntlm-2.1.25-12.1.mga3 libsasl2-plug-mysql-2.1.25-12.1.mga3 libsasl2-plug-pgsql-2.1.25-12.1.mga3 libsasl2-plug-sqlite3-2.1.25-12.1.mga3 libsasl2-plug-ldapdb-2.1.25-12.1.mga3 from cyrus-sasl-2.1.25-12.1.mga3.src.rpm
Component: RPM Packages => SecurityAssignee: bugsquad => qa-bugsSummary: SIGSEV in gssapi.c => cyrus-sasl: NULL deref causing SIGSEGV in gssapi.c, NULL derefs from crypt()Severity: critical => normal
That was quick. The version in core/updates_testing works fine in my test setup (but keep in mind it's not a comprehensive test, I just have sssd working against samba 4 using gssapi). Thank you.
Thanks Luca, is that i586 or x86_64 please?
my test VM is x86_64
Thanks. It seems quite a complex setup. Do you mind sharing how you configured everything to reproduce this?
Whiteboard: (none) => mga3-64-ok
No, it's not simple, probably there's a simpler way to test, but since I'm a total newbie WRT kerberos I cannot tell. Anyway, here's my setup: I'm currently running in production a samba domain with users in ldap. Ldap is also used to authenticate users for all services (intranet, mail, etc.). I'm trying samba 4 in a VM, so I compiled it from source and did the migration as explained in the samba wiki: https://wiki.samba.org/index.php/Samba4/samba-tool/domain/classicupgrade/HOWTO Once I had this working, I wanted to used Samba 4 active directory for unix users' (like currently I'm using ldap), the options are winbind, nslcd and sssd. I first tried winbind but I didn't like it (for no particular reason), then nslcd and sssd. sssd seems to be the best option, but in the first tests I used ldap simple bind, and that's not optimal, it's better to use kerberos. That's how cyrus-sasl and gssapi enter the picture. For the gory details follow this (longish) thread here https://lists.samba.org/archive/samba/2013-August/175255.html continuation here https://lists.samba.org/archive/samba/2013-August/175344.html
Thanks Luca. So you're running Samba 4 in a Mageia VM packaged from source? I'm just curious. I *so* wish we had it packaged. Do you think you could replicate your client setup in a 32-bit VM to verify it's working there? If so we could get this update released pretty quickly.
Buchan Milne is working on a samba4 package. I'm currently installing mageia 32 to test, it will take a while to replicate the setup.
OK, I installed a minimal mageia 3 32 bits in a VM, installed sssd (which in turn installs libsasl2 and libsasl2-plug-gssapi) and configured it to use the samba 4 server in the other VM. After a few unsuccessful attempts, I managed to get sssd talking to the server and reproduce the crash. Installing the RPMs from updates testing fixed the crash and sssd works.
Thanks Luca!
Whiteboard: mga3-64-ok => mga3-64-ok mga3-32-ok
Thanks Luca, that has saved alot of time, and David for asking. Validating. Advisory from comment 2 uploaded. Could sysadmin please push from core/updates_testing to updates Thanks!
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
Note that my tests only cover gssapi, not the other patch.
Update pushed: http://advisories.mageia.org/MGAA-2013-0097.html
Status: NEW => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED
According to Gentoo, the crypt() issue is CVE-2013-4122: http://www.gentoo.org/security/en/glsa/glsa-201309-01.xml
URL: http://www.spinics.net/lists/cyrus-sasl/msg02004.html => http://lwn.net/Vulnerabilities/565575/Summary: cyrus-sasl: NULL deref causing SIGSEGV in gssapi.c, NULL derefs from crypt() => cyrus-sasl: NULL deref causing SIGSEGV in gssapi.c, NULL derefs from crypt() (CVE-2013-4122)
Also, this advisory should have been a MGASA. I had changed the component to Security because of the crypt() issue.