Re: Vulnerability in 4.4BSD Secure Levels Implementation

[tqbf () pobox com (tqbf () pobox com)]

> We have discovered a vulnerability in all current implementations of
> secure levels which allow an intruder to modify the memory image of
> running processes, thereby bypassing the protection applied to system
> binaries and their configuration files.  The vulnerability cannot be
> exploited to modify the init process, kernel memory or the protected
> files themselves.

While I certainly respect the work you are putting into auditing 4.4BSD, I
do not think you have discovered anything, and I do not think that what
you are discussing is a bug. I do not understand why Theo de Raadt, who
understands this issue better than I do, believes that the issue being
considered here is worth a patch.

To start with, the fact that processes can be "hijacked" when the system
is in secure mode is well known. Please consult the June, 1997 OpenBSD
security advisory regarding procfs vulnerabilities for prior art in
published advisories; this document acknowledges that processes other than
init can be taken over by root. You can obtain this advisory, along with
all other OpenBSD security advisories, from the OpenBSD website. See:
"http://www.openbsd.org/advisories/procfs";.

I realize that you are referring specifically to the fact that a process
which was loaded into memory from an immutable file does not have an
"immutable" text segment. I don't see where it is documented that these
semantics hold. McKusick et al do not mention anything about the text
segment of "login" being immutable, and the "man" page documentation for
the immutable flag doesn't mention it either.

I do not understand how the attack you describe poses a major threat to
the current securelevels semantics. There remains no published method for
altering or truncating the contents of an immutable or append-only file on
OpenBSD 2.2, and there remains no published method for accessing kernel
memory in securelevel 1 on OpenBSD.

The access you talk about obtaining by patching "inetd" can just as easily
be obtained by replacing it with another process entirely; even on secure
systems, unless the inetd process is watched very carefully, it is
possible to transparently replace inetd with another program, while
maintaining the process ID. The fact that inetd is running from a
different binary is not much more noticeable than the fact that, for
instance, telnetd is running from a new binary.

Meanwhile, patching this "problem" means that I cannot debug programs that
run from immutable files. More importantly, I can't take over and perform
forensics on a live attacking process; an attacker merely flags her
sniffer "immutable", and I suddenly have no way of backdooring it. From my
perspective, "fixing" this problem loses more for me much more than it
wins.

Of course, the core issue here is that securelevels are silly. The 4.4BSD
kernel is not secure against "root". It wasn't designed to be. Adding a
global flag to the kernel and periodically checking it doesn't alter this
fact; root is too powerful, and "securelevels" are a hack that attempts
(and fails, IMO) to perform damage control. Don't defend it; replace it
with something that works (like compartmentalization/domain-type
enforcement).

-----------------------------------------------------------------------------
Thomas H. Ptacek          The Company Formerly Known As Secure Networks, Inc.
-----------------------------------------------------------------------------
http://www.pobox.com/~tqbf       "If you're so special, why aren't you dead?"