Systemtap » Systemtap : Security Vulnerabilities, CVEs,

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 MODPROBE_OPTIONS environment variable to specify a malicious configuration file.

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.

The insert_module function in runtime/staprun/staprun_funcs.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.

runtime/staprun/staprun_funcs.c in the systemtap runtime tool (staprun) in SystemTap before 1.6 does not properly validate modules when a module path is specified by a user for user-space probing, which allows local users in the stapusr group to gain privileges via a crafted module in the search path in the -u argument.

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.4 and earlier, 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 context variable access.

The staprun runtime tool in SystemTap 1.3 does not verify that a module to unload was previously loaded by SystemTap, which allows local users to cause a denial of service (unloading of arbitrary kernel modules).

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.

Multiple integer signedness errors in the (1) __get_argv and (2) __get_compat_argv functions in tapset/aux_syscalls.stp in SystemTap 1.1 allow local users to cause a denial of service (script crash, or system crash or hang) via a process with a large number of arguments, leading to a buffer overflow.

stap-server in SystemTap before 1.1 allows remote attackers to execute arbitrary commands via shell metacharacters in stap command-line arguments in a request.

SystemTap 1.0, when the --unprivileged option is used, does not properly restrict certain data sizes, which allows local users to (1) cause a denial of service or gain privileges via a print operation with a large number of arguments that trigger a kernel stack overflow, (2) cause a denial of service via crafted DWARF expressions that trigger a kernel stack frame overflow, or (3) cause a denial of service (infinite loop) via vectors that trigger creation of large unwind tables, related to Common Information Entry (CIE) and Call Frame Instruction (CFI) records.

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.