|
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 --------
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-15@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 <rrs@debian.org> 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 <rrs@debian.org> 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 <rrs@debian.org>
+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_TRUE@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_TRUE@$(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
Attachment:
signature.asc
Description: OpenPGP digital signature