From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30605 invoked by alias); 25 Jul 2011 15:49:40 -0000 Received: (qmail 30577 invoked by uid 426); 25 Jul 2011 15:49:40 -0000 Date: Mon, 25 Jul 2011 15:49:00 -0000 Message-ID: <20110725154940.30566.qmail@sourceware.org> From: fche@sourceware.org To: systemtap-cvs@sourceware.org Subject: [SCM] systemtap: system-wide probe/trace tool branch, master, updated. release-1.5-183-ged51cfa X-Git-Refname: refs/heads/master X-Git-Reftype: branch X-Git-Oldrev: 57fd81522e119db3ccaeacd54e4d518c8ca01a60 X-Git-Newrev: ed51cfa24ca27746ab09b59280b94117dd58cba3 Mailing-List: contact systemtap-cvs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-cvs-owner@sourceware.org List-Archive: Reply-To: systemtap@sourceware.org X-SW-Source: 2011-q3/txt/msg00091.txt.bz2 This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "systemtap: system-wide probe/trace tool". The branch, master has been updated via ed51cfa24ca27746ab09b59280b94117dd58cba3 (commit) via 4ecaadf545a729bb3e5f01f6f019716d49815d9a (commit) from 57fd81522e119db3ccaeacd54e4d518c8ca01a60 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit ed51cfa24ca27746ab09b59280b94117dd58cba3 Author: Josh Stone Date: Mon Jul 25 11:48:31 2011 -0400 CVE-2011-2503: read instead of mmap to load modules As staprun is preparing to load a kernel module, we first mmap the whole module as MAP_PRIVATE. Then we proceed with our security checks, including a trusted-signature validation on the mapped region, and if all checks out, we'll call init_module() with that same mapped region. However, MMAP(2) says of MAP_PRIVATE, "It is unspecified whether changes made to the file after the mmap() call are visible in the mapped region." From my testing, it appears that file changes do indeed show up in our mapped memory. This means we have a TOCTOU race between verifying the signature of that memory and then calling init_module(). By using read() instead of mmap(), we ensure that we have a fully private copy of the module to verify and load, without fear of change. commit 4ecaadf545a729bb3e5f01f6f019716d49815d9a Author: Josh Stone Date: Mon Jul 25 09:54:28 2011 -0400 CVE-2011-2502: Don't allow path-based auth for uprobes For users that are only members of stapusr, and not stapdev, we only allow loading modules that are either signed with a trusted certificate or located in controlled paths. For the script itself, that path is /lib/modules/.../systemtap/, and for uprobes it is the runtime. When this policy was first written, uprobes only ever came from the runtime path, so the path check just returned 1 always. Later, commit 474d17ad added an optional argument to staprun -u, to allow the user to specify their own signed copy of uprobes to load. Unfortunately, if presented with an unsigned module, that would still fall back to the path check, which blissfully approved it anyway. Our policy is now that stapusr can only load a signed uprobes.ko, so the path check for uprobes now unconditionally returns 0. ----------------------------------------------------------------------- Summary of changes: runtime/staprun/staprun_funcs.c | 54 +++++++++++++++++++++++++++----------- 1 files changed, 38 insertions(+), 16 deletions(-) hooks/post-receive -- systemtap: system-wide probe/trace tool