kernel module for chmod restrictions while in securelevel one or higher

Chris Walker chris.walker at velocitum.com
Sun Aug 1 05:09:59 UTC 2010


Bryan, it is merely a statement of facts.
Another statement of facts: Your kernel module to remove sendfile syscall breaks a ton of applications.

The right thing to do is _always_ to patch properly. In this case it would be either: Patch your kernel and reboot *or* load a replacement call. The recommended approach by the FreeBSD security officer is obviously to patch up and reboot. Removing a syscall because you want to maintain uptime on the shell provider you run is just ludacris. That said, there is already functionality in place to prevent this. MAC framework springs to mind. :)
If you are interested in a flamewar you have my email, let's keep it off-list. thanks.



On Jul 31, 2010, at 7:30 PM, Bryan Drewery wrote:

> The module/change never proposed to stop the exploit. There's no reason
> to attack someone trying to help the community. It's merely adding on
> top of the already existing securelevel restrictions, such as chflags
> restrictions. It makes a lot of sense to restrict setuid/setgid when in
> securelevel, based on the fact that flags are as well.
> 
> But maybe securelevel should just be removed? By your arguments it's
> useless, makes the system unstable and gives a false sense of security.
> 
> Bryan
> 
> On 7/31/2010 10:39 AM, Chris Walker wrote:
>> 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 at 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 at freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-security
>>> To unsubscribe, send any mail to "freebsd-security-unsubscribe at freebsd.org"
>>> 
>> _______________________________________________
>> freebsd-security at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-security
>> To unsubscribe, send any mail to "freebsd-security-unsubscribe at freebsd.org"
> _______________________________________________
> freebsd-security at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscribe at freebsd.org"
> 



More information about the freebsd-security mailing list