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.