01. Osicom Technologies ROUTERmate Security Advisory
----------------------------------------------------

Osicom Technologies (http://www.osicom.com) makes remote access router
products for 56K-T1 users.  While evaluating these products Rootshell came
across various flaws in the TCP/IP stack of these routers allowing remote
users to gain access to and crash the ROUTERmate products.

Products affected
-----------------

* ROUTERmate Plus T1
* ROUTERmate Plus 56K
* ROUTER mate-EX MULTI-PROTOCOL EXECUTIVE ROUTER 
* ROUTER mate Plus - D&I INTEGRATED ROUTER AND T-1 DROP & INSERT CSU 

List of problems
----------------

* The TCP/IP stack deals with SYN packets incorrectly and allows a remote
user to crash the unit in two ways.  In each of these cases the router will
reboot and then function normally unless hit with the attack again.

  1) If a user port scans the router with any readily available port scanner
  the unit will crash.

  2) If the router is hit with a flood of SYN packets the router crashes. 
  Code to generate SYN packets can be found on the Rootshell website as
  "synk4.c" and "SYNpacket.tgz".

* The TCP/IP stack can be crashed by exploiting the "off by one" IP header
bug that recently affected Linux and Windows users.  This attack is commonly
know as "nestea.c" and can be found on Rootshell.  The ROUTERmate will also
crash with the similar bugs "bonk.c" and "newtear.c".  After these attacks
the router will reboot then function normally unless hit with the attack
again.

* The TCP/IP stack can be caused to completely freeze up requiring a reboot
by the end user via the serial port console or by bouncing the units power
source.  "pmcrash.c" available on Rootshell crashes Livingston portmasters
prior to ComOS 3.3.1 (they fixed this problem well over a year ago).  This
same problem is now in the ROUTERmate product, however the unit will not
reboot on its own.  On a local network we were able to crash the ROUTERmate
after running pmcrash for just a few seconds.  pmcrash.c simply sends large
amounts of fragmented ICMP traffic at the router.

* The default SNMP configuration allows any remote user to change the
configuration of leased lines, place circuits in loopback, and reboot the
router.  The ROUTERmate product ships with a default write community of
"private".  By using commonly available SNMP software such as the CMU SNMP
packages a user can gain access to the following commands.  The entire MIB
file can be found on ftp.osicom.com.

unitResetCommand   <------ Anyone can reboot the product by default.
localNIloop
remoteNIloop
lineLoop
payloadLoop
testPattern
niClearTestCounter
insertBitError
interfaceLocalLoop
interfaceRemoteLoopWithTestPattern
interfaceTestPattern
interfaceDiagClearCounters
saveConfigToFlash
niFormat
niCoding
niTiming
niLineBuildOut
esfDataLink
remoteLoop
esfCxrLoops
bandwidthAlloc
interfaceDataRate
interfaceDataMode
interfaceRmtLoopResponse
clearCounters
clientAutoLearn
accessViaTelnet
clientAddress

This problem is not unique to Osicom.  Rootshell after 2 years of e-mails to
Ascend (http://www.ascend.com/) got them to turn off the write community in
their products and added the "R/W Comm Enable" setting in their SNMP
configuration area.

Since the ROUTERmate product does not support packet filters the only
workaround at the moment is to disable the "Autolearn Clients" feature of
the ROUTERmate.

Solution
--------

Osicom was informed of these problems on July 31st, 1998.

New firmware when available should be posted to :

ftp://ftp.osicom.com/

Vendor Contact
--------------

Osicom Technologies Inc., 2800
28th Street, Suite 100
Santa Monica, CA 90405 USA

info@osicom.com 
888-674-2668 (888-Osicom-8)