COMMAND
Livingston portmaster
SYSTEMS AFFECTED
PM3: Livingston Enterprises PM-3 ComOS 3.5.1b11 (May 1997 code)
PM2: Livingston Enterprises PortMaster Version 3.3.2 (1997 code)
PM2: Livingston Enterprises PortMaster Version 3.3.2c1
OR-U: Livingston Enterprises PortMaster Version 3.4.2L (Mid 1996
code)
PROBLEM
Dave Andersen posted following. Even this issue has been around
for some time, and there is exploit code that was actually
written years ago. The issue seems to have been overlooked
because it occured near the same time as a similar issue
involving sending BREAK signals to a portmaster via telnet. This
issue remains open in versions of the Livingston ComOS before 3.7.
There is a vulnerability in the Livingston Portmaster 2,
Portmaster 3, and Office Router series of routers/terminal
servers which allows an oustide attacker with access to the telnet
port of the router to cause the router to reboot, or experience
memory corruption which may require a hard reboot of the router
to solve. This vulnerability does not apply to direct console
access either via the console port or via dialing in to the
router, and also does not apply to other TCP ports on the router.
SOLUTION
Livingston has corrected this issue in all newer releases of the
OS. There are three methods which can be used to prevent this
problem. They may be used in cojunction with each other.
1 - Upgrade the router to ComOS 3.7
2 - Apply a packet filter to the router
In order to prevent this denial-of-service attack on a
portmaster completely, it is necessary to use two sets of
filters. The first set protects against access to your
portmasters from outside of your network - the ethernet
filter. Depending on your configuration, you may need to
change this filter. Here are several examples. Note that
the filters discussed herein should be used to supplement,
not replace, any existing filters you may have. Placing
anti-spoofing filters on your dialin users is more than a
good idea, as is preventing them from accessing your
sensitive internal hosts if they share a network. The
portmaster's IP address is 192.168.10.33 in all examples.
The second set of filters protects the portmaster from users
who are dialed in. In general, it is easiest to manage this
via RADIUS. In the user configuration, put an entry saying:
Framed-Filter-Id = "modemscreen"
Because of the use of RADIUS, the assumption with the
modemscreen filter is that no modem users are allowed to
communicate with the portmaster. If a user should be allowed
to communicate with the portmaster, it is easy enough to give
them a different filter via RADIUS. The modemscreen filter:
add filter modemscreen.in
set filter modemscreen.in 1 deny 0.0.0.0/0 192.168.10.33/32
set filter modemscreen.in 2 permit 0.0.0.0/0 0.0.0.0/0
Example 1:
* There is only 1 administrative host, 192.168.10.2
* Users communicate only via PPP/SLIP (no rlogin/telnet from
the PM)
add filter etherscreen
set filter etherscreen 1 permit 192.168.10.2/32 192.168.10.33/32
set filter etherscreen 2 deny 0.0.0.0/0 192.168.10.33/32
set filter etherscreen 3 permit 0.0.0.0/0 0.0.0.0/0
set ether0 ifilter etherscreen
Example 2:
* Administrative hosts are on 192.168.1.0/24
* Other portmasters sharing routing information are in
192.168.10.0/24
* The portmaster only handles PPP/SLIP connections.
add filter etherscreen
set filter etherscreen 1 permit 192.168.10.0/24 192.168.10.33/32
set filter etherscreen 2 permit 192.168.1.0/24 192.168.10.33/32
set filter etherscreen 3 deny 0.0.0.0/0 192.168.10.33/32
set filter etherscreen 4 permit 0.0.0.0/0 0.0.0.0/0
Example 3:
* Administrative hosts are on 192.168.1.0/24
* Other portmasters sharing routing information are in
192.168.10.0/24
* The host 192.168.1.10 is a shell host and should not talk
directly to the portmaster, but should not be allowed to
telnet to the portmaster. The telnet port is the default 23.
* Users logged in need to telnet or rlogin to anywhere.
add filter etherscreen
set filter etherscreen 1 deny 196.168.1.10/32 192.168.10.33/32 tcp dst eq 23
set filter etherscreen 2 permit 192.168.1.0/24 192.168.10.33/32
set filter etherscreen 3 permit 192.168.10.0/24 192.168.10.33/32
set filter etherscreen 4 deny 0.0.0.0/0 192.168.10.33/32 tcp dst eq 23
set filter etherscreen 5 permit 0.0.0.0/0 192.168.10.33/32 tcp established
set filter etherscreen 6 deny 0.0.0.0/0 192.168.10.33/32
set filter etherscreen 7 permit 0.0.0.0/0 0.0.0.0/0
An explanation of what we're doing:
1 - Don't let the shell host talk to the portmaster's telnet
port. (But it can do anything else - perhaps it's
involved in routing),
2 - Let all of the administrative hosts communicate with the
portmaster,
3 - Let all of the other portmasters communicate with the
portmaster,
4 - Don't let anything send anything to our telnet port,
5 - Permit already established connections to come in to us,
6 - Don't let anything else come in to us,
7 - Let everything else (not destined for us) pass through.
3 - Disable telnet access to the portmaster entirely using the
command "set telnet 0". This presumes you have an out-of-band
way to manage the portmaster or that you use the portmaster
protocol (pmconsole, etc).