> 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?"
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:57:38 PDT