OpenVZ/Virtuozzo linux kernel team has discovered the following issue on the latest RHEL5 kernel: unprivileged user is able to crash the node by running 32-bit "mount -t smbfs ..." Issue was fixed in mainstream: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=822191a2fa1584a29c3224ab328507adcaeac1ab [test@dhcp0-43 tmp]$ uname -a Linux dhcp0-43.sw.ru 2.6.18-8.1.3.el5 #1 SMP Mon Apr 16 15:54:14 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux [test@dhcp0-43 tmp]$ id uid=502(test) gid=502(test) groups=502(test) [test@dhcp0-43 tmp]$ file /tmp/mount /tmp/mount: setuid ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), for GNU/Linux 2.2.5, stripped [test@dhcp0-43 tmp]$ /tmp/mount -t smbfs // /mnt mount: only root can do that >>>> Hmm, will try to strace it [test@dhcp0-43 tmp]$ strace /tmp/mount -t smbfs // /mnt execve("/tmp/mount", ["/tmp/mount", "-t", "smbfs", "//", "/mnt"], [/* 23 vars */]) = 0 [ Process PID=2689 runs in 32 bit mode. ] brk(0) = 0x805e000 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xfffffffff7ffd000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(0x3, 0xffc66d74) = 0 mmap2(NULL, 79905, PROT_READ, MAP_PRIVATE, 3, 0) = 0xfffffffff7fe9000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000\17j"..., 512) = 512 fstat64(0x3, 0xffc66dd8) = 0 mmap2(0x68b000, 1295780, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x68b000 mmap2(0x7c2000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x137) = 0x7c2000 mmap2(0x7c5000, 9636, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7c5000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xfffffffff7fe8000 set_thread_area(0xffc672c0) = 0 mprotect(0x7c2000, 8192, PROT_READ) = 0 mprotect(0x687000, 4096, PROT_READ) = 0 munmap(0xf7fe9000, 79905) = 0 brk(0) = 0x805e000 brk(0x807f000) = 0x807f000 umask(022) = 02 open("/dev/null", O_RDWR|O_LARGEFILE) = 3 close(3) = 0 getuid32() = 502 geteuid32() = 502 lstat64(0x8057caf, 0xffc674c0) = 0 stat64(0xffc67150, 0xffc670f0) = -1 ENOENT (No such file or directory) rt_sigprocmask(SIG_BLOCK, ~[TRAP SEGV RTMIN RT_1], NULL, 8) = 0 mount("//", "/mnt", "smbfs", MS_MGC_VAL, NULL <unfinished ...> +++ killed by SIGKILL +++ Process 2689 detached >>>>>>>>>>>>>> CRASH Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP: [<ffffffff800e9d7d>] compat_sys_mount+0x9c/0x241 PGD f0c4067 PUD f141067 PMD 0 Oops: 0000 [1] SMP last sysfs file: /devices/pci0000:00/0000:00:10.0/host0/target0:0:0/0:0:0:0/vendor CPU 0 Modules linked in: xt_length ipt_ttl xt_tcpmss ipt_TCPMSS iptable_mangle iptable_filter xt_multiport xt_limit ipt_tos ipt_REJECT ip_tables autofs4 hidp rfcomm l2cap bluetooth sunrpc 8021q bridge nfnetlink ip6t_REJECT xt_tcpudp ip6table_filter ip6_tables x_tables ipv6 video sbs i2c_ec i2c_core button battery asus_acpi acpi_memhot plug ac lp sg floppy e1000 pcspkr shpchp parport_pc serio_raw parport ide_cd cdrom dm_snapshot dm_zero dm_mirror dm_mod mptspi mptscsih mptbase scsi_transport_spi sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd Pid: 2689, comm: mount Not tainted 2.6.18-8.1.3.el5 #1 RIP: 0010:[<ffffffff800e9d7d>] [<ffffffff800e9d7d>] compat_sys_mount+0x9c/0x241 RSP: 0018:ffff81000f35df38 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff81000f0be000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff802849b1 RDI: ffff81000f0be005 RBP: ffff810017c4e000 R08: 0000000000001000 R09: ffff81000f0f0000 R10: 000000000805e468 R11: 0000000000000001 R12: 000000000805e458 R13: 0000000000000000 R14: 00000000c0ed0000 R15: 0000000000000000 FS: 00002aaaaaac1260(0000) GS:ffffffff8038a000(0063) knlGS:00000000f7fe86c0 CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b CR2: 0000000000000000 CR3: 000000000f118000 CR4: 00000000000006e0 Process mount (pid: 2689, threadinfo ffff81000f35c000, task ffff81000ffd2080) Stack: 0000000000000000 ffff81000f0f0000 0000000000000000 ffff81000f0be000 000000000805e458 000000000805e468 0000000000000000 0000000000000000 0000000000000000 ffffffff8005f194 0000000000000000 0000000000000000 Call Trace: [<ffffffff8005f194>] cstar_do_call+0x1b/0x65 Code: 83 3a 06 0f 85 3a 01 00 00 0f b7 42 0c 89 42 14 0f b7 42 0a RIP [<ffffffff800e9d7d>] compat_sys_mount+0x9c/0x241 RSP <ffff81000f35df38> CR2: 0000000000000000 Acknowledgements: Red Hat would like to thank the SWsoft Virtuozzo/OpenVZ Linux kernel team for reporting this issue.
about compat_sys_mount(): RHEL4 kernels are vulnerabled too
We don't ship RHEL5 with smbfs enabled. I'll move this to a RHEL4 BZ and we can address it there.
Jeff, I would note: it is not samba-related issue, It is bug in 32-bit compat for sys_mount and it is not requires smbfs enabled. Also I would note that I've reproduced this issue on your latest RHEL5 kernel. Just try to reproduce it, it works.
I see, my mistake. I'll move this back to RHEL5 and clone this bug for RHEL4 as well...
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Created attachment 154585 [details] reproducer program Had some problem getting this to reproduce on RHEL4, so here is a simpler reproducer program. Compile with: gcc -m32 -static ...and run as an unprivileged user and the box will panic.
Anoither note: As you can see, I was not able to crash the node by using usual mount (/bin/mount was copied from 32-bit RHEL4u3 node) [test@dhcp0-43 tmp]$ /tmp/mount -t smbfs // /mnt mount: only root can do that but node was crashed when the same command was running under strace. I do not understand how it's possible and suppose that it may point to some another issue.
This request was evaluated by Red Hat Kernel Team for inclusion in a Red Hat Enterprise Linux maintenance release, and has moved to bugzilla status POST.
Thanks for the report, I've posted the patch for internal review. It's not clear to me either why strace makes a difference here with an unprivileged user (though I've not looked too closely). Would you mind opening a new case for that against the util-linux package? It may turn out to be a ptrace problem (or it may be expected for some reason), though we should probably look at why it occurs...
I've reported to vendor-sec about this issue.
A patch for this issue is included in build 2.6.18-20.el5.
I'm moving this bug to Security Response parent as the flaw affected multiple versions of RHEL, and we've already fixed this issue for RHEL5 in RHSA-2007:0376 and RHEL4 in RHSA-2007:0488. (I will open separate tracking bug for 5.1 to replace this bug)
confirmed the -52.el5 kernel is not vulnerable by running the attached test case.
Issue was addressed in following erratas for affected Red Hat Enterprise Linux versions: http://rhn.redhat.com/errata/RHSA-2007-0376.html http://rhn.redhat.com/errata/RHSA-2007-0488.html Fedora kernel versions were updated to fixed upstream versions.