Multiple Vendor profil(2) Vulnerability
BID:570
Info
Multiple Vendor profil(2) Vulnerability
| Bugtraq ID: | 570 |
| Class: | Failure to Handle Exceptional Conditions |
| CVE: | |
| Remote: | No |
| Local: | Yes |
| Published: | Aug 09 1999 12:00AM |
| Updated: | Aug 09 1999 12:00AM |
| Credit: | This problem was discovered and fixed by Ross Harvey <[email protected]>. The advisory describing this vulnerability (which the content of this vulnerability entry is based on) was forwarded to Bugtraq by Ross Harvey <[email protected]> Sun, 8 Aug 1999. |
| Vulnerable: |
Sun Solaris 2.5.1 Sun Solaris 7.0_x86 Sun Solaris 7.0 Sun Solaris 2.6_x86 Sun Solaris 2.6 Sun Solaris 2.5_x86 Sun Solaris 2.5 Sun Solaris 2.4_x86 Sun Solaris 2.4 Sun Solaris 2.3 Sun Solaris 2.2 Sun Solaris 2.1 OpenBSD OpenBSD 2.5 OpenBSD OpenBSD 2.4 OpenBSD OpenBSD 2.3 OpenBSD OpenBSD 2.2 OpenBSD OpenBSD 2.1 OpenBSD OpenBSD 2.0 NetBSD NetBSD 1.4 x86 NetBSD NetBSD 1.3.3 NetBSD NetBSD 1.3.2 NetBSD NetBSD 1.3.1 NetBSD NetBSD 1.3 NetBSD NetBSD 1.2.1 NetBSD NetBSD 1.2 NetBSD NetBSD 1.1 NetBSD NetBSD 1.0 |
| Not Vulnerable: |
NetBSD NetBSD 1.4.1 x86 |
Discussion
Multiple Vendor profil(2) Vulnerability
Some *BSD's use a profil(2) system call that dates back to "version 6" unix. This system call arranges for the kernel to sample the PC and increment an element of an array on every profile clock tick.
The security issue stems from the fact that profiling is not turned off when a process execve(2)'s another program image.
As the size and location of this array as well as the scale factor are under the program's control, it is possible to arrange for an arbitrary 16-bit program virtual address to be incremented on each profile clock tick.
Although unlikely, it is theoretically possible that an attacker with local access and knowledge of the addresses used by privileged programs could construct an exploit.
It may be that there are no candidate addresses that, when incremented, result in a security failure. However, as this can turn -1 into 0, and 0 into 1, and as security-related system calls and library functions often return either -1 or 0, this mechanism could turn system call returns of success into failure or failure into success if a program stores system call results into memory locations.
Some *BSD's use a profil(2) system call that dates back to "version 6" unix. This system call arranges for the kernel to sample the PC and increment an element of an array on every profile clock tick.
The security issue stems from the fact that profiling is not turned off when a process execve(2)'s another program image.
As the size and location of this array as well as the scale factor are under the program's control, it is possible to arrange for an arbitrary 16-bit program virtual address to be incremented on each profile clock tick.
Although unlikely, it is theoretically possible that an attacker with local access and knowledge of the addresses used by privileged programs could construct an exploit.
It may be that there are no candidate addresses that, when incremented, result in a security failure. However, as this can turn -1 into 0, and 0 into 1, and as security-related system calls and library functions often return either -1 or 0, this mechanism could turn system call returns of success into failure or failure into success if a program stores system call results into memory locations.
Exploit / POC
Multiple Vendor profil(2) Vulnerability
Currently the SecurityFocus staff are not aware of any exploits for this issue. If you feel we are in error or are aware of more recent information, please mail us at: [email protected]. The following program will test for the vulnerability although not exploit it:
/* This program will check to see if a given system has the profil(2) bug
described in NetBSD Security Advisory 1999-011. If it prints `Counting!'
then you've got it...
At least one system (Solaris) appears to fix the security issue but
doesn't turn off profiling unless the new image is owned by a different
user. To check for this, you need to do something like:
% cc profiltest.c
% su
# cp a.out prog.setuid
# chown (something) prog.setuid
# (possibly make it setuid)
# exit
% ./a.out
If the program doesn't find prog.setuid, it just exec's itself; this
gets the same result on most systems. (So: % cc profiltest.c; ./a.out)
So far, I've only found it in BSD systems. Linux hasn't had profiling
in the kernel for a while, so current versions should not be vulnerable. */
#include <sys/types.h>
#include <stdio.h>
#include <unistd.h>
volatile unsigned short twobins[2];
int
main(int ac, char **av)
{
if (ac == 1) {
/* can't check the return value; on some systems it's void */
profil((char *)twobins, sizeof twobins, (u_long)&main, 2);
/* try a different image for uid/setuid tests */
execl("prog.setuid", "tryroot", "-", 0);
/* otherwise, just chain to ourself */
execl(av[0], av[0], "-", 0);
fprintf(stderr, "problems\n");
exit(1);
}
for(;;) {
if (twobins[0] | twobins[1]) {
printf("Counting!\n");
twobins[0] = twobins[1] = 0;
}
}
}
/* [email protected] */
Currently the SecurityFocus staff are not aware of any exploits for this issue. If you feel we are in error or are aware of more recent information, please mail us at: [email protected]. The following program will test for the vulnerability although not exploit it:
/* This program will check to see if a given system has the profil(2) bug
described in NetBSD Security Advisory 1999-011. If it prints `Counting!'
then you've got it...
At least one system (Solaris) appears to fix the security issue but
doesn't turn off profiling unless the new image is owned by a different
user. To check for this, you need to do something like:
% cc profiltest.c
% su
# cp a.out prog.setuid
# chown (something) prog.setuid
# (possibly make it setuid)
# exit
% ./a.out
If the program doesn't find prog.setuid, it just exec's itself; this
gets the same result on most systems. (So: % cc profiltest.c; ./a.out)
So far, I've only found it in BSD systems. Linux hasn't had profiling
in the kernel for a while, so current versions should not be vulnerable. */
#include <sys/types.h>
#include <stdio.h>
#include <unistd.h>
volatile unsigned short twobins[2];
int
main(int ac, char **av)
{
if (ac == 1) {
/* can't check the return value; on some systems it's void */
profil((char *)twobins, sizeof twobins, (u_long)&main, 2);
/* try a different image for uid/setuid tests */
execl("prog.setuid", "tryroot", "-", 0);
/* otherwise, just chain to ourself */
execl(av[0], av[0], "-", 0);
fprintf(stderr, "problems\n");
exit(1);
}
for(;;) {
if (twobins[0] | twobins[1]) {
printf("Counting!\n");
twobins[0] = twobins[1] = 0;
}
}
}
/* [email protected] */
Solution / Fix
Multiple Vendor profil(2) Vulnerability
Solution:
OpenBSD
--------------
OpenBSD has the following patch available for this problem:
http://www.openbsd.org/errata.html#profil
NetBSD
-----------
Upgrade to NetBSD 1.4.1, NetBSD-current, or apply the following patch:
Index: kern_exec.c
===================================================================
RCS file: /cvsroot/syssrc/sys/kern/kern_exec.c,v
retrieving revision 1.101
diff -u -w -u -r1.101 kern_exec.c
- --- kern_exec.c 1999/04/27 05:28:44 1.101
+++ kern_exec.c 1999/08/06 07:19:24
@@ -415,6 +415,7 @@
goto exec_abort;
}
+ stopprofclock(p); /* stop profiling */
fdcloseexec(p); /* handle close on exec */
execsigs(p); /* reset catched signals */
p->p_ctxlink = NULL; /* reset ucontext link */
Patches are available to all Sun customers at http://sunsolve.sun.com/
Sun Solaris 7.0
Sun Solaris 7.0_x86
Sun Solaris 2.6
Sun Solaris 2.6_x86
Sun Solaris 2.5.1
Solution:
OpenBSD
--------------
OpenBSD has the following patch available for this problem:
http://www.openbsd.org/errata.html#profil
NetBSD
-----------
Upgrade to NetBSD 1.4.1, NetBSD-current, or apply the following patch:
Index: kern_exec.c
===================================================================
RCS file: /cvsroot/syssrc/sys/kern/kern_exec.c,v
retrieving revision 1.101
diff -u -w -u -r1.101 kern_exec.c
- --- kern_exec.c 1999/04/27 05:28:44 1.101
+++ kern_exec.c 1999/08/06 07:19:24
@@ -415,6 +415,7 @@
goto exec_abort;
}
+ stopprofclock(p); /* stop profiling */
fdcloseexec(p); /* handle close on exec */
execsigs(p); /* reset catched signals */
p->p_ctxlink = NULL; /* reset ucontext link */
Patches are available to all Sun customers at http://sunsolve.sun.com/
Sun Solaris 7.0
-
Sun 106541-10
sparc
http://sunsolve.sun.com/search/document.do?assetkey=1-21-106541-10-1
Sun Solaris 7.0_x86
Sun Solaris 2.6
-
Sun 105181-19
sparc
http://sunsolve.sun.com/search/document.do?assetkey=1-21-105181-19-1 -
Sun 106629-18
sparc
Sun Solaris 2.6_x86
-
Sun 105182-19
x86
http://sunsolve.sun.com/search/document.do?assetkey=1-21-105182-19-1
Sun Solaris 2.5.1
-
Sun 103640-32
sparc
http://sunsolve.sun.com/search/document.do?assetkey=1-21-103640-32-1