CVE-2010-0628 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-0628): The spnego_gss_accept_sec_context function in lib/gssapi/spnego/spnego_mech.c in the SPNEGO GSS-API functionality in MIT Kerberos 5 (aka krb5) 1.7 before 1.7.2 and 1.8 before 1.8.1 allows remote attackers to cause a denial of service (assertion failure and daemon crash) via an invalid packet that triggers incorrect preparation of an error token.
Created attachment 227095 [details] mit-krb5-1.8.1.ebuild mit-krb5-1.8.1 is out. Attached is the ebuild that works for me. Couple of points: * Works with openssl-1.0.0. Closes bug #310451 * Added ldap USE flag. Closes bug #177522 * Kerberized versions of telnet, rlogin, rsh, rcp, and ftp clients and daemons are distributed as a seperate tarball from version 1.8 onwards. Hence, the new appl USE flag. These programs are no longer in wide use (OpenSSH is usually used instead). The default is not to install them. Please bump. Thank you.
Created attachment 228577 [details] mit-krb5-1.8.1 with CVE-2010-1320 patch CVE-2010-1320 SUMMARY ======= A double free vulnerability exists in the KDC in MIT krb5 releases krb5-1.7 and later. This is an implementation vulnerability in MIT krb5, and not a vulnerability in the Kerberos protocol. IMPACT ====== An authenticated remote attacker can crash the KDC by inducing the KDC to perform a double free. Under some circumstances on some platforms, this could also allow malicious code execution. Successfully inducing code execution by exploiting a double free is believed to be difficult, and no such exploits are known to exist for this vulnerability. AFFECTED SOFTWARE ================= * KDC in krb5-1.7 and later FIXES ===== * The upcoming krb5-1.8.2 release, as well as an upcoming krb5-1.7 series release, will contain a fix. * Apply the following patch: [...] Ebuild and patch are attached.
Created attachment 228579 [details, diff] CVE-2010-1320 patch
Created attachment 229727 [details] mit-krb5-1.8.1 ebuild Well, looks like splitting the package is the better option. To recap: The bundled kerborized apps are not in wide use anymore. It lets us decouple the release cycles. Ebuilds become much simpler. Also, all the distros I checked (including Debian, Fedora, FreeBSD) either have already split or are in the proces of splitting mit-krb5.
Created attachment 229729 [details] Kerberized programs split from mit-krb5 Kerberized versions of telnet, rlogin, rsh, rcp, ftp clients and telnet, ftp daemons
Could you please change the ebuild, so that it installs 1) kdc.conf.example rather to /var/lib/krb5kdc/ 2) or add some file /etc/conf.d/mit-krb5kdc with some line like export KRB5_KDC_PROFILE="/etc/kdc.conf". I was highly confused, why my changes to the port settings were not respected until I found out about the default location for the KDC configuration. Thanks a lot; also for the tools splitup. :) And does somebody know about QA warnings after compile? They were introducted in the 1.7 ebuilds. And I'm not quite sure, if there wasn't a patch to the 1.6.3-r6 ebuild that actually fixed those. If it is not about a missing patch, then I will directly ask the MIT guys about it. A last thing: is it possible to add a dependency to an ebuild, so that ebuild something.ebuild manifest checks for the dependent files? Because I at first didn't copy the init.d scripts to my overlay and was confused, why those files were not created.
(In reply to comment #6) > Could you please change the ebuild, so that it installs > 1) kdc.conf.example rather to /var/lib/krb5kdc/ Agreed that /var/lib/krb5kdc is the correct place. I keep mine in /var/lib as well. However, in gentoo previous versions placed kdc.conf.example in /etc and suddenly changing the location is not a good move. We do not want to surprise users. I symlink from /etc to /var/lib. You can also use the environment variable KRB5_KDC_PROFILE to change the location. > And does somebody know about QA warnings after compile? Upstream AFAIK. > A last thing: is it possible to add a dependency to an ebuild, so that > ebuild something.ebuild manifest checks for the dependent files? You can do "newinitd ... ... || die ..." I guess but better still read your build logs cerafully first time you change the ebuild.
(In reply to comment #7) > (In reply to comment #6) > > Could you please change the ebuild, so that it installs > > 1) kdc.conf.example rather to /var/lib/krb5kdc/ > > Agreed that /var/lib/krb5kdc is the correct place. I keep mine in /var/lib as > well. However, in gentoo previous versions placed kdc.conf.example in /etc and > suddenly changing the location is not a good move. We do not want to surprise > users. > > I symlink from /etc to /var/lib. You can also use the environment variable > KRB5_KDC_PROFILE to change the location. Okay, I see your point to not surprise the users. So I'd propose that the ebuild either creates a symlink from /etc/kdc.conf to /var/lib/krb5kdc/kdc.conf (if there is no kdc.conf in /var/lib/krb5kdc/) or adds the before mentioned /etc/conf.d/mit-krb5kdc that exports KRB5_KDC_PROFILE. Otherwise it feels a little bit inconsistent, when you emerge it the first time. And if you still don't like it, what about a short notice at the end of the compile cycle? Something like: "Please note that mit-krb5 looks for the KDC's configuration in /var/lib/krb5kdc/ by default. You could change this behaviour by exporting KRB5_KDC_PROFILE in /etc/conf.d/mit-krb5kdc." > > And does somebody know about QA warnings after compile? > > Upstream AFAIK. that sounds great. > > A last thing: is it possible to add a dependency to an ebuild, so that > > ebuild something.ebuild manifest checks for the dependent files? > > You can do "newinitd ... ... || die ..." I guess but better still read your > build logs cerafully first time you change the ebuild. > I just read my comment again, and realized that I wasn't clear enough. I didn't change the ebuild. I just didn't want to put it directly into the portage tree but an overlay so that I can easily remove it, when it has finally been added to the official tree. But this way emerge won't find the files mit-krb5kdc.initd and mit-krb5kadmind.initd (from /usr/portage/app-crypt/mit-krb5/files). And I was wondering, if it is possible to have ebuild mit-krb5-1.8.1.ebuild manifest to fail, if these init.d scripts haven't been copied to the overlay as well.
Created attachment 229805 [details] mit-krb5-1.8.1.ebuild (In reply to comment #8) > And if you still don't like it, what about a short notice at the end of the > compile cycle? Something like: Symlinking is a gross hack. Won't do. Moved example kdc.conf file to /var/lib/krb5kdc. Thank you for your feedback.
(In reply to comment #9) > Created an attachment (id=229805) [details] > mit-krb5-1.8.1.ebuild Thanks. Committed for you, I added a src_prepare() step since that is the proper place to do patching. In the future, configure your editor for UNIX line endings. I had to run dos2unix on all of your files.
(In reply to comment #5) > Created an attachment (id=229729) [details] > Kerberized programs split from mit-krb5 > > Kerberized versions of telnet, rlogin, rsh, rcp, ftp clients and telnet, ftp > daemons > Committed. Thanks.
Just tested the committed ebuild. Works perfectly. Thanks to both of you.
Newer versions of app-crypt/mit-krb5 are now stable. GLSA vote: no.
Old and DoS only so GLSA Vote: no -> Closing. Feel free to reopen if you disagree.
