Bugzilla – Bug 296871
VUL-0: CVE-2007-3848: kernel: potential local privilege escalation
Last modified: 2021-08-11 09:10:14 UTC
We received the following report via vendor-sec. This issue is not public yet, please keep any information about it inside SUSE. CRD Aug 10 Date: Thu, 02 Aug 2007 16:16:24 +0200 From: Marcel Holtmann <holtmann@redhat.com> To: vendor-sec@lst.de Subject: [vendor-sec] Potential local privilege escalation (embargoed) Hi, I am sending this now the second time, since the first time, I tried, it never made it to the list (this time without the attached advisory). We got anadvisory from Vulnerability Research Labs, COSEINC PTE Ltd. and it talks about a potential local privilege escalation in the Linux kernel. These issues are under EMBARGO and the planned date of publication is currently set by them to 10th of August, 2007. The whole depends on two flaws in the Linux kernel. One is that the PDEATHSIG is not cleared when an application does executes a suid binary and the second is that the dumpable flag is restored (not cleared) after a suid application starts a non-suid application. I verified that both issues exists in basically every Linux kernel from back then until now. Mainly the PDEATHSIG issue is around since 2.1.57 when it got introduced. And for the dumpable issue it should affect all 2.4 and 2.6 kernels. Our kernels are vulnerable and so is the upstream kernel. The PDEATHSIG issue is actually a security issue by itself. What you can do with it is that an unprivileged user can basically send any signal to a suid process at any time (until it modifies PDEATHSIG). Normally this is forbidden since you can't send signals to a privileged process and the checks for that are enforced even for PDEATHSIG. The exploitability of this depends on the suid process. For the dumpable flag issue, I think that it is the desired behavior. Please correct me if I am wrong here. If you combine them, you might get a privilege escalation and can become root. The advisory implies that they have an exploit for that, but so far they haven't provided me with any prove of it. So mainly what you need for that is a suid binary on your installation that executes other programs as root. I was thinking about userhelper and sudo, but haven't succeeded in writing an exploit yet. Does anybody else have any ideas? Regards Marcel _______________________________________________ Vendor Security mailing list Vendor Security@lst.de https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
Please use CVE-2007-3848 for the PDEATHSIG issue.
===[ ABSTRACT ]========================================================= The document describes two technically unrelated issues discovered in the Linux kernel that when exploited together may lead to local privileges escalation. ===[ IMPACT ]=========================================================== Under some circumstances any local user may gain root privileges. ===[ AFFECTED SOFTWARE ]================================================ Linux 2.6 tested on v2.6.23-rc1 Linux 2.4 not tested ===[ DESCRIPTION ]====================================================== ISSUE #1: An unprivileged user may send arbitrary signal to a child process even if it is running with higher privileges. When a parent process dies or exits its child processes may receive a signal. Each child process may choose and set its own "parent process death signal" using PR_SET_PDEATHSIG function of the prctl() system call. PARENT CHILD ---------------------------------------------------------------- fork() prctl(PR_SET_PDEATHSIG) exit()'ed or killed child receives the signal The parent process death signal is not reset over execve() system call and is inherited by spawned process: PARENT CHILD ---------------------------------------------------------------- fork() prctl(PR_SET_PDEATHSIG) execve("./a.out") exit()'ed or killed child receives the signal The signal gets delivered only if parent process has sufficient privileges to send signals to child processes. Typically any child process running with higher privilege than its parent will receive no signal. PARENT CHILD ---------------------------------------------------------------- fork() prctl(PR_SET_PDEATHSIG) execve("/bin/setuid-binary") exit()'ed or killed child receives NO signal this time However, above restriction may be bypassed if parent process execute setuid-root binary which dies afterwards. PARENT CHILD ---------------------------------------------------------------- fork() prctl(PR_SET_PDEATHSIG) execve("/bin/setuid-binary") execve("/bin/setuid-binary") exit()'ed or killed privileged process receives the signal ISSUE #2: The execve() system call may enable the dumpable flag for privileged process thus disabling the required protection against ptracing and dumping core. Typically dumpable flag is cleared whenever a privileged process is started like setuid binary. Whenever privileged process drops user privileges (i.e. changes all its UIDs and GIDs to privileged UID/GID) and then execute another binary the dumpable flag is reinitialized and set to true. The problem is illustrated below (example for typical setuid-root binary): DUMPABLE ACTION ---------------------------------------------------------------- true execve("/bin/setuid-binary") false setuid(geteuid()) setgid(getegid()) setgroups() execve("/bin/any-binary") true ... Such a task may be forced to dump core when fatal signal gets delivered to the process (like SIGSEGV) or any other user-controllable signal raises like SIGXCPU, SIGXFSZ or SIGQUIT sent from keyboard. ===[ EXPLOITATION ]===================================================== The two issues described above were successfully exploited using a proof of concept code. The exploit lets any local user to gain root privileges under specific conditions. Successful exploitation depends on additional software that must meet specific conditions described in the advisory. The exploit code will not be published. ===[ DISCLOSURE TIMELINE ]============================================== 27th July 2007 Vendor notification ===[ AUTHOR ]=========================================================== Wojciech Purczynski <cliph@research.coseinc.com> Wojciech Purczynski is a Security Researcher at Vulnerability Research Labs, COSEINC PTE Ltd. Wojciech Purczynski is also a member of iSEC Security Research. ===[ LEGAL DISCLAIMER ]================================================= Copyright (c) 2006,2007 Wojciech Purczynski Copyright (c) 2007 COSEINC PTE Ltd. All Rights Reserved. PUBLISHING, DISTRIBUTING, PRINTING, COPYING, SCANNING, DUPLICATING IN ANY FORM, MODIFYING WITHOUT PRIOR WRITTEN PERMISSION IS STRICTLY PROHIBITED. THE DOCUMENT IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. THE CONTENT MAY CHANGE WITHOUT NOTICE. IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, INJURIES, LOSSES OR UNLAWFUL OFFENCES. USE AT YOUR OWN RISK.
Date: Thu, 2 Aug 2007 18:11:36 +0100 From: Alan Cox <alan@lxorguk.ukuu.org.uk> To: Marcel Holtmann <holtmann@redhat.com> Cc: vendor-sec@lst.de Subject: Re: [vendor-sec] Potential local privilege escalation (embargoed) PDEATHSIG looks like a DoS case for the uses I can see and should probably be fixed up a bit by clearing it on an suid exec. (and the app can't fix it as I can suid exec a binary that blows up in exec) The other case looks like complete bollocks. "Such a task may be forced to dump core when fatal signal gets delivered to the process (like SIGSEGV) or any other user-controllable signal raises like SIGXCPU, SIGXFSZ or SIGQUIT sent from keyboard." Which is correct behaviour. "The execve() system call may enable the dumpable flag for privileged process thus disabling the required protection against ptracing and dumping core." This bit looks wrong about ptrace too For the ptrace case if I do the following foo exec suid bar [can't dump or ptrace] exec nonsuid app [can dump] I still can't ptrace it - because its not running as me. Alan _______________________________________________ Vendor Security mailing list Vendor Security@lst.de https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
new CRD Aug 13
patch was added by Greg to 2.6.22 stable tree: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.22.y.git;a=commit;h=c27a3393808acab7243da7455c713fe763ea2627
Brandon, can you take this patch and apply it to all other kernel branches as well?
Checked in to HEAD (by Greg), SL100_BRANCH, SLES10_SP1_BRANCH. Working on SLES9_SP3/SLES9_SP4.
SLES9_SP3/SLES9_SP4 done. closing. Thanks.
Just for the record: Patch: patches.fixes/reset-pdeath_signal-cve-2007-3848.patch included and released in SLES10-SP1 kernelupdate 2.6.16.53-0.8 dated Aug 31, 2007 & released Sep 07, 2007. Setting Whiteboard Status for SLES10-SP1 --> released
Again, for the record: Patch: patches.fixes/reset-pdeath_signal-cve-2007-3848.patch included, enabled, and released in: SLES-9 SP3 kernel update 2.6.5-7.287.3 dated Oct 02, 2007 & released Oct 11, 2007. 10.0 kernel update 2.6.13-15.18 dated Oct 03, 2007 & released Oct 10, 2007. Apparently no fix for this bug yet (despite the 10.2 Whiteboard tag) in: 10.2 kernel update 2.6.18.8-0.7 dated Oct 03, 2007 & released Oct 10, 2007. Setting Whiteboard Status for SLES9-SP3 --> released Setting Whiteboard Status for 10.0 --> released
Checked into the OpenSuSE 10.2. Sorry for missing that branch.
Re: comment 8 and comment 10 Brandon: Wasn't patches.fixes/reset-pdeath_signal-cve-2007-3848.patch (or another patch referencing to this bug) intended to be present in SLES9_SP4_BRANCH, too? I'm unable to spot anything related in a checkout taken today. Since SP4 GA is now done, and the first maintenance update is coming very soon: could you please check/verify? Reopening bug and setting to NEEDINFO. Feel free to re-set to RESOLVED as soon as the presence of the appropriate checkin into SLES9_SP4_BRANCH is verified.
Klaus: I checked in the change just now. Let me know if any other issues pop up and thanks for coaching on these releases.
released sles9 updates kernel version is: 2.6.5-7.312
CVE-2007-3848: CVSS v2 Base Score: 1.9 (AV:L/AC:M/Au:N/C:N/I:N/A:P)