Bug 4560 - in.telnetd denial-of-service
in.telnetd denial-of-service
Status: CLOSED ERRATA
Product: Red Hat Linux
Classification: Retired
Component: telnet (Show other bugs)
6.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Florian La Roche
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-08-16 23:08 EDT by kvajk
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-08-19 15:28:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description kvajk 1999-08-16 23:08:07 EDT
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!
Comment 1 Bill Nottingham 1999-08-19 15:28:59 EDT
fixed in errata release; any TERM type with a / in it is
accepted without passing it off to tgetent()

Note You need to log in before you can comment on or make changes to this bug.