Dailydave mailing list archives

securelevels


From: dave <dave () immunitysec com>
Date: Wed, 16 Jun 2004 13:15:11 -0400

Anonymized post follows

--------------------------

Anyone see the humor in this post to bugtraq and everything else? For those
uninitiated with FreeBSD, this guy is basically raising a security concern
where one is already present. If the kern.securelevel is already -1 ( which
means that root is able to load a kld ( kernel module ) into the system )
why bother with loading his trivial code to lower the securelevel and then
raising it to only lower it again? IIRC, the FreeBSD manpages even suggest
raising the kern.securelevel to 1 after initial installation thereby
forcing root to reboot the system to adjust the securelevel and insert
their kld. His paranoia is misplaced with a complete misunderstanding of
FreeBSD securelevels. Just seems to be a bit more of the larger issue of
people seeking notoriety on public mailing lists....


Cheers

------------------------- rado () unitra sk said on 06/16/04 11:04 AM
-----------------------------------
rado () unitra sk 06/15/2004 08:42 To AM bugtraq () securityfocus com, cert () cert org cc phrackstaff () phrack org, staff () packetstormsecurity org, security () FreeBSD org Subject Unprivilegued settings for FreeBSD kernel variables



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




_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://www.immunitysec.com/mailman/listinfo/dailydave


Current thread: