Race condition in the SystemTap stap tool 0.0.20080705 and 0.0.20090314 allows local users in the stapusr group to insert arbitrary SystemTap kernel modules and gain privileges via unknown vectors.

A flaw was found in the "stap-server" network compilation server, an optional part of systemtap. Part of the server is written in bash and does not adequately sanitize its inputs, which are essentially full command line parameter sets from a client. Remote users may be able to abuse quoting/spacing/metacharacters to execute shell code on behalf of the compile server process/user (normally a fully unprivileged synthetic userid).

There is currently no fix available. To work-around this issue, avoid running the stap-server program on a network with untrusted users.

[1] http://sourceware.org/PR11105

stap-server in SystemTap 1.1 does not properly restrict the value of the -B (aka BUILD) option, which allows attackers to have an unspecified impact via vectors associated with executing the make program, a different vulnerability than CVE-2009-4273.

Escalated to Bugzilla from IssueTracker

The insertmodule function in runtime/staprun/staprunfuncs.c in the systemtap runtime tool (staprun) in SystemTap before 1.6 does not properly validate a module when loading it, which allows local users to gain privileges via a race condition between the signature validation and the module initialization.

It was found that systemtap runtime tool (staprun) did not properly enforce the module's path sanity check, when the ad-hoc module instrumentation via user-space probing with user-specified module path was requested. A local user, member of the 'stapusr' group could use this flaw to escalate their privileges.

Multiple denial of service flaws were found in the SystemTap instrumentation system, when the --unprivileged mode was activated:

a, Kernel stack overflow allows local attackers to cause denial of service or execute arbitrary code via long number of parameters, provided to the print call.

b, Kernel stack frame overflow allows local attackers to cause denial of service via specially-crafted user-provided DWARF information.

c, Absent check(s) for the upper bound of the size of the unwind table and for the upper bound of the size of each of the CIE/CFI records, could allow an attacker to cause a denial of service (infinite loop).

References: ----------- http://sources.redhat.com/bugzilla/showbug.cgi?id=10750 http://gcc.gnu.org/bugzilla/showbug.cgi?id=41633

Issue severity note: -------------------- The --unprivileged mode needs to be activated by the privileged user prior the unprivileged user could exploit these flaws.

SystemTap 1.0 in the default configuration is not shipped with the --unprivileged mode activated, this is NOT vulnerable to these flaws.

Information about vulnerable versions: -------------------------------------- These issues do NOT affect the versions of SystemTap instrumentation system, as shipped with Red Hat Enterprise Linux 4 and 5.

These issues affect the versions of SystemTap instrumentation system, as shipped with Fedora releases of 10 and 11. See also above severity note.

The staprun runtime tool in SystemTap 1.3 does not properly clear the environment before executing modprobe, which allows local users to gain privileges by setting the MODPROBEOPTIONS environment variable to specify a malicious configuration file.

A security flaw was found in the way systemtap runtime tool (staprun) removed unused modules. A local attacker could use this flaw to conduct various denial of service attacks.

References: [1] http://sources.redhat.com/ml/systemtap/2010-q4/msg00230.html

Upstream changeset: [2] http://sources.redhat.com/git/gitweb.cgi?p=systemtap.git;a=commit;h=b7565b41228bea196cefa3a7d43ab67f8f9152e2

Acknowledgements:

Red Hat would like to thank Tavis Ormandy for reporting this issue.

A flaw was discovered in systemtap's handling of DWARF expressions where it did not guard against two cases of divide by zero. This can result in a kernel div-by-zero message and possible busywait during stap module shutdown. A div-by-zero could cause the kernel to panic and if the kernel reboot on panic flag was set (paniconoops), it would cause the system to reboot.

In order to trigger this flaw, it would require a user with staprun or stapdev group membership (or root privileges) to run a particular stap script operation on a hand-corrupted elf program.

SystemTap 1.4, when unprivileged (aka stapusr) mode is enabled, allows local users to cause a denial of service (divide-by-zero error and OOPS) via a crafted ELF program with DWARF expressions that are not properly handled by a stap script that performs stack unwinding (aka backtracing).

SystemTap 1.7, 1.6.7, and probably other versions, when unprivileged mode is enabled, allows local users to obtain sensitive information from kernel memory or cause a denial of service (kernel panic and crash) via vectors related to crafted DWARF data, which triggers a read of an invalid pointer.

A flaw was discovered in systemtap's handling of DWARF expressions where it did not guard against two cases of divide by zero. This can result in a kernel div-by-zero message and possible busywait during stap module shutdown. A div-by-zero could cause the kernel to panic and if the kernel reboot on panic flag was set (paniconoops), it would cause the system to reboot.

In order to trigger this flaw, it would require a user with staprun or stapdev group membership (or root privileges) to run a particular stap script operation on a hand-corrupted elf program.