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!
fixed in errata release; any TERM type with a / in it is accepted without passing it off to tgetent()