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
This is CVE-2009-4273.
systemtap-1.1-1.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/systemtap-1.1-1.fc11
systemtap-1.1-1.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/systemtap-1.1-1.fc12
systemtap-1.1-1.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
systemtap-1.1-1.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
systemtap 0.6.2 in EL4 does not have server functionality at all and as a result is unaffected by this issue.
We have identified a few additional cases where the fix above is not sufficient. We are working on a workaround that involves only changes to configuration files (rather than compiled code). Shall we handle this with a whole separate advisory or an update to this one?
Ok, but this doesn't make the CVE-2009-4273 fix incomplete, right? Since this is not due to unsanitized input in a shell script, but rather due to an issue with the Makefile (or how make is run?). This would probably be considered a separate flaw and would need another CVE if I'm understanding this correctly. So I wouldn't say the original fix was incomplete, but rather that this is a separate, yet similar, issue (am I correct in assuming that if you fixed this, but _not_ this original issue, that the original issue would still exist? Or would fixing this _also_ fix the original issue? That distinction is probably what would decide whether this is a separate CVE or not).
The 'make' invocation we are talking about is done via the chain stap-server -> stap -> make, at the server at run time. This is not the 'make' of the software itself, but again, a 'make' invoked at run time, as a consequence of how systemtap works. For the original issue, we secured only the first link (stap-server -> stap) to avoid unintentional eval's. However, this second link (stap -> make) also exists, and make is all too happy to eval just about anything, so we need to sanitize its inputs too. So yes, it is another instance of the original issue.
I've assigned CVE-2010-0412 for the "incomplete fix of CVE-2009-4273". For reference, we do not need to refer to CVE-2010-0412 in our advisories since we have not updated systemtap with the incomplete fix.
The tentative additional fixes for this problem are here: http://sourceware.org/git/?p=systemtap.git;a=commit;h=c0d1b5a00 http://sourceware.org/git/?p=systemtap.git;a=commit;h=cc9e5488d
CVE-2010-0412 has been assigned for the "incomplete fix of CVE-2009-4273". MITRE unfortunately classified it differently: 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. They picked this up from Fedora commits which, unfortunately, did not indicate that this isn't a new issue, but that the fix for CVE-2009-4273 was incomplete.
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2010:0124 https://rhn.redhat.com/errata/RHSA-2010-0124.html