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: <40D16101.60900@oucs.ox.ac.uk>
Date: Thu, 17 Jun 2004 10:14:41 +0100
From: Ivaylo Kostadinov <ivaylo.kostadinov@...puting-services.oxford.ac.uk>
Cc: bugtraq@...urityfocus.com, cert@...t.org, phrackstaff@...ack.org,
	staff@...ketstormsecurity.org, security@...eBSD.org
Subject: Re: Unprivilegued settings for FreeBSD kernel variables


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



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ