A local user could use the missing size check in sctp_getsockopt_assoc_stats() function to escalate their privileges. On x86 this might be mitigated by destination object size check as the destination size is known at compile time. Upstream fix: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=726bc6b0 Introduced by: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=196d6759 Introduced in: v3.8-rc1 References: https://twitter.com/grsecurity/status/309805924749541376 http://grsecurity.net/~spender/sctp.c
Created kernel tracking bugs for this issue Affects: fedora-all [bug 919316]
Statement: Not vulnerable. This issue did not affect the versions of the Linux kernel as shipped with Red Hat Enterprise Linux 5 and 6, and Red Hat Enterprise MRG as those versions are missing upstream commit 196d6759 that introduced this issue.
We are including 196d6759 in RHEL6.5 but will ensure to also include the follow-up fix 726bc6b0
kernel-3.8.2-206.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
kernel-3.8.3-103.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
I am having that problem on linux 3.8.3 and I verified that both commits are included there.
Hi Marc, (In reply to comment #7) > I am having that problem on linux 3.8.3 and I verified that both commits are > included there. can you please be more specific -- how does the problem you have look like? Did you try to run the referenced reproducer on Linux 3.8.3 (mainline Linux kernel, or Fedora kernel?) and something unexpected happened? Thank you, -- Petr Matousek / Red Hat Security Response Team
Hi Petr, sorry fo being too unspecific. I am not running any RedHat or Fedora kernel, but the problem does not seem to be distro specific. I am running a gentoo hardened kernel (Linux 3.8.3 with grsecurity/pax extensions) In the meantime I am not sure if am really hitting that specific sctp issue or another sctp issue: I have enabled dlm and sctp in the kernel. I am using cman 3.1.5. In cluster.conf I enabled dlm to use SCTP protocol. Now when starting clvmd after cman I am getting a kernel panic initiated on purpse by grsecurity because sctp is causing a buffer overflow. TO investigate further I disabled that security function in grsec after which PAX detected the buffer overflow. As soon as I have access to that machine again I can provide you with kernel trace message if you like. Would that be of any help?
(In reply to comment #9) > I have enabled dlm and sctp in the kernel. I am using cman 3.1.5. In > cluster.conf I enabled dlm to use SCTP protocol. Now when starting clvmd > after cman I am getting a kernel panic initiated on purpse by grsecurity > because sctp is causing a buffer overflow. > TO investigate further I disabled that security function in grsec after > which PAX detected the buffer overflow. > > As soon as I have access to that machine again I can provide you with kernel > trace message if you like. Would that be of any help? Feel free to attach the backtrace here, but please note that I (as a member of Red Hat Security Response Team) can give only very limited, if any, help on Gentoo Hardened with grsecurity/PAX patchset. You might want to enter the bug report in Gentoo bugzilla and/or talk directly to Brad Spengler and PaX Team (grsecurity.net). Thanks, -- Petr Matousek / Red Hat Security Response Team
Hi Petr, I do not think that the problem has something to do with grsec itself. Its only grsec/pax that reacts on the bug/flaw. This is what I see with CONFIG_GRKERNSEC_KERN_LOCKOUT=n [ 32.383568] sctp: Hash tables configured (established 65536 bind 65536) [ 32.384862] sctp: sctp_init_sock(sk: ffff880bffc5b680) [ 32.390366] DLM installed [ 44.667542] dlm: Using SCTP for communications [ 44.667551] sctp: sctp_init_sock(sk: ffff880bffc1b9c0) [ 44.667573] sctp: sctp_setsockopt(sk: ffff880bffc1b9c0... optname: 11) [ 44.667577] PAX: From xx.xx.xx.xx: kernel memory overwrite attempt detected to ffff880bffc1bdec (SCTP) (10 bytes) [ 44.667580] Pid: 7312, comm: clvmd Not tainted 3.8.3-hardened #6 [ 44.667582] Call Trace: [ 44.667591] [<ffffffff810e6666>] ? __check_object_size+0xe2/0xfa [ 44.667597] [<ffffffff813c8af6>] ? printk+0x4f/0x54 [ 44.667608] [<ffffffffa04f7768>] ? sctp_setsockopt_events+0x3d/0x143 [sctp] [ 44.667616] [<ffffffffa04f8e4d>] ? sctp_setsockopt+0x2c5/0x91c [sctp] [ 44.667621] [<ffffffff8131f141>] ? kernel_setsockopt+0x29/0x38 [ 44.667628] [<ffffffffa051def5>] ? sctp_listen_for_all+0x124/0x295 [dlm] [ 44.667633] [<ffffffff81067285>] ? __alloc_workqueue_key+0x311/0x43a [ 44.667640] [<ffffffffa051ea4c>] ? dlm_lowcomms_start+0x2d4/0x343 [dlm] [ 44.667646] [<ffffffffa051a923>] ? dlm_new_lockspace+0x98/0xa55 [dlm] [ 44.667650] [<ffffffff81048c98>] ? __do_page_fault+0x344/0x38d [ 44.667655] [<ffffffffa052272a>] ? device_write+0x4a7/0x705 [dlm] [ 44.667660] [<ffffffff810e1845>] ? vfs_write+0xf6/0x1a7 [ 44.667665] [<ffffffff810e1b69>] ? sys_write+0x4b/0x73 [ 44.667669] [<ffffffff813cf398>] ? retint_swapgs+0x7/0x8 [ 44.667671] [<ffffffff813cfb0d>] ? system_call_fastpath+0x1c/0x21 -Marc
Additional note: The referenced expoid code by brad does not seem to work anymore with the patches: It just causes following dmesg output: [ 421.803273] sctp: sctp_init_sock(sk: ffff880bffc1b500) [ 421.803288] sctp: sctp_getsockopt(sk: ffff880bffc1b500... optname: 112) [ 421.803321] sctp: sctp_close(sk: 0xffff880bffc1b500, timeout:0) [ 421.803322] sctp: sctp_destroy_sock(sk: ffff880bffc1b500) So did I hit another sctp bug?
(In reply to comment #12) > Additional note: > > The referenced expoid code by brad does not seem to work anymore with the > patches: > It just causes following dmesg output: > > [ 421.803273] sctp: sctp_init_sock(sk: ffff880bffc1b500) > [ 421.803288] sctp: sctp_getsockopt(sk: ffff880bffc1b500... optname: 112) > [ 421.803321] sctp: sctp_close(sk: 0xffff880bffc1b500, timeout:0) > [ 421.803322] sctp: sctp_destroy_sock(sk: ffff880bffc1b500) > > So did I hit another sctp bug? It looks like false positive to me. Can you try the patch below if it fixes your problem? [cynique@console ../cynique/git/linux]$ git diff net/sctp/socket.c diff --git a/net/sctp/socket.c b/net/sctp/socket.c index b907073..274c096 100644 --- a/net/sctp/socket.c +++ b/net/sctp/socket.c @@ -7045,6 +7045,7 @@ struct proto sctp_prot = { .unhash = sctp_unhash, .get_port = sctp_get_port, .obj_size = sizeof(struct sctp_sock), + .slab_flags = SLAB_USERCOPY, .sysctl_mem = sysctl_sctp_mem, .sysctl_rmem = sysctl_sctp_rmem, .sysctl_wmem = sysctl_sctp_wmem,
(In reply to comment #13) > It looks like false positive to me. Can you try the patch below if it fixes > your problem? I asked pipacs to verify the problem/patch and it was false positive indeed. Grsecurity is fixed now, just download the latest patchset. Thanks, -- Petr Matousek / Red Hat Security Response Team
Petr, the above one-line fix looks good! No more panic or PaX messages. AFAICS the SLAB_USERCOPY flag belongs to PaX, right? I am asking because I cannot find the above fix in the current PaX patchset (pax-linux-3.8.4-test12.patch), but the changelog mentionts it: "fixed USERCOPY reports triggered by SCTP, reported by mcp" Thanks Marc
(In reply to comment #15) > the above one-line fix looks good! No more panic or PaX messages. > AFAICS the SLAB_USERCOPY flag belongs to PaX, right? Correct. > I am asking because I cannot find the above fix in the current PaX patchset > (pax-linux-3.8.4-test12.patch), but the changelog mentionts it: > > "fixed USERCOPY reports triggered by SCTP, reported by mcp" Yes, that is the changelog entry that identifies this bugfix. Grsecurity fixed the issue in a different way, but the idea is the same. Petr