From owner-freebsd-stable@FreeBSD.ORG Wed Apr 4 16:13:51 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EB31106564A for ; Wed, 4 Apr 2012 16:13:51 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 37D1E8FC16 for ; Wed, 4 Apr 2012 16:13:51 +0000 (UTC) Received: by vbmv11 with SMTP id v11so405681vbm.13 for ; Wed, 04 Apr 2012 09:13:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3ozNCM0IFoE7ltSsxtMxyMryon+L8QMYEjIUfDMklTA=; b=Ytkn09K5bQLRrhZtF2a39em2vFNnurFee4HPysw9h54OINY8mp+gK+B1AdC8Y9/dto KGMxZkpmPiYGnQem+oIilsnNrI5ap2xCs2PC8j7iNODSaHir0Rb3YlOpfXfInILCEVe8 S92ZnqXxoLAkBSPA89fek6nSBRkfh2lceK1wo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=3ozNCM0IFoE7ltSsxtMxyMryon+L8QMYEjIUfDMklTA=; b=gDjANFJPRcyjSV3wOomTfQD1admVGKYSrSAG+gniNQbnV6dkgwe6ao9D7hzO7vHIXq TgXfs4IAZQCGQQUHs6cCtr+/30nk+ZS1GeanCDwbrBoGtMO0EAuM9n0rwNpIhma63xQl XKhf5xO0DzyxLzr/kIkp/Wh+vN7OqcrMXDfLqQREaRneXcV/3PwgECBhp/KlxDmxeBET 6rsm5PG/y49EGOxocb52XcBAxuHVVAOdOWmjTcof5L3cCqPkq91/SN9LnkzSc1sHtEce Ah0jqLRGMS0uTX9BI/AhOEu4HxeuKXfh9V+SLNwlRWQ8vjTHAyjA0nxRVKYu0iXoC+vr 6hYw== MIME-Version: 1.0 Received: by 10.52.17.239 with SMTP id r15mr6885383vdd.95.1333556030643; Wed, 04 Apr 2012 09:13:50 -0700 (PDT) Received: by 10.220.180.199 with HTTP; Wed, 4 Apr 2012 09:13:50 -0700 (PDT) In-Reply-To: References: <4F766F29.2030803@cs.stonybrook.edu> <4F79D88B.3040102@cs.stonybrook.edu> <4F79E27E.3000509@cs.stonybrook.edu> <4F79FCB8.1090003@cs.stonybrook.edu> <4F7A05C4.9070808@cs.stonybrook.edu> <20120403170259.GA94837@neutralgood.org> <1333550029.1090.67.camel@revolution.hippie.lan> Date: Wed, 4 Apr 2012 09:13:50 -0700 Message-ID: From: Peter Wemm To: jb Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn5QCnIFrdVGFDfGfquQl5BXPGUrmKjciYKW0MF+IKKQxGzmlv8opYmlQgDrsOjYE8m3pz5 Cc: freebsd-stable@freebsd.org Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 16:13:51 -0000 On Wed, Apr 4, 2012 at 8:05 AM, jb wrote: > Ian Lepore damnhippie.dyndns.org> writes: > >> ... >> > But of interest to me is this: >> > "... >> > Text relocations are a way in which references in the executable code to >> > addresses not known at link time are solved. Basically they just write >> > the appropriate address at runtime marking the code segment writable in >> > order to change the address then unmarking it. This can be a problem as >> > an attacker could try to exploit a bug when the text relocation happens >> > in order to be able to write arbitrary code in the text segment which >> > would be executed. >> > ..." >> ... >> A kernel module is loaded and linked >> ONCE, at load time, into the kernel's address space. >> ... > > >From the point of view of an attacker it does not matter whether kernel module > is loaded and linked once only. That's enough to create a window of opportunity > for interfering with relocation process and modifying text (code). There is no way to interfere because it is done outside of user space entirely, **after** the file has been copied out of the file system. You can do whatever you like to the file, but it has no effect because all the relocation is done in a private kernel copy. In linux, the module tools do the linking and hand the resulting block of memory to the kernel. In freebsd, the module tools are third parties in the process. The copy is done while the vnode is locked. Any attempt to write to the file, or page fault via a mmap(MAP_SHARED) will sleep till the lock is released and the kernel has completed the copy of the contents. Once the lock is released, it doesn't matter what you do because the kernel is operating on a private, non-shared copy that you can't get anywhere near. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell