Tymm Twillman pointed out a denial-of-service attack
against in.telnetd, and I have written up a patch which
I think is probably the best fix available at present.
(You may want to check the security audit mailing list
to see if any more discussion about the problem comes
up with a better solution than mine.)

The basic problem is that the remote telnet asks
in.telnetd whether or not the value of $TERM it intends
to pass over is OK.  Depending on the value of the
terminal type, in.telnetd (running as root) can be
tricked into opening arbitrary files.  On some systems,
this could probably result in a crash (by reading from
/dev/port or something), or it could result in leaving
in.telnetd processes running, hung trying to open a FIFO
with nobody writing to it, which could be used to fill
up the system's process table.

My solution is for in.telnetd to just tell the remote
telnet client that the suggested value of $TERM is
fine, without checking it.  I think this is fine; the
terminal type probaly is fine, and if it isn't the
remote telnet client is probably too stupid to figure
out a better equivalent term type to try.  And the
users' login scripts can handle this problem, anyhow.

I don't know if this bug is serious enough to warrant
an errata, but I'd at least like to see it fixed in the
next release.

Thanks!