Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 1 Aug 2010 07:06:36 +0200
From:      Chris Walker <chris.walker@velocitum.com>
To:        Bryan Drewery <bryan@xzibition.com>
Cc:        Kostik Belousov <kostikbel@gmail.com>, =?iso-8859-1?Q?Istv=E1n?= <leccine@gmail.com>, Selphie Keller <selphie.keller@gmail.com>, freebsd-security <freebsd-security@freebsd.org>
Subject:   Re: kernel module for chmod restrictions while in securelevel one or higher
Message-ID:  <023E2510-6766-4844-857B-1ACBA53C871E@velocitum.com>
In-Reply-To: <4C545DB0.6020901@xzibition.com>
References:  <235BB726E71747BA980A0EF60F76ED37@2WIRE304>	<20100731124136.GN22295@deviant.kiev.zoral.com.ua>	<AANLkTi=6e1ZkCEYEJS%2B74DHK8QxfaFjYHDP8JJoJE4n-@mail.gmail.com> <BD26B28B-8418-44FE-BC7D-88BA50BE26AE@velocitum.com> <4C545DB0.6020901@xzibition.com>

next in thread | previous in thread | raw e-mail | index | archive | help

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@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"
>>> 
>> _______________________________________________
>> 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"
> _______________________________________________
> 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"
> 




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?023E2510-6766-4844-857B-1ACBA53C871E>