=====================================================================
                                   CERT-Renater

                        Note d'Information No. 2009/VULN383
_____________________________________________________________________

DATE                      : 17/09/2009

HARDWARE PLATFORM(S)      : /

OPERATING SYSTEM(S)       : Solaris 10, OpenSolaris running Solaris IPv6.

======================================================================
http://sunsolve.sun.com/search/printfriendly.do?assetkey=1-66-265608-1
______________________________________________________________________

Solution Type: Sun Alert

Solution  265608 :   Security Vulnerability with the Solaris IPv6
Networking Stack Involving the Cassini Gigabit-Ethernet Device Driver
and Jumbo Frames

Bug ID: 6857395

Product:
Solaris 10 Operating System
OpenSolaris

Date of Resolved Release: 02-Sep-2009

Security Vulnerability with the Solaris IPv6 Networking Stack  :

1. Impact

A security vulnerability with the Solaris IPv6 networking stack involving the
Cassini Gigabit-Ethernet Device Driver (ce(7D)) and jumbo frames may allow
a remote user to panic the system. This is a type of Denial of Service
(DoS) condition.

Note: A similar issue exists for systems using IPv4 networking. See
Sun Alert 257008 for details:

         http://sunsolve.sun.com/search/document.do?assetkey=1-66-257008-1

2. Contributing Factors

This issue can occur in the following releases:

SPARC platform
  * Solaris 10 without patch 141414-10
  * OpenSolaris based upon builds snv_01 through snv_82, and snv_111
    through snv_122

x86 platform
  * Solaris 10 without patch 141415-10
  * OpenSolaris based upon builds snv_01 through snv_82, and snv_111
    through snv_122

Notes:  Solaris 9 and Solaris 8 are not impacted by this issue.

A system is only vulnerable to this issue if it is using a GigaSwift
Ethernet Adapter (CE) interface (ce(7D)) which has been configured to
accept jumbo frames and is configured for IPv6 and hardware checksumming is
enabled.

To determine if there are any active CE interfaces present on a
system, run the following command:

     $ /sbin/ifconfig -a inet6 | /bin/grep ^ce
     ce1: flags=2004841<UP,RUNNING,MULTICAST,DHCP,IPv6> mtu 9194 index 3

To determine if jumbo frames are in use on a CE interface, use the
following ndd commands:

      # ndd -set /dev/ce instance 1
      # ndd -get /dev/ce accept_jumbo 1

The above two commands must be repeated for each CE interface present
on the system (adjusting the instance number in the first command
accordingly).

The file /kernel/drv/ce.conf may also include the accept_jumbo=1
directive, either globally or for a subset of interfaces, but the
above ndd commands will give the current state of the running interfaces.

To determine whether hardware checksumming is enabled, run the
following command as root:

     # echo "dohwcksum/X" | /usr/bin/mdb -k
     dohwcksum:
     dohwcksum:      1

A value of 1 indicates that hardware checksumming is enabled (default
value).

A value of 0 indicates hardware checksumming is disabled.

Note 3: Some third party storage systems have been seen to generate
jumbo ethernet packets which may trigger this issue and cause the
Solaris system to panic.

Note 4: The use of the kernel memory debugging facility 'kmem_flags'
will greatly increase the likelihood of a panic. To determine if
kmem_flags is set, run the following command as root:

     # echo "kmem_flags/X" | /usr/bin/mdb -k
     kmem_flags:
     kmem_flags:     0

A value of zero indicates kmem_flags is not set. Any other value
indicates one or more of the kmem debugging facilities is active.

3. Symptoms

If the described issue occurs, the system will panic with a BAD TRAP
type 31, and a stack trace similar to the following:

     panic[cpu0]/thread=2a1008a1ca0: BAD TRAP: type=31 rp=2a1008a1270
     addr=310cf2e6000 mmu_fsr=0
     bcksum+20 ()
     ip_rput_data_v6+1238 ()
     ip_rput_v6+870 ()
     putnext+208 ()

4. Relief/Workaround

There are two possible workarounds known at this time.

Workaround A:

Disable hardware checksumming. To do this, place the following line
in /etc/system and reboot:

  set ip:dohwcksum = 0

Note: This may impact performance.

Workaround B:

Prevent the network from sending jumbo frames to this host by
disabling jumbo frames on the entire subnet.

Note: This may impact performance.

5. Resolution

This issue is addressed in the following releases:

SPARC Platform
  * Solaris 10 with patch 141414-10 or later
  * OpenSolaris based upon build snv_123 or later

x86 platform
  * Solaris 10 with patch 141415-10 or later
  * OpenSolaris based upon build snv_123 or later

For more information on Security Sun Alerts, see Technical Instruction
ID 213557

http://sunsolve.sun.com/search/document.do?assetkey=1-61-213557-1

This Sun Alert notification is being provided to you on an "AS IS"
basis. This Sun Alert notification may contain information provided by
third parties. The issues described in this Sun Alert notification may
or may not impact your system(s). Sun makes no representations,
warranties, or guarantees as to the information contained herein. ANY
AND ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR
NON-INFRINGEMENT, ARE HEREBY DISCLAIMED. BY ACCESSING THIS DOCUMENT
YOU ACKNOWLEDGE THAT SUN SHALL IN NO EVENT BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, PUNITIVE, OR CONSEQUENTIAL DAMAGES THAT ARISE
OUT OF YOUR USE OR FAILURE TO USE THE INFORMATION CONTAINED HEREIN.
This Sun Alert notification contains Sun proprietary and confidential
information. It is being provided to you pursuant to the provisions of
your agreement to purchase services from Sun, or, if you do not have
such an agreement, the Sun.com Terms of Use. This Sun Alert
notification may only be used for the purposes contemplated by these
agreements.

Copyright 2000-2009 Sun Microsystems, Inc., 4150 Network Circle, Santa
Clara, CA 95054 U.S.A. All rights reserved


======================================================================

          =========================================================
          Les serveurs de référence du CERT-Renater
          http://www.urec.fr/securite
          http://www.cru.fr/securite
          http://www.renater.fr
          =========================================================
          + CERT-RENATER          | tel : 01-53-94-20-44          +
          + 151 bd de l'Hopital   | fax : 01-53-94-20-41          +
          + 75013 Paris           | email: certsvp@renater.fr     +
          =========================================================


