Re: Unprivilegued settings for FreeBSD kernel variables
Please have a look at my post in response to the original message, as there
is some misunderstanding here.
If an attacker compromises a machine running at security level 3, then they
cannot lower the securelevel sysctl. The "technique" used in the original
post involved loading an arbitrary kernel module while the system was still
running at security level -1, which basically introduced a backdoor into
the kernel that would allow an attacker to lower it afterwards.
As DES explains, the attacker would require unrestricted access (at
security level < 1) in order to implement this "attack". It's not a
vulnerability.
J.
On Thu, Jun 17, 2004 at 06:33:49PM +0400, Eygene A. Ryabinkin wrote:
> On Tue, Jun 15, 2004 at 09:01:13PM +0200, Dag-Erling Sm?rgrav wrote:
> > I've already told you that there is no such threat, since the attack
> > you describe can only be initiated by someone who already has
> > unrestricted access. Please stop wasting everybody's time.
> You are wrong. Unrestricted access means _really unrestricted_ and
> kernel securelevel restricts access to certain places even to root.
> IMHO, it's dagerous bug, because some administrators can think "...hmm,
> I've enabled the hardest securelevel and even if a hacker would break
> into my host with r00t privileges he will be restricted in certain ways.
> The only thing he can do is to change /etc/rc.conf (for example) and
> _reboot_ my host. But I will notice the reboot." So, for certain
> people the following formulae may hold:
> Hardest securelevel + no reboots = good security.
>
> But this bug changes things. One can lower securelevel, do some nasty things
> and raise it again _without reboots_. So, as I've already noted, you are
> wrong.
> The bug _gives_ you almost unrestricted access.
> rea
--
Jason V. Miller, Threat Analyst
Symantec, Inc. - www.symantec.com
E-Mail: jmiller@xxxxxxxxxxxxxxxxx