From owner-freebsd-security Tue Feb 18 17:36:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA19513 for security-outgoing; Tue, 18 Feb 1997 17:36:15 -0800 (PST) Received: from enteract.com (root@enteract.com [206.54.252.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA19501 for ; Tue, 18 Feb 1997 17:36:08 -0800 (PST) Received: (from tqbf@localhost) by enteract.com (8.8.5/8.7.6) id TAA12057 for freebsd-security@freebsd.org; Tue, 18 Feb 1997 19:34:12 -0600 (CST) From: "Thomas H. Ptacek" Message-Id: <199702190134.TAA12057@enteract.com> Subject: Security problem in FreeBSD /sbin/init To: freebsd-security@freebsd.org Date: Tue, 18 Feb 1997 19:34:11 -0600 (CST) Reply-To: tqbf@enteract.com X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This problem will probably be picked up by the sweeping audit of your code base, but I figured I'd alert you to it anyways. FreeBSD, in revisions up to and including -current, has a stack overrun in /sbin/init. The affected routines are "start_getty()" and "start_window_system()", both of which can be tricked into reading an overly large "type" entry from the /etc/ttys file (which is copied into an array on the stack used to hold the "TERM" environment variable for a subsequent execve() call). This overflow is only exploitable if you control /etc/ttys. On almost all systems, this means it's only an issue if you're root. Unfortunately, this is a serious issue in init's case. Unbeknownst to many, init (or, more specifically, PID 1) can change the securelevel arbitrarily in 4.4BSD systems. The purpose of securelevels is to "secure the system from root", disabling the modification of crucial system binaries. The "immutable" flag depends on this concept. This overflow provides intruders with a means to evade the immutable (or append-only, or any other securelevel-dependant concept) mechanism. Given my relative unfamiliarity with the FreeBSD CVS "protocol", such as it is, I'll leave it for another developer to fix this. The problem is an unchecked string copy in both routines, and can easily be resolved by sticking an "n" in the strcpy() function call. Good luck with the audit. ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com] ---------------- "If you're so special, why aren't you dead?"