Hello Release Team, systemtap introduced an RC bug yesterday. These are CVE vulnerabilities. Please see the attached debdiff. I will wait for your confirmation before I do the upload.
Ritesh -------- Original Message -------- Subject: Bug#603946: CVE-2010-4170 and CVE-2010-4171 Resent-Date: Thu, 18 Nov 2010 18:42:02 +0000, Thu, 18 Nov 2010 18:42:04 +0000 Resent-From: Moritz Muehlenhoff <[email protected]> Resent-To: [email protected] Resent-CC: [email protected], [email protected], Ritesh Raj Sarraf <[email protected]> Date: Thu, 18 Nov 2010 19:39:00 +0100 From: Moritz Muehlenhoff <[email protected]> Reply-To: Moritz Muehlenhoff <[email protected]>, [email protected] To: Debian Bug Tracking System <[email protected]> Package: systemtap Severity: grave Tags: security Two security issues have been found in systemtap, one of them allowing local privilege escalation: http://sources.redhat.com/ml/systemtap/2010-q4/msg00230.html These are CVE-2010-4170 and CVE-2010-4171. Fix: http://sources.redhat.com/git/gitweb.cgi?p=systemtap.git;a=commit;h=b7565b41228bea196cefa3a7d43ab67f8f9152e2 Cheers, Moritz -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=C, lc_ctype=de_de.iso-8859...@euro (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages systemtap depends on: ii libc6 2.11.2-6 Embedded GNU C Library: Shared lib ii libelf1 0.148-1 library to read and write ELF file ii libgcc1 1:4.4.5-3 GCC support library ii libsqlite3-0 3.7.2-1 SQLite 3 shared library ii libstdc++6 4.4.5-3 The GNU Standard C++ Library v3 pn systemtap-runtime <none> (no description available) systemtap recommends no packages. Versions of packages systemtap suggests: pn systemtap-doc <none> (no description available) pn vim-addon-manager <none> (no description available)
diff -Nru systemtap-1.2/debian/changelog systemtap-1.2/debian/changelog --- systemtap-1.2/debian/changelog 2010-09-29 23:21:31.000000000 +0530 +++ systemtap-1.2/debian/changelog 2010-11-19 19:09:53.000000000 +0530 @@ -1,3 +1,11 @@ +systemtap (1.2-3) unstable; urgency=high + + * Fix CVE Vulnerability: CVE-2010-4170, CVE-2010-4171 + staprun module loading/unloading security fixes + (Closes: #603946) + + -- Ritesh Raj Sarraf <[email protected]> Fri, 19 Nov 2010 18:47:21 +0530 + systemtap (1.2-2) unstable; urgency=low * Update README.Debian about kernel dependency diff -Nru systemtap-1.2/debian/NEWS systemtap-1.2/debian/NEWS --- systemtap-1.2/debian/NEWS 2010-09-29 23:21:31.000000000 +0530 +++ systemtap-1.2/debian/NEWS 2010-11-19 19:09:53.000000000 +0530 @@ -1,3 +1,13 @@ +systemtap (1.2-3) unstable; urgency=high + + This release fixes security vulnerabilities in SystemTap + (CVE-2010-4170, CVE-2010-4171) + There is a change is the runtime behavior of SystemTap. All users + that are currently part of 'stapdev' group would also have to be added + to the 'stapusr' (limited-privilege powers) group. + + -- Ritesh Raj Sarraf <[email protected]> Fri, 19 Nov 2010 19:09:21 +0530 + systemtap (0.9.9+0git20090910-1) experimental; urgency=low This release supports execution of precompiled and signed probe modules diff -Nru systemtap-1.2/debian/patches/debian-changes-1.2-3 systemtap-1.2/debian/patches/debian-changes-1.2-3 --- systemtap-1.2/debian/patches/debian-changes-1.2-3 1970-01-01 05:30:00.000000000 +0530 +++ systemtap-1.2/debian/patches/debian-changes-1.2-3 2010-11-19 19:16:33.000000000 +0530 @@ -0,0 +1,161 @@ +Description: Upstream changes introduced in version 1.2-3 + This patch has been created by dpkg-source during the package build. + Here's the last changelog entry, hopefully it gives details on why + those changes were made: + . + systemtap (1.2-3) unstable; urgency=high + . + * Fix CVE Vulnerability: CVE-2010-4170, CVE-2010-4171 + staprun module loading/unloading security fixes + (Closes: #603946) + . + The person named in the Author field signed this changelog entry. +Author: Ritesh Raj Sarraf <[email protected]> +Bug-Debian: http://bugs.debian.org/603946 + +--- +The information above should follow the Patch Tagging Guidelines, please +checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here +are templates for supplementary fields that you might want to add: + +Origin: <vendor|upstream|other>, <url of original patch> +Bug: <url in upstream bugtracker> +Bug-Debian: http://bugs.debian.org/<bugnumber> +Bug-Ubuntu: https://launchpad.net/bugs/<bugnumber> +Forwarded: <no|not-needed|url proving that it has been forwarded> +Reviewed-By: <name and email of someone who approved the patch> +Last-Update: <YYYY-MM-DD> + +--- systemtap-1.2.orig/staprun.8.in ++++ systemtap-1.2/staprun.8.in +@@ -198,13 +198,13 @@ structures and potentially private user + manual page for additional information on safety and security. + .PP + To increase system security, only the root user and members of the +-.I stapdev +-group can use ++.I stapdev " and " staprun ++groups can use + .I staprun + to insert systemtap modules (or attach to existing ones). + Members of the + .I stapusr +-group can use ++groups can use + .I staprun + to insert or remove systemtap modules (or attach to existing systemtap modules) + under the following conditions: +--- systemtap-1.2.orig/Makefile.am ++++ systemtap-1.2/Makefile.am +@@ -172,7 +172,10 @@ stapio_LDADD = -lpthread + + + install-exec-hook: +- if [ `id -u` -eq 0 ]; then chmod 04111 "$(DESTDIR)$(bindir)/staprun"; fi ++ if [ `id -u` -eq 0 ]; then \ ++ getent group stapusr >/dev/null && chgrp stapusr "$(DESTDIR)$(bindir)/staprun"; \ ++ chmod 04110 "$(DESTDIR)$(bindir)/staprun"; \ ++ fi + + # Why the "id -u" condition? This way, an unprivileged user can run + # make install, and have "sudo stap ...." or "sudo staprun ...." work later. +--- systemtap-1.2.orig/Makefile.in ++++ systemtap-1.2/Makefile.in +@@ -1991,7 +1991,10 @@ cscope: + @BUILD_ELFUTILS_TRUE@@build_translator_t...@install-exec-local: install-elfutils + + install-exec-hook: +- if [ `id -u` -eq 0 ]; then chmod 04111 "$(DESTDIR)$(bindir)/staprun"; fi ++ if [ `id -u` -eq 0 ]; then \ ++ getent group stapusr >/dev/null && chgrp stapusr "$(DESTDIR)$(bindir)/staprun"; \ ++ chmod 04110 "$(DESTDIR)$(bindir)/staprun"; \ ++ fi + + @build_crashmod_t...@$(STAPLOG): staplog.c + @BUILD_CRASHMOD_TRUE@ $(CC) $(staplog_CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -shared -rdynamic \ +--- systemtap-1.2.orig/README.security ++++ systemtap-1.2/README.security +@@ -15,7 +15,7 @@ following: + + * the root user; + +- * a member of the 'stapdev' group; or ++ * a member of both 'stapdev' and 'stapusr' groups; or + + * a member of the 'stapusr' group. Members of the stapusr group can + only use modules located in the /lib/modules/VERSION/systemtap +@@ -23,8 +23,8 @@ following: + directory must be owned by root and not be world writable. + + So, there are two classes of users: systemtap developers (the root user +-and members of the stapdev group) and systemtap users (members of the +-stapusr group). Systemtap developers can compile and run any ++and members of the stapdev/stapusr groups) and systemtap users (members of ++only the stapusr group). Systemtap developers can compile and run any + systemtap script. Systemtap users can only run "approved" + pre-compiled modules located in /lib/modules/VERSION/systemtap. + +--- systemtap-1.2.orig/runtime/staprun/ctl.c ++++ systemtap-1.2/runtime/staprun/ctl.c +@@ -27,6 +27,9 @@ int init_ctl_channel(const char *name, i + return -2; + } + ++ if (access(buf, R_OK|W_OK) != 0) ++ return -5; ++ + control_channel = open(buf, O_RDWR); + dbug(2, "Opened %s (%d)\n", buf, control_channel); + if (control_channel < 0) { +--- systemtap-1.2.orig/runtime/staprun/staprun.c ++++ systemtap-1.2/runtime/staprun/staprun.c +@@ -115,19 +115,7 @@ static int enable_uprobes(void) + if (run_as(0, uid, gid, argv[0], argv) == 0) + return 0; + +- /* +- * TODO: If user can't setresuid to root here, staprun will exit. +- * Is there a situation where that would fail but the subsequent +- * attempt to insert_module() would succeed? +- */ +- dbug(2, "Inserting uprobes module from /lib/modules, if any.\n"); +- i = 0; +- argv[i++] = "/sbin/modprobe"; +- argv[i++] = "-q"; +- argv[i++] = "uprobes"; +- argv[i] = NULL; +- if (run_as(0, 0, 0, argv[0], argv) == 0) +- return 0; ++ /* NB: don't use /sbin/modprobe, without more env. sanitation. */ + + /* This module may be signed, so use insert_module to load it. */ + snprintf (runtimeko, sizeof(runtimeko), "%s/uprobes/uprobes.ko", +@@ -186,9 +174,16 @@ static int remove_module(const char *nam + return 0; + } + +- /* We could call init_ctl_channel / close_ctl_channel here, as a heuristic +- to determine whether the module is being used by some other stapio process. +- However, delete_module() does basically the same thing. */ ++ /* We call init_ctl_channel/close_ctl_channel to check whether ++ the module is a systemtap-built one (having the right files), ++ and that it's already unattached (because otherwise it'd EBUSY ++ the opens. */ ++ ret = init_ctl_channel (name, 0); ++ if (ret < 0) { ++ err("Error, '%s' is not a zombie systemtap module.\n", name); ++ return ret; ++ } ++ close_ctl_channel (); + + dbug(2, "removing module %s\n", name); + STAP_PROBE1(staprun, remove__module, name); +@@ -223,7 +218,7 @@ int init_staprun(void) + without first removing the kernel module. This would block + a subsequent rerun attempt. So here we gingerly try to + unload it first. */ +- int ret = delete_module (modname, O_NONBLOCK); ++ int ret = remove_module (modname, 0); + err("Retrying, after attempted removal of module %s (rc %d)\n", modname, ret); + /* Then we try an insert a second time. */ + if (insert_stap_module() < 0) diff -Nru systemtap-1.2/debian/patches/series systemtap-1.2/debian/patches/series --- systemtap-1.2/debian/patches/series 2010-09-29 23:21:31.000000000 +0530 +++ systemtap-1.2/debian/patches/series 2010-11-19 19:10:38.000000000 +0530 @@ -7,3 +7,4 @@ new-elfutils.diff grapher-libs.diff debversion.diff +debian-changes-1.2-3
signature.asc
Description: OpenPGP digital signature
