From owner-freebsd-security Sat Sep 8 17:38:10 2001 Delivered-To: freebsd-security@freebsd.org Received: from aries.ai.net (aries.ai.net [205.134.163.4]) by hub.freebsd.org (Postfix) with ESMTP id 3EDF737B401 for ; Sat, 8 Sep 2001 17:38:05 -0700 (PDT) Received: from blood (pool-138-88-72-170.res.east.verizon.net [138.88.72.170]) by aries.ai.net (8.9.3/8.9.3) with SMTP id UAA19631; Sat, 8 Sep 2001 20:45:40 -0400 (EDT) (envelope-from deepak@ai.net) Reply-To: From: "Deepak Jain" To: "Kris Kennaway" , "D J Hawkey Jr" Cc: "Alexander Langer" , Subject: RE: Kernel-loadable Root Kits Date: Sat, 8 Sep 2001 20:41:53 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <20010908153700.B72780@xor.obsecurity.org> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Presumably, a user in userland has root to be loading a kernel module in the first place. This user could easily edit the rc.conf file to boot up in securelevel=-1 and reboot the machine -- as well as circumvent most notifications about the reboot. Hell, if I wanted to compromise a box, screwing the kernel directly is the way to go. Especially for remotely administered boxes, there is almost no downside. Deepak Jain AiNET -----Original Message----- From: Kris Kennaway [mailto:kris@obsecurity.org] Sent: Saturday, September 08, 2001 6:37 PM To: D J Hawkey Jr Cc: Alexander Langer; deepak@ai.net; freebsd-security@FreeBSD.ORG Subject: Re: Kernel-loadable Root Kits On Sat, Sep 08, 2001 at 10:28:16AM -0500, D J Hawkey Jr wrote: > Q: Can the kernel be "forced" to load a module from within itself? That > is, does a cracker need to be in userland? If you're at securelevel 1 or higher, you shouldn't be able to cause untrusted code to be loaded by the kernel by "legal" means, only by "illegal" means such as exploiting kernel buffer overflows and other bugs which may exist. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message