Bugtraq mailing list archives
Re: Unprivilegued settings for FreeBSD kernel variables
From: Ivaylo Kostadinov <ivaylo.kostadinov () computing-services oxford ac uk>
Date: Thu, 17 Jun 2004 10:14:41 +0100
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.koWhy 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
Current thread:
- Unprivilegued settings for FreeBSD kernel variables Radko Keves (Jun 15)
- Re: Unprivilegued settings for FreeBSD kernel variables Dag-Erling Smørgrav (Jun 16)
- Re: Unprivilegued settings for FreeBSD kernel variables Eygene A. Ryabinkin (Jun 18)
- Re: Unprivilegued settings for FreeBSD kernel variables Jason V. Miller (Jun 18)
- Re: Unprivilegued settings for FreeBSD kernel variables Christian Ullrich (Jun 18)
- Re: Unprivilegued settings for FreeBSD kernel variables Ivaylo Kostadinov (Jun 18)
- Re: Unprivilegued settings for FreeBSD kernel variables Eygene A. Ryabinkin (Jun 18)
- Re: Unprivilegued settings for FreeBSD kernel variables Manuel Bouyer (Jun 18)
- Re: Unprivilegued settings for FreeBSD kernel variables Valdis . Kletnieks (Jun 19)
- Re: Unprivilegued settings for FreeBSD kernel variables Wietse Venema (Jun 22)
- Re: Unprivilegued settings for FreeBSD kernel variables Henning Brauer (Jun 19)
- Re: Unprivilegued settings for FreeBSD kernel variables Valdis . Kletnieks (Jun 19)
- Re: Unprivilegued settings for FreeBSD kernel variables Jason V. Miller (Jun 21)
- <Possible follow-ups>
- Re: Unprivilegued settings for FreeBSD kernel variables blexim (Jun 20)
- Re: Unprivilegued settings for FreeBSD kernel variables Dag-Erling Smørgrav (Jun 16)