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 - in.telnetd denial-of-service
Summary: in.telnetd denial-of-service
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: telnet
Version: 6.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Florian La Roche
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-08-17 03:08 UTC by kvajk
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 1999-08-19 19:28:47 UTC


Attachments (Terms of Use)

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.

Thanks!

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()


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