[15359] in bugtraq
Re: Sendmail 8.10.2, Linux 2.4.0 - capabilities
daemon@ATHENA.MIT.EDU (Antonio Galea)
Thu Jun 15 15:48:18 2000
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <Pine.LNX.4.04.10006151556130.836-100000@chomp.uff.netwise.it>
Date: Thu, 15 Jun 2000 17:26:17 +0200
Reply-To: ant9000@NETWISE.IT
From: Antonio Galea <ant9000@NETWISE.IT>
X-To: xdr@hert.org
To: BUGTRAQ@SECURITYFOCUS.COM
On Sat, 10 Jun 2000, xdr wrote:
>asmlinkage int new_sys_capset(cap_user_header_t header,cap_user_data_t dataptr)
>{
> if(current->uid && !cap_raised(dataptr->inheritable, CAP_SETUID)) {
> printk(KERN_ALERT "Program attempting to possibly abuse CAP_SETUID bug: "
> "UID: %d TASK: %.15s[%d].\n",
> current->uid, current->comm, current->pid);
> return (RETURN_EPERM ? -EPERM : -EFAULT);
> }
> return orig_sys_capset(header, dataptr);
>}
I've tested this code against smlnx (posted a few days ago by Wojciech
Purczynski): I got a suid shell and no logging was done.
Adding a check before the 'if' shows that the current uid is 0... has this
anything to do with the fact that capset is called within a shared library?
If I understand it correctly, the other exploits used the user uid... but then,
you have no chance but to remove the check on the uid altogether (or stop using
shared libraries :) like this:
>asmlinkage int new_sys_capset(cap_user_header_t header,cap_user_data_t dataptr)
>{
> if(!cap_raised(...
More or less, this amounts to disabling the CAP feature ;-)
Regards,
Ant9000
--
__________________________________________________________________________
Dr. Antonio Galea N e t W i s e http://www.netwise.it
Sviluppo tecnico Advanced Network Solutions Tel/Fax 0461.421016
--------------------------------------------------------------------------
Unix _IS_ user friendly... It's just selective about who its friends are.
--------------------------------------------------------------------------
--
