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.
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.
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.
Escalated to Bugzilla from IssueTracker
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.
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.