[My apologies if this has already been brought up by somebody else who
saw the same BugTraq messages. I get the digest version of portmaster-users,
so I have not yet seen the most recent messages on this list.]
1) Send several thousand characters to the Portmaster after initiating
a telnet connection, at the login: prompt. (TCP connection to port 23
by default.) On a Unix box, the following command works nicely:
(perl -e 'print "A" x 10000' ; sleep 10) | telnet pm3-hostname
2) That network connection will lock up.
3) Even if the network connection is killed on the remote (non-PM3) end,
the Portmaster will think the network connection is still established.
A "show netcon" command will show a state of "ESTABLISHED". The
connection will apparently remain in this state indefinitely, until
the portmaster is rebooted, or a "reset n###" command is given.
(When the "reset n###" command is given, the state shown by
"show netcon" will change to "TIME WAIT". After a few minutes,
the connection will be dropped.)
4) As far as I could tell, this does not affect anything other than
locking up one of the available telnet connections. No impact was seen
on other operations of the PortMaster.
This is a problem for the following reasons:
1) Once four(?) of these "locked up" connections are made, it is no
longer possible for an admin to log into the box over the network.
A direct physical connection must be made, or the unit must be
power-cycled. So it is not possible for an admin to just telnet
in and do a "reset n###" on the connection.
2) No special privileges are required to get to the unit to do this,
other than a clear network route to the unit. Obviously, an appropriate
firewall/filter setting should keep most or even all potential hackers
away from the unit, but it is far too common for such filters to not
exist. In such a case, ComOS should be more robust than it currently is.
As it stands now, a user with access to the telnet port can lock out the
admin from telnet sessions with four "hit-and-run" connections.
It seems to me that ComOS could/should have a number of fixes to improve
this:
1) Drop the telnet session when a certain number of characters have been
seen on the login: prompt.
2) Be better about detecting that the other end of a telnet session has
gone away, and reset the connection when this happens. Possibly use
a keepalive mechanism? I realize that by default it won't detect the
other side has gone away unless it tries to write something to the
connection, and that is not going to happen in this case. [This would
in general be useful for other situations where telnet sessions just
linger on the PM3.]
3) Other?
-- Michael Bryan michael@blueneptune.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe portmaster-users' in the body of the message. Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>