Message-ID: <20040510230513.GA2374@e-matters.de>
From: s.esser at e-matters.de (Stefan Esser)
Subject: Advisory 04/2004: Net(Free)BSD Systrace local root vulnerabilitiy

                           e-matters GmbH
                          www.e-matters.de

                      -= Security  Advisory =-



     Advisory: Net(Free)BSD Systrace local root vulnerability
 Release Date: 2004/05/11
Last Modified: 2004/05/11
       Author: Stefan Esser [s.esser@...atters.de]
  Application: NetBSD with systrace support before 2004/04/09
               FreeBSD with *unofficial* port by Vladimir Kotal
     Severity: A local user with access to systrace can
               gain root privileges
         Risk: Critical
Vendor Status: Vendor has fixed the vulnerability, after 4 weeks
               still no advisory...
    Reference: http://security.e-matters.de/advisories/042004.html


Overview:

   Quote from http://www.systrace.org
   
   "Systrace enforces system call policies for applications by 
   constraining the application's access to the system. The policy 
   is generated interactively. Operations not covered by the policy 
   raise an alarm, allowing an user to refine the currently 
   configured policy."
   
   A code audit of systrace on various platforms revealed a flaw in
   its NetBSD implementation (which is also present in the unofficial
   FreeBSD port by Vladimir Kotal). This flaw allows a local user with
   access to the systrace device to abuse the privilege elevation
   feature to gain root permissions.
   
   
Details:

   At the end of March Brad Spengler from grsecurity informed the 
   world about a silently patched systrace bypass vulnerability
   within the linux port of systrace. He also revealed that he found
   two more holes within systrace, which he did not disclose further.
   His mail was reason enough to have a look into systrace on nearly 
   all of its supported platforms.
   
   Soon it was discovered that the NetBSD implementation and the 
   FreeBSD port implement the privilege elevation feature in a
   different way. After a system call was called with raised 
   permissions it will restore the elevated permissions if the flags 
   say so. Unlike the OpenBSD or Linux implementation it does not
   check for super user privileges when restoring the user id.
   This was most probably done because the syscall handling is split
   up within NetBSD/FreeBSD into a part which is called on enter
   and a part which is called on exit.
   
   The superuser check is missing within the exit code because the 
   procedure which is called on enter clears the corresponding flags.
   It should be obvious that tricking the exit procedure into
   restoring the process permissions to the savedugid values results
   into superuser permissions because those are initialised to zero.
   
   At this point the flaw seems unexploitable because it seems 
   impossible to enter the exit procedure with the flags set correctly
   due to the fact that the systrace design forbids sending privilege
   elevation messages to the process while it is within a system call.
   
   It is necessary to dig a bit deeper into the NetBSD kernel to 
   finally find the answer to the question of exploitability. (Same
   for FreeBSD) For NetBSD the problem is located within syscall_fancy()
   which is responsible for handling traced syscall. This routine was
   designed in a way that an error while copying the system call
   arguments into kernelspace will result in trace_enter() and the
   actual system call itself to be skipped, while trace_exit() is
   called nevertheless.
   
   Combined this means exploiting this vulnerability comes down do
   attaching to a child process, sending a privilege elevation
   answer to a system call result message and magically letting the 
   kernel fail when copying the arguments to the next system call. 
   Everyone who knows his assembly language will know how to achieve 
   this with minimum effort.
   
   After this simple process the child has super user privileges.


Proof of Concept:

   e-matters is not going to release an exploit for any of these 
   vulnerabilities to the public. 


Disclosure Timeline:

    4. April 2004 - The NetBSD security officers and Niels Provos
                    were informed about this vulnerability by
                    email.
    9. April 2004 - Bug is fixed in NetBSD CVS tree.
   11. April 2004 - NetBSD informs me that they hope to release
                    within the week.
   16. April 2004 - After realising that the unofficial FreeBSD
                    port is also affected Vladimir Kotal gets
		    informed by email
   27. April 2004 - Vladimir Kotal replies that he is too busy to
                    fix at the moment
    3. May   2004 - After contacting NetBSD again their tell me
                    that they "lost track" and hope to release
		    within the week (again)
   11. May   2004 - Since the fix over a month has passed. 
                    Still no vendor advisory. Public Disclosure.


Recommendation:

   It is strongly recommended to update your version of NetBSD as 
   soon as possible because exploiting this vulnerability is pretty
   straight forward. 
   
   
GPG-Key:

   http://security.e-matters.de/gpg_key.asc
    
   pub  1024D/75E7AAD6 2002-02-26 e-matters GmbH - Securityteam
   Key fingerprint = 43DD 843C FAB9 832A E5AB  CAEB 81F2 8110 75E7 AAD6


Copyright 2004 Stefan Esser. All rights reserved.




-- 

--------------------------------------------------------------------------
 Stefan Esser                                        s.esser@...atters.de
 e-matters Security                         http://security.e-matters.de/

 GPG-Key                gpg --keyserver pgp.mit.edu --recv-key 0xCF6CAE69 
 Key fingerprint       B418 B290 ACC0 C8E5 8292  8B72 D6B0 7704 CF6C AE69
--------------------------------------------------------------------------
 Did I help you? Consider a gift:            http://wishlist.suspekt.org/
--------------------------------------------------------------------------

Powered by blists - more mailing lists