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 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.
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).
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.
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.
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.