From owner-freebsd-stable@FreeBSD.ORG Wed Apr 4 16:07:50 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DE89C106564A for ; Wed, 4 Apr 2012 16:07:50 +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 7FBE28FC15 for ; Wed, 4 Apr 2012 16:07:50 +0000 (UTC) Received: by vbmv11 with SMTP id v11so398023vbm.13 for ; Wed, 04 Apr 2012 09:07: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:content-transfer-encoding; bh=pK5X1giK7JfriXsAgAM1aM8XXrr9KBQIGOYOLxWHD7Y=; b=g9r8Fx/JRXz46/fowAYZ6nc42xKPkQ2q8GipbMJxyFLiqMRu3b362NSx+bWcvTSjpr WwqZU+ePo5PPCFx9/qV1v75JH4RpobreRdkVR3bGXYhHrRIEjTZ5Z3tBtpMJKY5b/r14 EJBF7Hs7Kg+SiAx2xR5KfzEoShFSsGwdw5ZeM= 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:content-transfer-encoding:x-gm-message-state; bh=pK5X1giK7JfriXsAgAM1aM8XXrr9KBQIGOYOLxWHD7Y=; b=BvzLNDBwxIRexgsFiIlKOiUViR+/7gIWSNTV/uU0LPOrZX03+NRn2+oDD2E/KkgEIp Lxx9VI4oGUXRSJLvHYZ1nBKg46NISLpD8O598Hc0OInA8JZBqqukPS3A5yUquEtjzDLa 1QfcMWLtskjRm3F95enmPoRYpFCoj+fk1nidyM0s5fA2QfmOYl76nuO0F5I3K8nPuir0 N4bWI2IRkhx4ilGiOcor9xzGNKOozKLRuYz5Q0u024trnj95yJoi6aifrS8b1zVepARj B6BMkoDDcJcowJJwrPiOviOfdL+GZV4bzP00gsvlUGorqipSn6bLA5WRfYIluzJfTUn0 caGA== MIME-Version: 1.0 Received: by 10.52.73.102 with SMTP id k6mr6841461vdv.57.1333555669909; Wed, 04 Apr 2012 09:07:49 -0700 (PDT) Received: by 10.220.180.199 with HTTP; Wed, 4 Apr 2012 09:07:49 -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> Date: Wed, 4 Apr 2012 09:07:49 -0700 Message-ID: From: Peter Wemm To: jb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnLHeDXdsIagh8hdzjnPCwJg6C9RM1nQIE7RvYDW6YsvmMcie8sjOR2Yw/uRBCffdrM3q50 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:07:50 -0000 On Wed, Apr 4, 2012 at 1:38 AM, jb wrote: > =A0 pobox.com> writes: > >> ... >> You can appeal to authority by saying the Gentoo Hardened developers sai= d >> such-and-such all you want, but it would be more useful for you to be ab= le >> to make specific technical arguments yourself. Saying "it could be a >> problem" or "in the wild there may be" isn't useful. A valid technical >> argument giving a mechanism for relocations to be exploited is all that >> is needed for you to prove your point. >> ... > > I have a question regarding security of FreeBSD kernel module loading and > relocation. > > According to KLDLOAD(8): > "...The kldload utility loads file.ko into the kernel using the kernel > =A0 =A0 linker. ..." > > So, kernel module is loaded: > # kldload /boot/kernel/foo.ko > > Here is my question: is foo.ko modified at this time ? Due to relocations= ? > > The reason I ask about it is this Gentoo Hardened FAQ item: > > http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml#paxnoelf > > "I keep getting the message: "error while loading shared libraries: canno= t make > segment writable for relocation: Permission denied." What does this mean?= " > > I understand this is about .so and does not apply directly to .ko . > > 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 o= rder > to change the address then unmarking it. This can be a problem as an atta= cker > could try to exploit a bug when the text relocation happens in order to b= e able > to write arbitrary code in the text segment which would be executed. > ..." > > Now, let me apply the above quoted paragraph to .ko and ask my question a= gain, > this time being more specific: > > are you doing any "marking" and "unmarking" of it at relocations and load= time, > thus creating an attack window opportunity ? In this particular case, no, there is no marking or unmarking. What happens is: kldload(2) syscall is performed with a pathname, in this case "/boot/kernel/foo.ko". The kernel locks the file. The kernel allocates a chunk of private, kernel-only data at a non deterministic address. The kernel *copies* the file from the file system into this allocated kernel-only memory. This isn't a mmap, its a read/memcpy type operation. The kernel unlocks the file. After the kernel has a private, non-shared copy of the file, it resolves outstanding symbols and relocations in its private, non-shared, non-user-accessible space. The kernel finally tells the user if the kldload() syscall was successful or not. ld.so is not involved, which is where those errors would come from. Nothing is shared, nothing is marked or unmarked. All of these operations happen outside of user visibility. We don't even have a way to report specific errors to the user, they're reported on the console. --=20 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