On Jun 11, 10:33pm, tqbfat_private 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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:57:57 PDT