BugTraq
Unprivilegued settings for FreeBSD kernel variables Jun 15 2004 06:42AM
Radko Keves (rado unitra sk) (3 replies)
Re: Unprivilegued settings for FreeBSD kernel variables Jun 18 2004 05:08PM
Jason V. Miller (jmiller securityfocus com)
Re: Unprivilegued settings for FreeBSD kernel variables Jun 17 2004 11:28AM
Manuel Bouyer (bouyer antioche eu org) (2 replies)
Re: Unprivilegued settings for FreeBSD kernel variables Jun 18 2004 09:27PM
Valdis Kletnieks vt edu (1 replies)
Re: Unprivilegued settings for FreeBSD kernel variables Jun 19 2004 09:38PM
wietse porcupine org (Wietse Venema)
Re: Unprivilegued settings for FreeBSD kernel variables Jun 18 2004 08:25PM
Henning Brauer (hb-bugtraq bsws de)
Re: Unprivilegued settings for FreeBSD kernel variables Jun 15 2004 07:01PM
des des no (Dag-Erling Smørgrav) (2 replies)
Re: Unprivilegued settings for FreeBSD kernel variables Jun 17 2004 02:33PM
Eygene A. Ryabinkin (rea rea mbslab kiae ru) (2 replies)
Re: Unprivilegued settings for FreeBSD kernel variables Jun 18 2004 06:01PM
Christian Ullrich (chris chrullrich de)
Re: Unprivilegued settings for FreeBSD kernel variables Jun 18 2004 05:18PM
Jason V. Miller (jmiller securityfocus com)
Re: Unprivilegued settings for FreeBSD kernel variables Jun 17 2004 09:14AM
Ivaylo Kostadinov (ivaylo kostadinov computing-services oxford ac uk)
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.

If the vulnerability described exists then there is such a threat.

The sole purpose of the FreeBSD secure levels is to prevent even someone
with unrestricted access from performing certain operations unless
working on the console and the system is in "maintenance" mode.

Imagine a bootable-CD-only FreeBSD system acting as router/firewall in
securelevel 3. Even if somehow a hacker gets remote access to the system
she/he will not be able to change the firewall setup.
If however the hacker is able to reduce the secure level the she/he can
reconfigure the firewall and thus disrupt the only function the system
is meant to perform.

This said if we look at the described "... security threat in basic
security facility..." :

>
> EXAMPLE:
> kernel module can gives you a new sysctl (for example kern.securelevel2):
> kern.securelevel2
> with which you can lower/raiser sysctl.securelevel variable
> (source code attached)
>
> $ kldstat
> Id Refs Address Size Name
> 1 7 0xc0400000 4378e4 kernel
> ...
> $
> $ kldload ./securelevel2.ko
> $ kldstat
> Id Refs Address Size Name
> 1 8 0xc0400000 4378e4 kernel
> ...
> 8 1 0xc4e96000 2000 securelevel2.ko

Why would you want to load the above-mentioned module? I mean except for
the purpose of exposing the securelevel2 variable.

This command only:

> sudo sysctl kern.securelevel=3

will safely put the system in the corresponding securelevel

> SYSCTL_PROC(_kern, OID_AUTO, securelevel2, CTLTYPE_LONG|CTLFLAG_RW,
0, 0, sysctl_securelevel2, "I", ".");
> [...]
>

I have not checked where this code is from but it seems to me that the
CTLFLAG_SECURE or similar flags are missing there.
Does this not indicate that the sysctl variable is intended to be
modifiable at any securelevel?

In conclusion, the described scenario would reduce the securelevel but
it will have to be engineered and greatly helped by the rightful admin
of the system.
And I must say I have definitely seen easier ways to Trojan-horse your
own host.

Best wishes,

ivaylo kostadinov

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus