Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 4560

Summary: in.telnetd denial-of-service
Product: [Retired] Red Hat Linux Reporter: kvajk
Component: telnetAssignee: Florian La Roche <laroche>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6.0Keywords: Security
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 1999-08-19 19:28:47 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description kvajk 1999-08-17 03:08:07 UTC
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.


Comment 1 Bill Nottingham 1999-08-19 19:28:59 UTC
fixed in errata release; any TERM type with a / in it is
accepted without passing it off to tgetent()