Bug 625699 - (CVE-2010-2959) CVE-2010-2959 kernel: can: add limit for nframes and clean up signed/unsigned variables
CVE-2010-2959 kernel: can: add limit for nframes and clean up signed/unsigned...
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
high Severity high
: ---
: ---
Assigned To: Red Hat Product Security
reported=20100820,public=20100811,sou...
: Security
Depends On: 625701 625702
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-20 03:50 EDT by Eugene Teo (Security Response)
Modified: 2012-07-11 15:33 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-03-28 04:57:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Eugene Teo (Security Response) 2010-08-20 03:50:28 EDT
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
Comment 1 Eugene Teo (Security Response) 2010-08-20 03:51:26 EDT
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
Comment 4 Eugene Teo (Security Response) 2010-08-23 03:47:53 EDT
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.
Comment 5 Chuck Ebbert 2010-08-24 10:18:18 EDT
The fix for this is queued for the next upstream 2.6.32, 2.6.34 and 2.6.35 stable updates.
Comment 8 Christoph A. 2010-08-27 14:49:02 EDT
Public exploit:
http://jon.oberheide.org/files/i-can-haz-modharden.c
Comment 9 Chuck Ebbert 2010-08-30 04:29:00 EDT
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.
Comment 10 Athmane Madjoudj 2010-08-30 18:33:44 EDT
(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 ]---
Comment 11 Jon Oberheide 2010-08-31 04:50:37 EDT
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...

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