Fedora has issued an advisory on July 9: https://lists.fedoraproject.org/pipermail/package-announce/2014-August/136360.html There doesn't appear to be an upstream advisory for that one (CVE-2014-434[1-4]), but there is this upstream advisory (CVE-2014-4345): http://web.mit.edu/kerberos/www/advisories/MITKRB5-SA-2014-001.txt Mageia 3 and Mageia 4 are also affected. The RedHat bugs have links to the upstream commits to fix the first 4 CVEs (and of course their update has patches), and the upstream advisory has a patch for the last CVE. Reproducible: Steps to Reproduce:
Whiteboard: (none) => MGA4TOO, MGA3TOO
Patches packages uploaded for Mageia 3, Mageia 4, and Cauldron. Advisory: ======================== Updated krb5 packages fix security vulnerabilities: MIT Kerberos 5 allows attackers to cause a denial of service via a buffer over-read or NULL pointer dereference, by injecting invalid tokens into a GSSAPI application session (CVE-2014-4341, CVE-2014-4342). MIT Kerberos 5 allows attackers to cause a denial of service via a double-free flaw or NULL pointer dereference, while processing invalid SPNEGO tokens (CVE-2014-4343, CVE-2014-4344). In MIT Kerberos 5, when kadmind is configured to use LDAP for the KDC database, an authenticated remote attacker can cause it to perform an out-of-bounds write (buffer overflow) (CVE-2014-4345). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4341 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4342 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4343 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4344 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4345 http://web.mit.edu/Kerberos/advisories/MITKRB5-SA-2014-001.txt https://lists.fedoraproject.org/pipermail/package-announce/2014-August/136360.html ======================== Updated packages in core/updates_testing: ======================== krb5-1.11.1-1.4.mga3 libkrb53-devel-1.11.1-1.4.mga3 libkrb53-1.11.1-1.4.mga3 krb5-server-1.11.1-1.4.mga3 krb5-server-ldap-1.11.1-1.4.mga3 krb5-workstation-1.11.1-1.4.mga3 krb5-pkinit-openssl-1.11.1-1.4.mga3 krb5-1.11.4-1.1.mga4 libkrb53-devel-1.11.4-1.1.mga4 libkrb53-1.11.4-1.1.mga4 krb5-server-1.11.4-1.1.mga4 krb5-server-ldap-1.11.4-1.1.mga4 krb5-workstation-1.11.4-1.1.mga4 krb5-pkinit-openssl-1.11.4-1.1.mga4 from SRPMS: krb5-1.11.1-1.4.mga3.src.rpm krb5-1.11.4-1.1.mga4.src.rpm
Version: Cauldron => 4Assignee: guillomovitch => qa-bugsWhiteboard: MGA4TOO, MGA3TOO => MGA3TOO
Debian has issued an advisory for this on August 9: https://www.debian.org/security/2014/dsa-3000 LWN reference for CVE-2014-4345: http://lwn.net/Vulnerabilities/608410/
Procedure: https://wiki.mageia.org/en/QA_procedure:Krb5
CC: (none) => remiWhiteboard: MGA3TOO => MGA3TOO has_procedure
I tried to use the procedure on the wiki (note that the /etc/krb5.conf has to be unmodified from the krb5 package), and I got to the last step of "krlogin $(hostname)" and get: error getting credentials: Server not found in Kerberos database I tried krb5-telnet and it still asks for my password. Not sure what to do here.
CC: (none) => davidwhodgins
I am giving this a go also (MGA4 64 real h/w), but the script krb5_server_setup.sh $USER is behaving oddly. I first tried after su (mistake?). BTAIM the eventual downloads took forever - mostly total inactivity; they clagged: rsync://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/4/x86_64/media/core/updates/lib64ldap2.4_2-devel-2.4.38-1.1.mga4.x86_64.rpm ... methodd ail-lwytho: Methodd 'rsync': gadael gyda 35 which means 'failed to re-load; rsync failed'; and left about 1/2 undone. Re-trying yielded the same result. Server problem? Will re-try another time.
CC: (none) => lewyssmith
If your urpmi won't work then yeah you're really going to have problems. You should fix that. It's ok to run the script as root, just make sure the argument you give it is the username of the regular user you're going to test with.
(In reply to David Walser from comment #6) > If your urpmi won't work then yeah you're really going to have problems. > You should fix that. I really *was* a server problem; other urpmi's clagged. The script flew today. > It's ok to run the script as root, just make sure the argument you give it > is the username of the regular user you're going to test with. I did so because I got bounced from sudo, not in its group. Useful tip re giving the correct username; thanks for that. Problem now at the last hurdle: At the end of the instructions (all of which went OK), "$ krlogin $(hostname) which should show This rlogin session is encrypting all data transmissions" does *not*... $ krlogin $(hostname) $ Is this OK as a basis for testing the update?
Oh, it looks like it worked for you. No fair :o( Yes, you can OK the update.
I may have misled... In my previous Comment 7, re-looking at the procedure in Comment 3, I found that before updating I had *not* done kinit or klist, just the krlogin. So I cannot say what would have happened if I had, because *after* updating from the Test repo to: lib64krb53-devel-1.11.4-1.1.mga4 krb5-workstation-1.11.4-1.1.mga4 krb5-server-ldap-1.11.4-1.1.mga4 krb5-appl-clients-1.0.3-3.mga4 lib64krb53-1.11.4-1.1.mga4 krb5-1.11.4-1.1.mga4 krb5-server-1.11.4-1.1.mga4 krb5-appl-servers-1.0.3-3.mga4 [does the divergence of not updated krb5-appl matter?] I get: $ kinit kinit: Client not found in Kerberos database while getting initial credentials $ klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_1001) $ krlogin $(hostname) $ So krlogin is the same - OK apparently. Was the absence of first-time-round kinit important? If so, I will uninstall it all & go back to square 1. It is not long to install etc.
That's strange. I wonder if krlogin is just ignoring kerberos and doing a regular rlogin. I've never used rlogin, so not sure how it's supposed to work, but surprised it's not asking for a password. Anyway, you shouldn't be getting those errors from kinit/klist, so you probably made a misstep in the procedure somewhere. As for krb5-appl, that's a different SRPM.
From Comment 9, I am in a mess. I installed krb5 to do this testing, & wanting to pull it to start all over again, it wants to take half the system with it. Can anyone suggest how I can 're-initialise' myself (user) so as to resume the given test procedure from $ kinit $ klist ? I imagine that would be legitiamte: the actual installation up to there was fine. Or can I safely re-run # /home/$USER/bin/krb5_server_setup.sh $USER to re-set things? ($USER = Unix username).
You don't need to uninstall the packages. As I noted earlier, you need a fresh copy of /etc/krb5.conf when you run the script. The script should have saved it as /etc/krb5.conf.original when it ran before, so just move that back to /etc/krb5.conf and re-run the script.
David: Comment 12 > As I noted earlier, you need a fresh copy of /etc/krb5.conf when you run the script If this refered to Comment 4 > (note that the /etc/krb5.conf has to be unmodified from the krb5 package) I had not grasped the message. Sorry. So thanks for your explicit advice in Comment 12. Bingo! Using the updated krb5 1.11.4-1.1.mga4 # mv krb5.conf.original krb5.conf [To clear the decks] # /home/lewis/bin/krb5_server_setup.sh lewis etc as root to # systemctl restart xinetd.service --- $ kinit [omitted 1st go] Password for lewis@LOCALHOST: $ klist [omitted 1st go] Ticket cache: FILE:/tmp/krb5cc_1001 Default principal: lewis@LOCALHOST Valid starting Expires Service principal 16.08.14 21:09:57 17.08.14 21:09:57 krbtgt/LOCALHOST@LOCALHOST renew until 16.08.14 21:09:57 $ krlogin $(hostname) This rlogin session is encrypting all data transmissions. Last login: Thu Jun 12 20:49:11 on tty1 You have mail. As per the procedure, hence "testing is complete for basic kerberos functionality" At last, OK. I have installed krb5-appl-clients & krb5-appl-servers, so if anyone can advise additional things to try - welcome.
Whiteboard: MGA3TOO has_procedure => MGA3TOO has_procedure MGA4-64-OK
Nice job Lewis. If you want one more thing to try, enable the krb5-telnet xinetd service too and then try (in your case) "telnet -k LOCALHOST -l lewis localhost" and I believe it should also log you back into yourself without a password.
(In reply to David Walser from comment #14) > If you want one more thing to try, enable the krb5-telnet xinetd service too In MCC/Services, krb5-telnet only had the 'enable on demand' button: unset. I set it, but there were nor buttons to start the service. So tried in hope, gueswork: # systemctl enable krb5-telnet Failed to issue method call: No such file or directory # systemctl start krb5-telnet Failed to issue method call: Unit krb5-telnet.service failed to load: No such file or directory. Trying none-the-less
[continued from above, things disappeared] > then try (in your case) "telnet -k LOCALHOST -l lewis localhost" and I believe it > should also log you back into yourself without a password. Trying none-the-less: $ telnet -k LOCALHOST -l lewis localhost Trying 127.0.0.1... Connected to localhost (127.0.0.1). Escape character is '^]'. Password: [replied with that for krb5 user from successful 2nd setup] Login incorrect Trying again: $ telnet -k LOCALHOST -l lewis localhost Trying 127.0.0.1... Connected to localhost (127.0.0.1). Escape character is '^]'. Password: [replied with normal Unix user password, same for 1st abortive setup] Last login: Sun Aug 17 20:06:30 from localhost You have mail. This does not look too sensible.
You enable krb5-telnet the same way you enabled krlogin, they're both xinetd services (but I guess you figured that out). Maybe kerberized telnet doesn't work? I'm not sure.
I took it you meant (which I did):- $ kinit Password for lewis@LOCALHOST: [krb5 user password OK] $ klist Ticket cache: FILE:/tmp/krb5cc_1001 Default principal: lewis@LOCALHOST Valid starting Expires Service principal 17.08.14 22:20:29 18.08.14 22:20:29 krbtgt/LOCALHOST@LOCALHOST renew until 17.08.14 22:20:29 $ telnet -k LOCALHOST -l lewis localhost Trying 127.0.0.1... Connected to localhost (127.0.0.1). Escape character is '^]'. Password: [tried krb5 user password] Login incorrect login: lewis Password: [Unix user password OK] Last login: Sun Aug 17 20:06:57 from localhost $ I don't know whether I am talking to Localhost directly or via telnet. This is all a quaqmire to me. Not worth chasing?
Yeah don't worry about it. Proceed with the krlogin tests.
Tested on M3 and M4, i586 and x86_64. Validating the update. Someone from the sysadmin team please push 13882.adv to updates.
Keywords: (none) => validated_updateWhiteboard: MGA3TOO has_procedure MGA4-64-OK => MGA3TOO has_procedure MGA4-64-OK MGA3-64-OK MGA3-32-OK MGA4-32-OK advisoryCC: (none) => sysadmin-bugs
An update for this issue has been pushed to Mageia Updates repository. http://advisories.mageia.org/MGASA-2014-0345.html
Status: NEW => RESOLVEDResolution: (none) => FIXED