Bug 702687 (CVE-2011-1769)
| Summary: | CVE-2011-1769 systemtap: does not guard against DWARF operations div-by-zero errors, which can cause a kernel panic | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Vincent Danen <vdanen> | ||||
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> | ||||
| Status: | CLOSED ERRATA | QA Contact: | |||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | unspecified | CC: | bressers, fche, jistone, mjc, mjw, scox, security-response-team | ||||
| Target Milestone: | --- | Keywords: | Security | ||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | |||||||
| : | 840849 (view as bug list) | Environment: | |||||
| Last Closed: | 2012-02-03 20:47:39 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | 703977, 703978, 703979, 703980, 840849 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
|
Description
Vincent Danen
2011-05-06 15:19:24 UTC
Created attachment 497383 [details]
patch to correct the flaw
This patch corrects both divide by zero issues.
Also note that the doctored binary must already be running on the system, and that a privileged user would then have to be tricked into inspecting it in a particular way, in order to take advantage of this flaw. Adjusted the title a little to make clear this is a specific case of div-by-zero. Other user input is already checked for such issues. Great, thank you for that correction. The description of the flaw itself is fine? It's probably worth mentioning that the bug exists in processing the malevolent DWARF code in two script language constructs: stack unwinding (backtracing) and $context variable access, for that user-space binary. I'm trying to understand this issue. It seems there are two potential divide by zero conditions. We can group them in one CVE ID, as long as both affect the same versions of systemtap. Does the second testcase not work in RHEL5 becuase the issue isn't there, or some other reason? Also, for deciding on severity, could a regular user who is able to run sysytemtap write a script capable of crashing the machine? If they can, this is probably a low severity issue since it would then require a malicious user to trick someone into inspecting a binary in a specific way (which is unlikely). However, if non root systemtap users cannot crash a machine, but this lets them, it's slightly more severe (but still only moderate severity since you shouldn't give systemtap access to untrusted users). Mark, the privileges question was not about what an already-root-equivalent
person can do. root or stapdev can already crash the machine deliberately.
The problem arises from root|stapdev being fooled into operating a particular
way upon a corrupted binary, OR from a stapusr ("unprivileged") user doing so.
OK, here is where things currently stand. Due to unprivileged mode, we will rate this flaw as moderate. Without unprivileged mode enabled, this flaw doesn't cross any trust boundary. If an admin has enabled unprivileged mode though, a normal user could use this to crash the target machine. We will also want to split this to be two CVE ids. The two issues are stack unwinding (backtracing) and $context variable access. Let's use CVE-2011-1769 for the $context variable access. This affects versions of systemtap as shipped in Red Hat Enterprise Linux 5 and 6. The stack unwinding flaw only affects systemtap versions 1.4 and above. It is CVE-2011-1781. Fixed upstream: http://sourceware.org/git/?p=systemtap.git;a=commit;h=fa2e3415185a28542d419a641ecd6cddd52e3cd9 Public now via upstream commit mentioned in the previous comment. This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2011:0842 https://rhn.redhat.com/errata/RHSA-2011-0842.html This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2011:0841 https://rhn.redhat.com/errata/RHSA-2011-0841.html |