Exposure:
Remote root compromise through buffer handling flaws
Confirmed vulnerable:
Up-to-date Debian 3.0 woody (issue is Debian-specific)
Debian netkit-telnet-ssl-0.17.24+0.1 package
Debian netkit-telnet-ssl-0.17.17+0.1 package
Mitigating factors:
Telnet service must be running and accessible to the attacker.
Nowadays, telnet service presence on newly deployed Linux hosts is
relatively low. The service is still used for LAN access from other unix
platforms, and to host various non-shell services (such as MUDs).
Problem description:
Netkit telnetd implementation shipped with Debian Linux appears to be
lacking the AYT vulnerability patch. This patch was devised by Red Hat
(?) and incorporated into Debian packages, but later dropped.
This exposes the platform to a remote root problem discovered by scut of
TESO back in 2001 (CVE-2001-0554), as well as to other currently
unpublished flaws associated with the old buffer handling code, and
elliminated by the Red Hat's overhaul of buffer handling routines.
Based on a review of package changelogs, my best guess is that the patch
was accidentally dropped by Christoph Martin in December 2001, but I
have not researched the matter any further.
Vendor response:
I have contacted Debian security staff on August 29, and received a
confirmation of the problem from Matt Zimmerman shortly thereafter.
Since this is not a new flaw, I did not plan to release my own advisory,
hoping they will release a DSA bulletin and fix the problem. Three weeks
have passed, however, and Debian did not indicate any clear intent to
release the information any time soon. They did release nine other
advisories in the meantime, some of which were of lesser importance.
As such, I believe it is a good idea to bring the problem to public
attention, particularly since those running telnetd were and are,
unbeknownst to them, vulnerable to existing exploits.
Workaround:
Disable telnet service if not needed; manually apply Red Hat
netkit patches, or compile the daemon from Red Hat sources.
Note that netkit as such is no longer maintained by the author, and
hence obtaining the most recent source tarball (0.17) is NOT
sufficient. You may also examine other less popular telnetd
implementations, but be advised that almost all are heavily based on the
original code, and not always up-to-date with security fixes for that
codebase.
PS. Express your outrage: http://eprovisia.coredump.cx.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
