freebsd security - Jul 2010 - kernel module for chmod restrictions while in securelevel one or higher

Kernel module for chmod restrictions while in securelevel one or higher:
http://gist.github.com/501800 (fbsd 8.x)

Was looking at the new recent sendfile/mbuf exploit and it was using a
shellcode that calls chmod syscall to make a setuid/setgid binary. However
was thinking of ways to block the creation of suid/sgid binaries if the
machine is in a securelevel, beyond the normal things like nosuid/noexec
mount flags for /tmp.

So came up with this quick module to handle it, but the concept of
restricting the creation of suid/sgid binaries while in securelevel seems
like a good idea to be part of the base. 

 

-Estella Mystagic

On Fri, Jul 30, 2010 at 11:18:39PM -0700, Selphie Keller
wrote:
> Kernel module for chmod restrictions while in securelevel one or higher:
> http://gist.github.com/501800 (fbsd 8.x)
> 
> Was looking at the new recent sendfile/mbuf exploit and it was using a
> shellcode that calls chmod syscall to make a setuid/setgid binary. However
Can you point to the exploit (code) ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url :
http://lists.freebsd.org/pipermail/freebsd-security/attachments/20100731/b8c4800e/attachment.pgp

On Sat, Jul 31, 2010 at 01:59:43PM +0100, Istv??n wrote:
> http://www.securiteam.com/exploits/6P00C00EKO.html
This is an exploit for the archaic SA-05:02.sendfile. Op (semi-)obviously
means exploit for the recent SA-10:07.mbuf, for which I am very
curious whether the working exploit appeared in the wild.
> 
> On Sat, Jul 31, 2010 at 1:41 PM, Kostik Belousov
<kostikbel@gmail.com>wrote:
> 
> > On Fri, Jul 30, 2010 at 11:18:39PM -0700, Selphie Keller wrote:
> > > Kernel module for chmod restrictions while in securelevel one or
higher:
> > > http://gist.github.com/501800 (fbsd 8.x)
> > >
> > > Was looking at the new recent sendfile/mbuf exploit and it was
using a
> > > shellcode that calls chmod syscall to make a setuid/setgid
binary.
> > However
> > Can you point to the exploit (code) ?
> >
> 
> 
> 
> -- 
> the sun shines for all
> 
> http://l1xl1x.blogspot.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url :
http://lists.freebsd.org/pipermail/freebsd-security/attachments/20100731/5f24d825/attachment.pgp

sorry my bad

On Sat, Jul 31, 2010 at 2:04 PM, Kostik Belousov
<kostikbel@gmail.com>wrote:
> On Sat, Jul 31, 2010 at 01:59:43PM +0100, Istv??n wrote:
> > http://www.securiteam.com/exploits/6P00C00EKO.html
> This is an exploit for the archaic SA-05:02.sendfile. Op (semi-)obviously
> means exploit for the recent SA-10:07.mbuf, for which I am very
> curious whether the working exploit appeared in the wild.
>
> >
> > On Sat, Jul 31, 2010 at 1:41 PM, Kostik Belousov
<kostikbel@gmail.com
> >wrote:
> >
> > > On Fri, Jul 30, 2010 at 11:18:39PM -0700, Selphie Keller wrote:
> > > > Kernel module for chmod restrictions while in securelevel
one or
> higher:
> > > > http://gist.github.com/501800 (fbsd 8.x)
> > > >
> > > > Was looking at the new recent sendfile/mbuf exploit and it
was using
> a
> > > > shellcode that calls chmod syscall to make a setuid/setgid
binary.
> > > However
> > > Can you point to the exploit (code) ?
> > >
> >
> >
> >
> > --
> > the sun shines for all
> >
> > http://l1xl1x.blogspot.com
>


-- 
the sun shines for all

http://l1xl1x.blogspot.com

http://www.securiteam.com/exploits/6P00C00EKO.html

<http://www.securiteam.com/exploits/6P00C00EKO.html>HTH

On Sat, Jul 31, 2010 at 1:41 PM, Kostik Belousov
<kostikbel@gmail.com>wrote:
> On Fri, Jul 30, 2010 at 11:18:39PM -0700, Selphie Keller wrote:
> > Kernel module for chmod restrictions while in securelevel one or
higher:
> > http://gist.github.com/501800 (fbsd 8.x)
> >
> > Was looking at the new recent sendfile/mbuf exploit and it was using a
> > shellcode that calls chmod syscall to make a setuid/setgid binary.
> However
> Can you point to the exploit (code) ?
>


-- 
the sun shines for all

http://l1xl1x.blogspot.com

Hi list

#1 Not same exploit referenced in URL.
#2 Not same bug, although you had the function right, sort of.
#3 That kernel module is useless: The exploit in the wild has already changed to
bypass such restriction.
#4 The bug is already patched, upgrade your kernel.
#5 If you intend on introducing a kernel module that potentially makes your
system unstable, make sure it actually fixes the bug. This workaround merely
made the exploit grow more lethal, and provides a FALSE sense of a security, and
as such I would *STRONGLY* discourage use of this kernel module.

This is a perfect example of why software developers never ever will be able to
fight blackhat hackers: Ignorance.

Thanks.

On Jul 31, 2010, at 2:59 PM, Istv?n wrote:
> http://www.securiteam.com/exploits/6P00C00EKO.html
> 
> <http://www.securiteam.com/exploits/6P00C00EKO.html>HTH
> 
> On Sat, Jul 31, 2010 at 1:41 PM, Kostik Belousov
<kostikbel@gmail.com>wrote:
> 
>> On Fri, Jul 30, 2010 at 11:18:39PM -0700, Selphie Keller wrote:
>>> Kernel module for chmod restrictions while in securelevel one or
higher:
>>> http://gist.github.com/501800 (fbsd 8.x)
>>> 
>>> Was looking at the new recent sendfile/mbuf exploit and it was
using a
>>> shellcode that calls chmod syscall to make a setuid/setgid binary.
>> However
>> Can you point to the exploit (code) ?
>> 
> 
> 
> 
> -- 
> the sun shines for all
> 
> http://l1xl1x.blogspot.com
> _______________________________________________
> freebsd-security@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to
"freebsd-security-unsubscribe@freebsd.org"
>

On Fri, 30 Jul 2010, Selphie Keller wrote:
> Kernel module for chmod restrictions while in securelevel one or higher: 
> http://gist.github.com/501800 (fbsd 8.x)
>
> Was looking at the new recent sendfile/mbuf exploit and it was using a 
> shellcode that calls chmod syscall to make a setuid/setgid binary. However 
> was thinking of ways to block the creation of suid/sgid binaries if the 
> machine is in a securelevel, beyond the normal things like nosuid/noexec 
> mount flags for /tmp.
>
> So came up with this quick module to handle it, but the concept of 
> restricting the creation of suid/sgid binaries while in securelevel seems 
> like a good idea to be part of the base.
While I'm not convinced this approach is a good idea (the remainder of the 
thread suggests some reasons why), a better way to implement the same policy 
would be to use the MAC Framework's mpo_vnode_check_setmode entry point. 
This
would catch all the chmod variations, including ones in compatibility ABIs 
such as the Linux ABI.

Robert