Privilege escalation is possible for users with access to the systrace device on Net-BSD and Free-BSD.
5055b81404726430cf6bf4f0924753685d120e9b3cabd9c41fc131e5cd09cfb0
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@e-matters.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: https://security.e-matters.de/advisories/042004.html
Overview:
Quote from https://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 informed 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 they 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:
https://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.