Livingston has corrected this issue in all newer releases of the OS.
----------------------------------------------
ArosNet Security Bulletin
September 8, 1997
denial-of-service vulnerability in Livingston
PM2, PM3, OR series routers/terminal servers.
----------------------------------------------
DESCRIPTION
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.
Exploit code for this vulnerability should be presumed to be in
active use. The vulnerability appears to have been known by some attackers
for a time, but was overlooked in major announcements.
AFFECTS
Systems tested for the bug include:
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)
CORRECTING THE PROBLEM
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 (see VENDOR SOLUTION).
2 - Apply a packet filter to the router (see PACKET FILTER SOLUTION)
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).
PACKET FILTER SOLUTION
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. We provide 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.
As with any change in filtering on a router, it is best to test
your implementation of these rules on a spare or test router before
putting them online in a production environment.
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.
VENDOR SOLUTION:
This bug has been corrected in ComOS 3.7. Affected users should
upgrade immediately. [Note: ComOS 3.7 may require additional memory
in some routers. Please read the release notes for ComOS 3.7 carefully].
Note that once you have applied the vendor solution, it is advisable
to also implement the packet filter solution, to prevent any future
attacks which rely upon communication with the telnet port (even something
as simple as password guessing). We encourage all users of this equipment
to implement both a packet filtering system (or firewall) to prevent this
type of access and to apply the upgrade from Livingston.
VENDOR CONTACT:
Livingston Enterprises
support@livingston.com
Voice: 1-800-458-9966
FAX: +1 (510) 426-8951