> I tried this on my Slackware 3.3 system at home, so it's safe to assume
> that it affects prior versions of Slackware.
I found similar problems in 3.1. In 2.3, in.telnetd wasn't linked against
libcurses, so maybe it wasn't a problem there.
Re-installing the newest netkit on a broken system doesn't fix the bug,
nor does installing the same netkit (even the same binary) on a working
system introduce the bug. So it's not netkit's fault. (Thus RedHat may
well be running the same telnetd as Slackware without problems.)
Installing the terminfo.tgz package fixes the bug. After some
investigation, I found that it's more specifically the existence of the
/usr/lib/terminfo/u/unknown file that fixes the bug.
A brief explanation in case this isn't clear... When telnetd finds that
your requested terminal isn't in the terminfo database, it tries using
TERM=unknown. I guess it just assumes that 'unknown' will work, thus
crashing when it's not there.
> Likewise, I don't see how anyone could exploit this one.
The BSD/OS exploit offered in the other message looks like a buffer
overrun in tgetent (unrelated to the missing-unknown-type bug that causes
the core dumps). It shouldn't affect any version of telnetd that is
linked against libcurses or libncurses. Any telnetd linked against
libtermcap is still vulnerable.
My suggested fix for future versions of Slackware: put
/usr/lib/terminfo/u/unknown into the default terminfo database
(hdsetup.tgz and ncurses.tgz) instead of the extended database
(terminfo.tgz).
--Patrick