Re: Vulnerability in 4.4BSD Secure Levels Implementation

[njs3 () DOC IC AC UK (Niall Smart)]

On Jun 11, 10:33pm, tqbf () POBOX COM wrote:
} Subject: Re: Vulnerability in 4.4BSD Secure Levels Implementation
> > 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.

[snip]

> 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.

That advisory concerns a vulnerability then present in procfs which
allowed the root user to circumvent the supposed immutability of the
init process' address space in secure mode.  The advisory we issued
concerns the semantics of the immutable filesystem flag,  the OpenBSD
advisory you refer to does not mention these semantics either explicitly
or implicitly and so I fail to see how it can be claimed as prior art,
nor can I find any mention in it of the fact that processes other than
init can be taken over by root.  Of course anyone capable of reading the
source code can determine this,  but documentation of a security bug in
the form of the buggy source code hardly qualifies as "prior art".

> 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.

Not propagating the immutable filesystem flag on an executable to its
address space, as you suggest is the correct and documented behaviour,
implies the following:

 - The only use of the immutable flag is to protect the disk images
   of the kernel, init, the LKMs and the directories in which they reside.
   Assuming your semantics are correct, I can see no use in using it
   to protect any others.  Do you think that protection of these 5-6
   files, which could just as easily have been achieved using the
   append-only flag, was the sole purpose of the introduction of the
   immutable flag?

 - The syslogd daemon can be covertly compromised, so no useful
   information ever gets logged to the protected system logs.  But at
   least no-one can modify the useless information.

 - Any conventional binary or library used to view the log files can
   be compromised, although compromising these would be a waste of time
   since that the logs don't have any useful information anyway.

 - Performing a syscall requires you to attempt to defeat any backdoors
   inserted at runtime in the executable.

McKusick et al have this to say:

   Files marked immutable include those that are frequently the subject
   of attack by intruders (e.g., login and su).  The append-only flag
   is typically used for critical system logs.  If an intruder breaks
   in, he will be unable to cover his tracks.  Although simple in
   concept, these two features improve the security of a system
   dramatically.

Why do they advocate protecting login and su if such protection can
be trivially defeated using the same techniques we demonstrated in
the attack on inetd?  And why do they claim these features improve the
security of a system "dramatically" if they can be bypassed so easily?
Either they didn't read the chflags man page (hmm, I think they wrote it),
they advocate partial security (hmm, don't think so), or there is a bug.
I believe the latter is the case.

Propogation of the immutable flag is the logical and correct thing to do.
I agree that this behaviour is not explicitly documented, however it
is a reasonable expectation that people hold.  Secure levels become a
farce without it.

> 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.

A system which does not watch inetd very carefully is, by definition,
not a secure system.  If an administrator judges the level of risk to
the machine to warrant the use of secure levels but doesn't then watch
inetd and the other daemons then he deserves whatever he gets.

> 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.

It is not necessary to involve any new binaries whatsoever to exploit
the vulnerability, for example you can simply load /usr/libexec/telnetd
and then hose it in situ using ptrace.  How are you going to detect that?
Its easier to prevent it happening in the first place.

> 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.

I think you're overplaying the importance of the problem.  Firstly,
understanding the sniffer is only practical with access to its source
code because the attacker can easily obfuscate the machine code to such
an extent that deciphering it would be impossible.  Presumably someone
who has broken root on your system knows better than to leave the source
code lying around.  Secondly, with regard to maintaining the ability to
backdoor a sniffer without killing it, you could allow write access to an
immutable process from the console.  Another possibility is to prevent the
setting of the immutable flag on a file when the system is in secure mode.

> 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).

Well, if you can find someone with sufficient time to attempt this and
sufficient skill to implement it without introducing new security problems
then that would be great.  However I'm trying to fix the current model,
not introduce a new one.

Niall