Bugzilla – Bug 199441
VUL-0: CVE-2006-3745 CVE-2006-4535: kernel: sctp privilege elevation
Last modified: 2019-05-01 14:48:00 UTC
And another one. From: Chris Wright <chrisw@sous-sol.org> To: David_Marcus@McAfee.com Cc: security@kernel.org, sri@us.ibm.com, Wei_Wang@McAfee.com, Zheng_Bu@McAfee.com, Anthony_Bettini@McAfee.com, vendor-sec@lst.de User-Agent: Mutt/1.4.2.1i Subject: [vendor-sec] Re: [Security] New Vulnerability Discovered -- Linux kernel sctp privilege elevation Errors-To: vendor-sec-admin@lst.de Date: Tue, 15 Aug 2006 02:32:49 -0700 * David_Marcus@McAfee.com (David_Marcus@McAfee.com) wrote: > Wei Wang of McAfee Avert Labs has found a vulnerability in Linux kernel. > Please let me know what we can do to assist confirmation, remedy and > subsequent combined disclosure of this issue. Documentation as follows: Thanks for the report. Presently this is an embargoed issue and we need to set a release date for coordinating with vendors. I propose August 22nd, 14:00 UTC. This is assigned CVE-2006-3745. Sridhar has proposed a patch (attached). We may also need to either fix this at a higher level (in the sanity checking done verify_iovec()) or do an audit. At least TIPC is looking suspect as well. > Synopsis: Linux kernel sctp privilege elevation > Product: Linux kernel > Version: 2.4.23--2.4.32 ; 2.6 up to and including 2.6.17.7 > Vendor: http://www.kernel.org/ > Severity: local(9) > Author: wang wei < wei_wang@mcafee.com > > > Issue: > ====== > > SCTP (Stream Control Transmission Protocol) is a message oriented, > reliable transport protocol, with congestion control, support for > transparent multi-homing, and multiple ordered streams of messages. > RFC2960 defines the core protocol. > > A locally exploitable flaw has been found in the Linux sctp module > sctp_make_abort_user function that allows local users to gain > root privileges and also execute arbitrary code at kernel privilege > level. > > > Details: > ======== > > SCTP module support sctp protocol , sctp_make_abort_user function > create ABORT with a SCTP_ERROR_USER_ABORT error. Due to lack of > strict check for user_data msg iovec array,it cause integer overflow, > whereafter ,kernel heap rewriting will happen. > > net/sctp/sm_make_chunk.c > > 807 /* Helper to create ABORT with a SCTP_ERROR_USER_ABORT error. */ > 808 struct sctp_chunk *sctp_make_abort_user(const struct > sctp_association *asoc, > 809 const struct sctp_chunk > *chunk, > 810 const struct msghdr *msg) > 811 { > 812 struct sctp_chunk *retval; > 813 void *payload = NULL, *payoff; > 814 size_t paylen = 0; > 815 struct iovec *iov = NULL; > 816 int iovlen = 0; > 817 > 818 if (msg) { > 819 iov = msg->msg_iov; > 820 iovlen = msg->msg_iovlen; > 821 paylen = get_user_iov_size(iov, iovlen); > 822 } > 823 > 824 retval = sctp_make_abort(asoc, chunk, > sizeof(sctp_errhdr_t) + paylen); > 825 if (!retval) > 826 goto err_chunk; > 827 > 828 if (paylen) { > 829 /* Put the msg_iov together into payload. */ > 830 payload = kmalloc(paylen, GFP_ATOMIC); > 831 if (!payload) > 832 goto err_payload; > 833 payoff = payload; > 834 > 835 for (; iovlen > 0; --iovlen) { > 836 if (copy_from_user(payoff, > iov->iov_base,iov->iov_len)) > 837 goto err_copy; > 838 payoff += iov->iov_len; > 839 iov++; > 840 } > 841 } > > line 820 get_user_iov_size calculate iov total count,we can see example > adding. Integer overflow will happen. > > 408 /* Calculate the size (in bytes) occupied by the data of an > iovec. */ > 409 static inline size_t get_user_iov_size(struct iovec *iov, int > iovlen) > 410 { > 411 size_t retval = 0; > 412 > 413 for (; iovlen > 0; --iovlen) { > 414 retval += iov->iov_len; > 415 iov++; > 416 } > 417 > 418 return retval; > 419 } > > line 830 will kmalloc small size room,whereafter,line 836 copy_from_user > will cause kernel heap overflow. > > > Discussion: > ============= > > SCTP module is default configure in most 2.6.x kernel. and any local > user can request sctp module via socket( AF_INET, SOCK_SEQPACKET, > IPPROTO_SCTP). This vulnerability is critical and exploitable, although > linux kernel have > some protections. > > There are kernel protections in some version. > > 1: int totallen += iov[i].iov_len; totallen must >0 > 2: BUG_ON((long) n < 0); in copy_from_user function > 3: kmalloc the same size don't return continuum addresss > 4: list_del have del check like xp sp2 and linux free heap check. > > FYI > http://www.isec.pl/vulnerabilities/isec-0023-coredump.txt > In that case, that vulnerability exploit condition is more difficult > than this sctp vulnerability. > > > Credits: > ======== > > thank a1rsupp1y@0x557 performed further research together and our > IDT team of mcafee. > > > POC: > ========= <complete mail attached>
Created attachment 96097 [details] k.txt
CVE-2006-3635
CRD August 22
reply to last fix: From: Sridhar Samudrala <sri@us.ibm.com> To: Chris Wright <chrisw@sous-sol.org> Cc: Andrew Morton <akpm@osdl.org>, security@kernel.org, Zheng_Bu@McAfee.com, Anthony_Bettini@McAfee.com, Wei_Wang@McAfee.com, David_Marcus@McAfee.com, vendor-sec@lst.de Subject: [vendor-sec] Re: [Security] New Vulnerability Discovered -- Linux +kernel sctp privilege elevation Errors-To: vendor-sec-admin@lst.de Date: Tue, 15 Aug 2006 17:47:39 -0700 On Tue, 2006-08-15 at 09:22 -0700, Chris Wright wrote: > * Andrew Morton (akpm@osdl.org) wrote: > > I must be missing something here. Wouldn't it be better & sufficient to fix > > the big fat bugs in verify_iovec()? > > There's no reason not to do both. And the latter is better in general, > IMO (esp. since I think TIPC is vulnerable too). Only reason is making > sure it doesn't break anything, but I think it's good to have both. The > current verify_iovec is not very restrictive, and the patch you supplied > was still not enough. Here's a quick hack at your patch to try and make > it robust enough. Hopefully I didn't miss anything obvious this time. > It's completely untested. Based on patch from Andrew, mistakes are mine. - If you are returning -ve values, shouldn't the return type be ssize_t rather than size_t? You changed the return type of verify_compat_iovec() to ssize_t, but verify_iovec() and iov_from_user_compat_kern() return types are changed to size_t. - the prototype for verify_compat_iovec() in include/net/compat.h needs to be updated. Also, I think the fixes to verify_iovec() need to be reviewed by DaveM and netdev. I am not sure what is the scope of the embargo, can we raise the issue with verify_iovec() bug on netdev? Thanks Sridhar
"embargo date has been set to 22nd of August 2006 at 14:00 UTC."
From: "Luiz Fernando N. Capitulino" <lcapitulino@mandriva.com.br> To: Sridhar Samudrala <sri@us.ibm.com> Cc: Chris Wright <chrisw@sous-sol.org>, Andrew Morton <akpm@osdl.org>, security@kernel.org, Zheng_Bu@McAfee.com, Anthony_Bettini@McAfee.com, Wei_Wang@McAfee.com, David_Marcus@McAfee.com, vendor-sec@lst.de Subject: Re: [vendor-sec] Re: [Security] New Vulnerability Discovered -- Linux kernel sctp privilege elevation Errors-To: vendor-sec-admin@lst.de Date: Thu, 17 Aug 2006 14:33:19 -0300 Hi guys, Em Tue, 15 Aug 2006 17:47:39 -0700 Sridhar Samudrala <sri@us.ibm.com> escreveu: | On Tue, 2006-08-15 at 09:22 -0700, Chris Wright wrote: | > * Andrew Morton (akpm@osdl.org) wrote: | > > I must be missing something here. Wouldn't it be better & sufficient to fix | > > the big fat bugs in verify_iovec()? | > | > There's no reason not to do both. And the latter is better in general, | > IMO (esp. since I think TIPC is vulnerable too). Only reason is making | > sure it doesn't break anything, but I think it's good to have both. The | > current verify_iovec is not very restrictive, and the patch you supplied | > was still not enough. Here's a quick hack at your patch to try and make | > it robust enough. Hopefully I didn't miss anything obvious this time. | > It's completely untested. Based on patch from Andrew, mistakes are mine. | | - If you are returning -ve values, shouldn't the return type be ssize_t | rather than size_t? You changed the return type of verify_compat_iovec() | to ssize_t, but verify_iovec() and iov_from_user_compat_kern() return | types are changed to size_t. | | - the prototype for verify_compat_iovec() in include/net/compat.h | needs to be updated. | | Also, I think the fixes to verify_iovec() need to be reviewed by DaveM and | netdev. | I am not sure what is the scope of the embargo, can we raise the issue with | verify_iovec() bug on netdev? Not sure if I missed something, but if we don't count the weekend we have only three days to fix this up and so far there're three proposed fixes around, right? Don't we need more time then? Also, the Mcafee's bug description says that privilege scalation is possible whereas the PoC only causes a local DoS. Is the privilege scalation really possible? -- Luiz Fernando N. Capitulino
Subject: Re: [vendor-sec] Re: [Security] New Vulnerability Discovered -- Linux kernel sctp privilege elevation From: Marcel Holtmann <holtmann@redhat.com> To: "Luiz Fernando N. Capitulino" <lcapitulino@mandriva.com.br> Cc: Sridhar Samudrala <sri@us.ibm.com>, Chris Wright <chrisw@sous-sol.org>, Andrew Morton <akpm@osdl.org>, security@kernel.org, Zheng_Bu@McAfee.com, Anthony_Bettini@McAfee.com, Wei_Wang@McAfee.com, David_Marcus@McAfee.com, vendor-sec@lst.de Errors-To: vendor-sec-admin@lst.de Date: Thu, 17 Aug 2006 18:37:32 +0200 Hi Luiz, > | > > I must be missing something here. Wouldn't it be better & sufficient to fix > | > > the big fat bugs in verify_iovec()? > | > > | > There's no reason not to do both. And the latter is better in general, > | > IMO (esp. since I think TIPC is vulnerable too). Only reason is making > | > sure it doesn't break anything, but I think it's good to have both. The > | > current verify_iovec is not very restrictive, and the patch you supplied > | > was still not enough. Here's a quick hack at your patch to try and make > | > it robust enough. Hopefully I didn't miss anything obvious this time. > | > It's completely untested. Based on patch from Andrew, mistakes are mine. > | > | - If you are returning -ve values, shouldn't the return type be ssize_t > | rather than size_t? You changed the return type of verify_compat_iovec() > | to ssize_t, but verify_iovec() and iov_from_user_compat_kern() return > | types are changed to size_t. > | > | - the prototype for verify_compat_iovec() in include/net/compat.h > | needs to be updated. > | > | Also, I think the fixes to verify_iovec() need to be reviewed by DaveM and > | netdev. > | I am not sure what is the scope of the embargo, can we raise the issue with > | verify_iovec() bug on netdev? > > Not sure if I missed something, but if we don't count the weekend we > have only three days to fix this up and so far there're three proposed > fixes around, right? > > Don't we need more time then? Chris posted this issue on Tuesday, 15th and it already included the patch from Sridhar to fix this issue inside the SCTP implementation. The additional concerns raced by Andrew were about verify_iovec() and my understanding is that we should fix both for upstream. However the verify_iovec() should go to netdev first once the embargo is over. I can't identify a third proposed fix. In case of RHEL4 we will go only with the patch from Sridhar. The embargo date was proposed within Chris' original posting and I asked to confirm it. And as of today nobody objected. See my other emails for reference. > Also, the Mcafee's bug description says that privilege scalation is > possible whereas the PoC only causes a local DoS. > > Is the privilege scalation really possible? We don't have a PoC to demonstrate the privilege escalation, but we think it is possible. Regards Marcel
From: "Luiz Fernando N. Capitulino" <lcapitulino@mandriva.com.br> To: Marcel Holtmann <holtmann@redhat.com> Cc: Sridhar Samudrala <sri@us.ibm.com>, Chris Wright <chrisw@sous-sol.org>, Andrew Morton <akpm@osdl.org>, security@kernel.org, Zheng_Bu@McAfee.com, Anthony_Bettini@McAfee.com, Wei_Wang@McAfee.com, David_Marcus@McAfee.com, vendor-sec@lst.de Subject: Re: [vendor-sec] Re: [Security] New Vulnerability Discovered -- Linux kernel sctp privilege elevation Errors-To: vendor-sec-admin@lst.de Date: Thu, 17 Aug 2006 15:11:09 -0300 Em Thu, 17 Aug 2006 18:37:32 +0200 Marcel Holtmann <holtmann@redhat.com> escreveu: | Hi Luiz, | | > | > > I must be missing something here. Wouldn't it be better & sufficient to fix | > | > > the big fat bugs in verify_iovec()? | > | > | > | > There's no reason not to do both. And the latter is better in general, | > | > IMO (esp. since I think TIPC is vulnerable too). Only reason is making | > | > sure it doesn't break anything, but I think it's good to have both. The | > | > current verify_iovec is not very restrictive, and the patch you supplied | > | > was still not enough. Here's a quick hack at your patch to try and make | > | > it robust enough. Hopefully I didn't miss anything obvious this time. | > | > It's completely untested. Based on patch from Andrew, mistakes are mine. | > | | > | - If you are returning -ve values, shouldn't the return type be ssize_t | > | rather than size_t? You changed the return type of verify_compat_iovec() | > | to ssize_t, but verify_iovec() and iov_from_user_compat_kern() return | > | types are changed to size_t. | > | | > | - the prototype for verify_compat_iovec() in include/net/compat.h | > | needs to be updated. | > | | > | Also, I think the fixes to verify_iovec() need to be reviewed by DaveM and | > | netdev. | > | I am not sure what is the scope of the embargo, can we raise the issue with | > | verify_iovec() bug on netdev? | > | > Not sure if I missed something, but if we don't count the weekend we | > have only three days to fix this up and so far there're three proposed | > fixes around, right? | > | > Don't we need more time then? | | Chris posted this issue on Tuesday, 15th and it already included the | patch from Sridhar to fix this issue inside the SCTP implementation. | | The additional concerns raced by Andrew were about verify_iovec() and my | understanding is that we should fix both for upstream. However the | verify_iovec() should go to netdev first once the embargo is over. | | I can't identify a third proposed fix. Ah, sorry, I thought Andrew's e-mail had a patch. | In case of RHEL4 we will go only with the patch from Sridhar. Ok. | The embargo date was proposed within Chris' original posting and I asked | to confirm it. And as of today nobody objected. See my other emails for | reference. I saw them before writing this. I thought that Sridhar's fix wasn't enough, but the whole thing is clear to me now. Thanks a lot Marcel! -- Luiz Fernando N. Capitulino
The first (Sridhar's) patch looks correct. TIPC is vulnerable too, but it's not enabled in our kernels (so I suppose we don't care about TIPC, right?). The patch seems to be unnecesary invasive, though - replacing the custom loop in sctp_make_abort_user by memcpy_fromiovec should be enough. Fixing verify_iovec and verify_compat_iovec is a good thing and it will fix the SCTP vulnerability too, because other two possible callers (do_readv_writev and compat_do_readv_writev in fs/read_write.c and fs/compat.c) already check iovec size correctly. However, fixing verify_iovec won't fix TIPC as it uses int instead of size_t when computing size of a message. That means neither of these patches fixes TIPC. I found no other places except SCTP and TIPC where this bug occurs. I suggest we use Sridhar's patch only (possibly simplified?).
it would be nice to fix TIPC too. Yes, then we should use Sridhars patch.
TIPC seems badly designed regarding datatypes. There are int's instead of ssize_t's used throughout the whole code. Fixing the vulnerability means fixing a lot of function prototypes (including exported ones, thus changing kABI) or limiting maximum iovec size for TIPC to 31 bits. Is it really worth the effort given the fact we don't support and don't ship this intra-cluster communication protocol?
No, it is not. Please leave out the TIPC fix for now.
Created attachment 96615 [details] kernel24.txt From: Willy Tarreau <w@1wt.eu> To: Sridhar Samudrala <sri@us.ibm.com> Cc: security@kernel.org, vendor-sec@lst.de User-Agent: Mutt/1.5.11 Subject: [vendor-sec] Re: [Security] New Vulnerability Discovered -- Linux kernel sctp privilege elevation Errors-To: vendor-sec-admin@lst.de Date: Sat, 19 Aug 2006 08:57:19 +0200 Hi, For those with 2.4 trees, I've rediffed Sridhar's fix for 2.4.33 (below). Just a few offsets and a trivial reject. SCTP still builds. Patch below. Sridhar, can I apply your sign-off on this patch ? Regards Willy -- [PATCH] [SCTP] Local privilege elevation - CVE-2006-3745 Avoid the use of buggy get_user_iov_size(). sctp_make_abort_user() now takes the msg_len along with the msg so that we don't have to recalculate the bytes in iovec. It also uses memcpy_fromiovec() so that we don't go beyond the length of the allocated buffer. diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h ...
Committed to all affected branches.
The patches checked into SLES9_SP3_BRANCH and SLES9_SP4_BRANCH don't even apply.
Bug public.
thanks! reassign to us for tracking.
Date: Mon, 28 Aug 2006 13:55:32 -0700 (PDT) From: David Miller <davem@davemloft.net> To: stable@kernel.org Subject: [stable] [PATCH]: Fix SCTP bug added by embargoe fix Thanks to the embargoe on that recent SCTP CVE, the patch got zero public review and ends up having a bug in it. This is why embargos suck and are bad for Linux development. I bet several distro's shipped that broken SCTP patch too to "fix" the CVE. Anyways, please add to -stable, thanks. commit e12289f0bc673dabb22be32d2df54b0ebfc7cf2b Author: Sridhar Samudrala <sri@us.ibm.com> Date: Mon Aug 28 13:53:01 2006 -0700 [SCTP]: Fix sctp_primitive_ABORT() call in sctp_close(). With the recent fix, the callers of sctp_primitive_ABORT() need to create an ABORT chunk and pass it as an argument rather than msghdr that was passed earlier. Signed-off-by: Sridhar Samudrala <sri@us.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net> diff --git a/net/sctp/socket.c b/net/sctp/socket.c index fde3f55..dab1594 100644 --- a/net/sctp/socket.c +++ b/net/sctp/socket.c @@ -1289,9 +1289,13 @@ SCTP_STATIC void sctp_close(struct sock } } - if (sock_flag(sk, SOCK_LINGER) && !sk->sk_lingertime) - sctp_primitive_ABORT(asoc, NULL); - else + if (sock_flag(sk, SOCK_LINGER) && !sk->sk_lingertime) { + struct sctp_chunk *chunk; + + chunk = sctp_make_abort_user(asoc, NULL, 0); + if (chunk) + sctp_primitive_ABORT(asoc, chunk); + } else sctp_primitive_SHUTDOWN(asoc, NULL); } _______________________________________________ stable mailing list stable@linux.kernel.org http://linux.kernel.org/mailman/listinfo/stable
From: dann frazier <dannf@dannf.org> To: Willy TARREAU <w@1wt.eu>, David Miller <davem@davemloft.net> Cc: vendor-sec@lst.de User-Agent: mutt-ng/devel-r782 (Debian) Subject: [vendor-sec] linux-2.4: Fix sctp_primitive_ABORT() call in sctp_close() Errors-To: vendor-sec-admin@lst.de Date: Mon, 28 Aug 2006 23:35:28 -0600 Here is a 2.4 backport of David's fix for a problem with the recent embargoed patch for CVE-2006-3745. Compile-tested. Signed-off-by: dann frazier <dannf@debian.org> diff --git a/net/sctp/socket.c b/net/sctp/socket.c index 6620b87..8d13849 100644 --- a/net/sctp/socket.c +++ b/net/sctp/socket.c @@ -967,9 +967,13 @@ SCTP_STATIC void sctp_close(struct sock sctp_unhash_established(asoc); sctp_association_free(asoc); - } else if (sk->linger && !sk->lingertime) - sctp_primitive_ABORT(asoc, NULL); - else + } else if (sk->linger && !sk->lingertime) { + struct sctp_chunk *chunk; + + chunk = sctp_make_abort_user(asoc, NULL, 0); + if (chunk) + sctp_primitive_ABORT(asoc, NULL); + } else sctp_primitive_SHUTDOWN(asoc, NULL); } else sctp_primitive_SHUTDOWN(asoc, NULL); --
----- Forwarded message from "Steven M. Christey" <coley@linus.mitre.org> ----- From: "Steven M. Christey" <coley@linus.mitre.org> To: Marcel Holtmann <holtmann@redhat.com> Cc: Sridhar Samudrala <sri@us.ibm.com>, Martin Schulze <joey@infodrom.org>, Greg KH <greg@kroah.com>, vendor-sec@lst.de, coley@mitre.org Subject: [vendor-sec] Re: [davem@davemloft.net: [stable] [PATCH]: Fix SCTP bug added by embargoe fix] Errors-To: vendor-sec-admin@lst.de Date: Thu, 31 Aug 2006 17:59:19 -0400 (EDT) On Thu, 31 Aug 2006, Marcel Holtmann wrote: > > Unfortunately, the regression causes a panic if an SCTP socket has > > SO_LINGER set with a linger value of 0 > > and it is closed. > > thanks. So it seems we should assign a CVE name. OK, use CVE-2006-4505. I assume that the attacker has some role, i.e. can either create such a socket or indirectly prompt its creation. - Steve _______________________________________________ Vendor Security mailing list Vendor Security@lst.de https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec ----- End forwarded message -----
From: Sridhar Samudrala <sri@us.ibm.com> User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) To: Marcel Holtmann <holtmann@redhat.com> Cc: "Steven M. Christey" <coley@linus.mitre.org>, Martin Schulze <joey@infodrom.org>, Greg KH <greg@kroah.com>, vendor-sec@lst.de, coley@mitre.org Subject: [vendor-sec] Re: [davem@davemloft.net: [stable] [PATCH]: Fix SCTP bug added by embargoe fix] Errors-To: vendor-sec-admin@lst.de Date: Fri, 01 Sep 2006 08:57:02 -0700 Marcel Holtmann wrote: >Hi Steven, > >>>>Unfortunately, the regression causes a panic if an SCTP socket has >>>>SO_LINGER set with a linger value of 0 >>>>and it is closed. >>>thanks. So it seems we should assign a CVE name. >> >>OK, use CVE-2006-4505. I assume that the attacker has some role, >>i.e. can >>either create such a socket or indirectly prompt its creation. > >the SO_LINGER is a standard socket option (man 7 socket) that is >supported by most socket based protocols. It basically means that >close() or shutdown() will not return until all queued messages for >the socket have been successfully sent or the linger timeout has been >reached. So it makes close() or shutdown() blocking. The SO_LINGER can >be set by the owner of the socket. So in this case any local user. There is another case which is not documented in the man page. With a linger time of 0(l_linger = 0), close() sends an ABORT(or RST for TCP) and returns immediately. This panic happens only when l_linger is set to 0 and it can be set by any local user owning an SCTP socket. Thanks Sridhar
*sigh* CVE ID already in use.
CVE-2006-4535
released all updates but sles10-s390x, published asdvisory
Patch published in kernelupdates - (sles9sp3) 2.6.5-7.282, dated Aug 30, 2006 & released Sep 21, 2006. - (sles10) 2.6.16.21-0.25, dated Sep 19, 2006 & released Oct 04, 2006.
CVE-2006-4535: CVSS v2 Base Score: 4.9 (AV:L/AC:L/Au:N/C:N/I:N/A:C)