Bugzilla – Bug 186980
VUL-0: CVE-2006-2451: kernel: privilege escalation via prctl()
Last modified: 2017-01-02 18:40:53 UTC
Date: Wed, 21 Jun 2006 11:16:40 +0200 From: Marcel Holtmann <holtmann@redhat.com> To: vendor-sec@lst.de Subject: [vendor-sec] Privilege escalation through prctl() and suid_dumpable (embargoed) Parts/Attachments: 1 Shown 58 lines Text 2 OK 20 lines Text (charset: UTF-8) 3 46 bytes Application ---------------------------------------- Hi, this issue is EMBARGOED and the proposed unembargo date is Thursday, 6th of July 2006 at 14:00 UTC. It has been assigned CVE-2006-2451. We found an issue with the prctl() system call that can lead to a denial of service or a privilege escalation. The finder is a Red Hat employee. With the Linux 2.6.13 kernel the prctl(PR_SET_DUMPABLE, ...) system call got extended with a third value. Previous kernel versions only allowed either 0 (process is not dumpable) or 1 (process is dumpable). The new value 2 causes any binary to be dumped and this dump will be readable by root only. In most cases this value is 1 and its gets cleared if SUID or SGID binaries are executed. The basic idea of value 2 (suid_dumpable) is to get dumps from SUID or SGID programs. The problem is that an unprivileged user process can set suid_dumpable and this results in that any core file is owned by root now instead of the owner of the process. Depending on the values of kernel.core_pattern and kernel.core_uses_pid any unprivileged user is capable of running a denial of service attack that will consume all the disk space of the root partition for example. Under specific circumstances the root owned core files can also be used for a privilege escalation. In this example a crond that executes binary files will be used to provide us with a SUID copy of the bash. It is enough to dump a core file in /etc/cron.d that contains a valid crontab entry. If this entry gets processed it calls a shell script (as root) that provides us with a SUID copy of the bash. The following procedure shows the details: # id uid=500(test) gid=500(test) groups=500(test) context=user_u:system_r:unconfined_t # gcc -o prctl_exploit prctl_exploit.c # cp prctl_exploit.sh /tmp # chmod 755 /tmp/prctl_exploit.sh # ./prctl_exploit Segmentation fault (core dumped) now wait until /tmp/sh shows up # /tmp/sh -p # id uid=500(test) gid=500(test) euid=0(root) egid=0(root) groups=500(test) context=user_u:system_r:unconfined_t The exploit files prctl_exploit.c and prctl_exploit.sh are attached. Please don't make them public. Not even after the embargo expired. I don't have enough insights to propose the correct fix, but it seems to me that we shouldn't allow setting suid_dumpable for unprivileged user processes. Regards Marcel
Created attachment 90789 [details] attached shellscript ...
Created attachment 90790 [details] the other attachment ...
With some modifications (script seems to be DOS format) the exploit works.
10.0 and 10.1 / SLE10 are affected I think (>= 2.6.13)
Subject: Re: [vendor-sec] Privilege escalation through prctl() and suid_dumpable (embargoed) From: Marcel Holtmann <holtmann@redhat.com> To: vendor-sec@lst.de Cc: Ernie Petrides <petrides@redhat.com> Errors-To: vendor-sec-admin@lst.de Date: Mon, 26 Jun 2006 12:40:15 +0200 Hi, > this issue is EMBARGOED and the proposed unembargo date is Thursday, 6th > of July 2006 at 14:00 UTC. It has been assigned CVE-2006-2451. > > We found an issue with the prctl() system call that can lead to a denial > of service or a privilege escalation. The finder is a Red Hat employee. > > With the Linux 2.6.13 kernel the prctl(PR_SET_DUMPABLE, ...) system call > got extended with a third value. Previous kernel versions only allowed > either 0 (process is not dumpable) or 1 (process is dumpable). The new > value 2 causes any binary to be dumped and this dump will be readable by > root only. In most cases this value is 1 and its gets cleared if SUID or > SGID binaries are executed. The basic idea of value 2 (suid_dumpable) is > to get dumps from SUID or SGID programs. > > The problem is that an unprivileged user process can set suid_dumpable > and this results in that any core file is owned by root now instead of > the owner of the process. this is our proposed patch from Ernie Petrides: --- linux-2.6.9/kernel/sys.c.orig +++ linux-2.6.9/kernel/sys.c @@ -1702,7 +1702,7 @@ asmlinkage long sys_prctl(int option, un error = 1; break; case PR_SET_DUMPABLE: - if (arg2 < 0 || arg2 > 2) { + if (arg2 < 0 || arg2 > 1) { error = -EINVAL; break; } After an internal discussion it seems that nobody came up with a valid reason why any process (root, SUID or unprivileged) needs to set the value 2 (suid_dumpable). Ernie split this into three cases: 1) running as root: Then core dumps will already be done as root and setting it to value 2 makes no difference and thus not useful at all. 2) running as non-root w/setuid-to-root This seems only useful for debugging purpose, but in this case it can be set through /proc/sys/fs/suid_dumpable. So not really useful either. 3) running as non-root w/setuid-to-non-root In this case, you definitely do not want "dumpable" to get set to 2 because you have the privilege escalation vulnerability. So our proposal is to not allow the value 2 through prctl() at all and if someone needs to debug SUID programs then /proc/sys/fs/suid_dumpable should be the only way to allow root owned core dumps. If we disallow setting value 2 through prctl() then we also need to make sure the manual page gets changed, because currently it talks about this feature. The other question is what should prctl(PR_GET_DUMPABLE) return if /proc/sys/fs/suid_dumpable is set? Regards Marcel
Created attachment 91566 [details] dumpable-priviledgescalation.patch patch from mail above
embargoed until Thursday.. but critical. can you review and apply the patch to the 10.0 branch at least, Greg? So we can ready a SUSE Linux 10.0 only kernel update.
Yes, I can apply it there. Do you want any of the other security updates in that branch too?
if you have others open and easy to apply, this would be nice. Please add at least the linuxppc32/ppc64 patch, since it also critical (and 10.0 has ppc/ppc64 kernels). (https://bugzilla.novell.com/show_bug.cgi?id=186583) This kernel update will only have the 10.0 kernel. (For the 10.1 / SLE10 I would wait until we add it to the SLE10 kernel.)
Fixed in 10.0, 10.1 (incase someone wants to use that tree), and HEAD. Are you sure there are no other trees this is needed to be fixed in?
9.3 has: case PR_SET_DUMPABLE: if (arg2 != 0 && arg2 != 1) { error = -EINVAL; break; } 9.2 same. However .... SLES 9 SP3 and SP4 branches have "./patches.suse/setuid-core-dumps" a backport of this stuff. So SLES 9 is affected too! (Sorry that I did not see that earlier.) SLES8 is not affected.
Checked into all affected trees, it's all yours now :)
*** Bug 192071 has been marked as a duplicate of this bug. ***
its actiuvely being exploited by automated scripts.
all updates released now. (sle 10 today)
*** Bug 235900 has been marked as a duplicate of this bug. ***
CVE-2006-2451: CVSS v2 Base Score: 4.6 (AV:L/AC:L/Au:N/C:P/I:P/A:P)