Bug 919315 (CVE-2013-1828)

Summary: CVE-2013-1828 kernel: sctp: SCTP_GET_ASSOC_STATS stack buffer overflow
Product: [Other] Security Response Reporter: Petr Matousek <pmatouse>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED NOTABUG QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: agordeev, anton, bhu, davej, dborkmann, dhoward, esammons, fhrbata, gansalmon, iboverma, itamar, jforbes, jkacur, jonathan, jwboyer, kernel-maint, kernel-mgr, lgoncalv, lwang, madhu.chinakonda, marc, mcressma, npajkovs, plougher, rt-maint, rvrbovsk, sforsber, tgraf, williams
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: impact=important,public=20130308,reported=20130308,source=internet,cvss2=6.9/AV:L/AC:M/Au:N/C:C/I:C/A:C,rhel-5/kernel=notaffected,rhel-6/kernel=notaffected,mrg-2/realtime-kernel=notaffected,fedora-all/kernel=affected,cwe=CWE-121[auto]
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-08-24 10:11:49 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On: 919316    
Bug Blocks: 919317    

Description Petr Matousek 2013-03-07 22:38:00 EST
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
Comment 1 Petr Matousek 2013-03-07 22:39:23 EST
Created kernel tracking bugs for this issue

Affects: fedora-all [bug 919316]
Comment 2 Petr Matousek 2013-03-07 22:46:04 EST
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.
Comment 3 Thomas Graf 2013-03-08 06:33:41 EST
We are including 196d6759 in RHEL6.5 but will ensure to also include the follow-up fix 726bc6b0
Comment 5 Fedora Update System 2013-03-10 21:23:45 EDT
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.
Comment 6 Fedora Update System 2013-03-21 20:20:09 EDT
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.
Comment 7 Marc Schiffbauer 2013-03-24 10:44:42 EDT
I am having that problem on linux 3.8.3 and I verified that both commits are included there.
Comment 8 Petr Matousek 2013-03-25 07:21:53 EDT
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
Comment 9 Marc Schiffbauer 2013-03-25 09:05:53 EDT
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?
Comment 10 Petr Matousek 2013-03-25 09:16:40 EDT
(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
Comment 11 Marc Schiffbauer 2013-03-25 12:12:46 EDT
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
Comment 12 Marc Schiffbauer 2013-03-25 12:18:12 EDT
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?
Comment 13 Petr Matousek 2013-03-26 06:43:39 EDT
(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,
Comment 14 Petr Matousek 2013-03-26 07:02:02 EDT
(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
Comment 15 Marc Schiffbauer 2013-03-26 15:54:51 EDT
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
Comment 16 Petr Matousek 2013-03-27 08:51:10 EDT
(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