lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20040618171805.GA3538@securityfocus.com>
Date: Fri, 18 Jun 2004 11:18:06 -0600
From: "Jason V. Miller" <jmiller@...urityfocus.com>
To: "Eygene A. Ryabinkin" <rea@....mbslab.kiae.ru>
Cc: bugtraq@...urityfocus.com
Subject: 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@...urityfocus.com


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ