According to Shaun Colley on Bugtraq, and apparently confirmed by a Trustix Linux Security Advisory (see below), there is a integer overflow in the net/sctp code in the Linux kernel that handles the sctp_setsockopt() function call. According to the post, this vulnerability in kernel versions 2.4.23-pre5 through (and including) 2.4.25 could allow a local attacker to gain root privileges. This vulnerabiliy is exploitable, but the bugtraq poster did provide a patch, if for some reason one could not upgrade to 2.4.26 (the 2.4.26 and above, and 2.6.x lines both removed the sctp code from the kernel, apparnetly, leaving them invulnerable to this problem). Reproducible: Always Steps to Reproduce: Initial Alert: http://www.securityfocus.com/archive/1/362953 TLSA: http://www.securityfocus.com/archive/1/363337 I can find no CAN's for this.
Please see http://bugs.gentoo.org/show_bug.cgi?id=47881 for related bugs in related kernel versions. Note that these are NOT the same vulnerabilities, but both are apparently fixed in 2.4.26.
This is NOT confirmed... From FD : -------------------------------------------------- Because this all is debate about nothing, as the original advisory was fake, because you simply can't pass negative optlen to setsockopt() syscall, so there is nothing to be exploited. asmlinkage long sys_setsockopt(int fd, int level, int optname, char __user *optval, { int err; struct socket *sock; if (optlen < 0) return -EINVAL; ---------------------------------------------------- Looks like Trustix got caught. Please confirm the debunking, but IMHO this one is fake.
I agree. This doesn't look worrysome. It was questionable from the start, but I figured better safe than sorry (and when I saw the TLSA I started to take it more seriously). Apparently the advisory is not itself ``fake'', but the bug is unlikely to be exploitable (according to the original poster: "I didn't realise that -1 or any negative will not get past sys_setsockopt().").
