My next class:

telnetd deja vu, this time it is Kerberos 5 telnetd

Published: 2007-04-04. Last Updated: 2007-04-05 02:15:58 UTC
by Jim Clausing (Version: 3)
0 comment(s)
It seems like it was just a couple of weeks ago that we noted issues with the Solaris telnetd.  A couple of our readers took exception to our statement in the earlier story that telnet shouldn't be open to the internet.  Some of them pointed out that Kerberized telnetd uses much stronger authentication and can optionally encrypt traffic.  That is all well and good, but I don't consider that ordinary telnet(d).  Today, I noticed a RedHat bulletin (and subsequently, the official MIT advisory) about a vulnerability in Kerberos 5 telnetd (so it isn't any safer from bugs creeping into the code) that could allow unauthenticated root login by passing a crafted username (a different bug than the Solaris one).   Note that in neither case is the issue with the client, the issue is on the server side.  There are still valid reasons to have the telnet client on machines.  Anyway, krb5-telnet is not enabled by default on RedHat (or any other Linux/Unix that I'm aware of), but if you use it, update as soon as possible/practical.  I assume that other Linux distributions will have updates soon, if not already available.  If you are building from source, please see the MIT advisory.

References:
http://web.mit.edu/Kerberos/advisories/MITKRB5-SA-2007-001-telnetd.txt
http://web.mit.edu/Kerberos/advisories/MITKRB5-SA-2007-002-syslog.txt
https://rhn.redhat.com/errata/RHSA-2007-0095.html
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229782
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-0956 (not live yet)
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-0957 (not live yet)

UPDATE:  Yes, I did see the other 2 advisories from MIT, one for a syslog issue and one for a double free.  They are all fixed, I wrote about the telnetd one because that appears to me to be the worst and because it was eerily similar to the Solaris thing in Feb, but you should patch for all 3.

UPDATE 2:  On further reading of the syslog issue, it appears to be pretty serious, too.  It potentially allows remote code execution on the KDC.


Keywords:
0 comment(s)
My next class:

Comments


Diary Archives