Description of problem: Discovered by Ben Hawkes, this patch adds a limit for nframes as the number of frames in TX_SETUP and RX_SETUP are derived from a single byte multiplex value by default. Use-cases that would require to send/filter more than 256 CAN frames should be implemented in userspace for complexity reasons anyway. Additionally the assignments of unsigned values from userspace to signed values in kernelspace and vice versa are fixed by using unsigned values in kernelspace consistently. Upstream commit: http://git.kernel.org/linus/5b75c4973ce779520b9d1e392483207d6f842cde
CAN BCM was introduced in commit ffd980f9 v2.6.25-rc1. This can be mitigated by blacklist the affected modules: /etc/modprobe.d/blacklist.conf blacklist can blacklist can_bcm
Statement: Not vulnerable. This issue did not affect the versions of the Linux kernel as shipped with Red Hat Enterprise Linux 3, 4, 5, and Red Hat Enterprise MRG as they did not include support for the broadcast manager (BCM) protocol.
The fix for this is queued for the next upstream 2.6.32, 2.6.34 and 2.6.35 stable updates.
As Chuck anticipated fixed versions have been released: http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.35.4 http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.34.6 http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.32.21 http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.27.53 ..and packages for fc12, fc13 and fc14 seam to be on the way: http://koji.fedoraproject.org/koji/buildinfo?buildID=192344 http://koji.fedoraproject.org/koji/buildinfo?buildID=192358 http://koji.fedoraproject.org/koji/buildinfo?buildID=192354 Thanks Chuck!
Public exploit: http://jon.oberheide.org/files/i-can-haz-modharden.c
From the exploit: * Distros: please use grsecurity's MODHARDEN or SELinux's module_request * to restrict unprivileged loading of uncommon packet families. Allowing * the loading of poorly-written PF modules just adds a non-trivial and * unnecessary attack surface to the kernel.
(In reply to comment #8) > Public exploit: > http://jon.oberheide.org/files/i-can-haz-modharden.c The exploit doesn't work in Fedora 13 and CentOS-5.5 even with SELinux in permissive mode; but works just fine in Ubuntu Server 10.04, kernel version 2.6.32-21-generic. I guess that should work in Debian. Here is the result on Fedora 13 i686: $ ./e [+] looking for symbols... [-] symbol table not availabe, aborting! [-] symbol table not availabe, aborting! [+] setting up exploit payload... [+] creating PF_CAN socket... [+] connecting PF_CAN socket... [+] clearing out any active OPs via RX_DELETE... [+] removing any active user-owned shmids... [+] massaging kmalloc-96 SLUB cache with dummy allocations [+] corrupting BCM OP with truncated allocation via RX_SETUP... [+] mmap'ing truncated memory to short-circuit/EFAULT the memcpy_fromiovec... [+] mmap'ed mapping of length 328 at 0xb7805000 [+] smashing adjacent shmid with dummy payload via malformed RX_SETUP... [+] seeking out the smashed shmid_kernel... [+] discovered our smashed shmid_kernel at shmid[112] = 4161660 [+] re-smashing the shmid_kernel with exploit payload... Killed $ dmesg [...] BUG: unable to handle kernel NULL pointer dereference at 00000004 IP: [<c0569965>] ipc_has_perm+0x4d/0x78 *pde = 00000000 Oops: 0000 [#1] SMP last sysfs file: /sys/module/can/initstate Modules linked in: can_bcm can fuse ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 uinput i2c_piix4 i2c_core virtio_net virtio_balloon joydev microcode virtio_blk virtio_pci [last unloaded: scsi_wait_scan] Pid: 1916, comm: e Not tainted 2.6.33.3-85.fc13.i686 #1 /Bochs EIP: 0060:[<c0569965>] EFLAGS: 00010246 CPU: 0 EIP is at ipc_has_perm+0x4d/0x78 EAX: 00000000 EBX: de951ea4 ECX: 00000000 EDX: 00000080 ESI: 00000000 EDI: de951f04 EBP: de951f14 ESP: de951e9c DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Process e (pid: 1916, ti=de950000 task=deb32640 task.ti=de950000) Stack: de951ea4 0000061e 00000004 00000000 00000000 00000000 00000000 00000000 <0> 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 <0> 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Call Trace: [<c0569aca>] ? selinux_ipc_permission+0x30/0x36 [<c0563e87>] ? security_ipc_permission+0x12/0x14 [<c05594fd>] ? ipcperms+0x8f/0xa4 [<c055cb5c>] ? do_shmat+0xcc/0x31a [<c04060b5>] ? sys_ipc+0xfd/0x160 [<c040a639>] ? syscall_trace_enter+0xfc/0x111 [<c040a821>] ? syscall_trace_leave+0xa5/0xb8 [<c0770b3c>] ? syscall_call+0x7/0xb Code: 80 e8 02 00 00 8b 40 58 8b 40 04 89 45 8c 8d 45 90 8b 73 28 89 45 88 8b 7d 88 31 c0 f3 ab c6 45 90 04 8b 43 0c 8d 5d 90 89 45 98 <8b> 46 04 0f b7 0e 53 52 89 c2 8b 45 8c e8 17 ef ff ff 8b 55 f0 EIP: [<c0569965>] ipc_has_perm+0x4d/0x78 SS:ESP 0068:de951e9c CR2: 0000000000000004 ---[ end trace 36b1fa3c597f7525 ]---
The currently public exploit is targeted for Ubuntu, which is why you're seeing the failure on Fedora 13. In particular, SELinux is doing some checks in ipc_has_perm which dereferences the ->security member of the false kern_ipc_perm that we're smashing with. Since the current exploit doesn't point the ->security pointer at an appropriately constructed false structure, we get the NULL deref. /me fires up a Fedora 13 VM...