Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
2.6.24.1 (as of this date, 2008-02-08 15:25 patch-2.6.24.1.bz2 ) may not fully close this hole. The post before this is from Feb. 08. This is dated Feb. 10.
Code:
From: Bastian Blank <bastian@waldi.eu.org>
Date: Sun, 10 Feb 2008 14:47:57 +0000 (+0200)
Subject: splice: fix user pointer access in get_iovec_page_array()
X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=712a30e63c8066ed84385b12edbfb804f49cbc44
splice: fix user pointer access in get_iovec_page_array()
Commit 8811930dc74a503415b35c4a79d14fb0b408a361 ("splice: missing user pointer access verification") added the proper access_ok() calls to copy_from_user_mmap_sem() which ensures we can copy the struct iovecs from userspace to the kernel.
But we also must check whether we can access the actual memory region pointed to by the struct iovec to fix the access checks properly.
Signed-off-by: Bastian Blank <waldi@debian.org>
Acked-by: Oliver Pinter <oliver.pntr@gmail.com>
Cc: Jens Axboe <jens.axboe@oracle.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
diff --git a/fs/splice.c b/fs/splice.c
index 14e2262..9b559ee 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -1234,7 +1234,7 @@ static int get_iovec_page_array(const struct iovec __user *iov,
if (unlikely(!len))
break;
error = -EFAULT;
- if (unlikely(!base))
+ if (!access_ok(VERIFY_READ, base, len))
break;
/*
That's the info I found, if someone knows more/better, please post. See the discussion:
jayjwa, I've moved your post to a new thread. I think that with the amount of talk this vulnerability has generated on the blogosphere it merits an area for LQ members to discuss it if they wish. It's a pretty serious vulnerability, and AFAICT a huge number of distros had (or have) vulnerable kernels.
What is the short term measure one can employ before the patch is officially out?
The patches have been out for a couple days - 2.6.24.1 fixed CVE-2008-0009 and CVE-2008-0010, while 2.6.24.2 fixed CVE-2008-0600. I can also confirm that at least Debian, Ubuntu, and Slackware (the distros which I am familiar with) have released updated kernel packages with the fixes backported.
Last edited by win32sux; 02-15-2008 at 09:41 PM.
Reason: Specified kernel versions.
EDIT: Well, I think it's a pretty safe bet that you are, so I'm merging this.
The article from gentoo said it has been assigned to CVE-2008-0009 and CVE-2008-0010. I don't know what that means. The only thing I understood from that article is that kernels up to 2.6.23 were vulnerable.
The Gentoo site does provide a nice summary of the whole deal.
I'll quote it here for the benefit of anyone who might have been confused:
Quote:
Two major security flaws in the Linux kernel were reported last weekend. Both flaws have the same impact (root access for local users) and both exist within the vmsplice() system call, which was added to the kernel in 2.6.17. There is no configuration option to exclude vmsplice() so everyone is vulnerable.
One of the security issues existed for the entire lifetime of vmsplice(), so any kernel version from 2.6.17 onwards is vulnerable. This was fixed in 2.6.24.2, 2.6.23.16 and 2.6.22.18. It has been assigned the vulnerability identifier of CVE-2008-0600.
The other security issue first appeared in 2.6.23. It was fixed in 2.6.23.15 and 2.6.24.1. This vulnerability has been assigned CVE-2008-0009 and CVE-2008-0010.
I've edited the thread title to make it a little clearer that this thread can be used to discuss any of those three CVEs.
Just to update on this, there is now malware appearing on various security forums using these issues.
Quote:
This program use the vmsplice bug for install some
basic backdoors.
Credits:
vmsplice exploit coded originaly by qaaz
Actions:
- disable INPUT rules on firewall
- open the 1407 port for execute remote commands
- open a bash session on 14071 port using the inetd daemon
- mail the shadow file for a mail account
Just to update on this, there is now malware appearing on various security forums using these issues.
Hope everyone is patched by now.
I'm confused...are you saying that there are documented attacks based on this exploit? Or are you saying that some security sites now have exploit code? If its the latter, from what I understand, there was exploit code out there approximately 2 weeks ago (proof-of-concept code)...people on some channels of freenode were using the exploit code to validate whether their patching was successful.
I'm confused...are you saying that there are documented attacks based on this exploit? Or are you saying that some security sites now have exploit code? If its the latter, from what I understand, there was exploit code out there approximately 2 weeks ago...people on some channels of freenode were using the exploit code to validate whether their patching was successful.
Yes, indeed. The initial impression I got from his post was that there was now some sort of attack based on this vulnerability carrying-out the actions he listed. But these actions could simply be part of one of the demo exploits which started floating-around a couple weeks ago (before the patches were released). Some clarification by jayjwa would be nice.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
CVE-2008-0009/0010/0600 (Linux Privilege Escalation Vulnerabilities)
