COMMAND

    ROUTERmate

SYSTEMS AFFECTED

    Systems using Osicom ROUTERmate products:
    * 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

PROBLEM

    Following  is  based  on  Osicom  Technologies ROUTERmate Security
    Advisory.  Osicom Technologies 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.

    Here are the 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
      on this  site (see  is Linux  section IP  fragment overlap  #2).
      The ROUTERmate will  also crash with  the similar bugs  "bonk.c"
      and "newtear.c" (see  in NT section  IP fragment overlap  #2 and
      #3).  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 the ROUTERmate
      crashed 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

SOLUTION

    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.  New firmware  when available
    should be posted to:

	ftp://ftp.osicom.com/