Message-ID: <20040618170832.GA17663@securityfocus.com>
Date: Fri, 18 Jun 2004 11:08:32 -0600
From: "Jason V. Miller" <jmiller@...urityfocus.com>
To: Radko Keves <rado@...tra.sk>
Cc: bugtraq@...urityfocus.com, security@...eBSD.org
Subject: Re: Unprivilegued settings for FreeBSD kernel variables


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@...mon.sk>

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

Powered by blists - more mailing lists