Bug 702687 (CVE-2011-1769) - CVE-2011-1769 systemtap: does not guard against DWARF operations div-by-zero errors, which can cause a kernel panic
Summary: CVE-2011-1769 systemtap: does not guard against DWARF operations div-by-zero ...
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2011-1769
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 703977 703978 703979 703980 840849
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-05-06 15:19 UTC by Vincent Danen
Modified: 2019-09-29 12:44 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 840849 (view as bug list)
Environment:
Last Closed: 2012-02-03 20:47:39 UTC


Attachments (Terms of Use)
patch to correct the flaw (3.91 KB, patch)
2011-05-06 15:24 UTC, Vincent Danen
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2011:0841 normal SHIPPED_LIVE Moderate: systemtap security update 2011-05-31 14:31:47 UTC
Red Hat Product Errata RHSA-2011:0842 normal SHIPPED_LIVE Moderate: systemtap security update 2011-05-31 14:04:42 UTC

Description Vincent Danen 2011-05-06 15:19:24 UTC
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 (panic_on_oops), 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.

Comment 1 Vincent Danen 2011-05-06 15:24:45 UTC
Created attachment 497383 [details]
patch to correct the flaw

This patch corrects both divide by zero issues.

Comment 3 Vincent Danen 2011-05-06 15:59:32 UTC
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.

Comment 4 Mark Wielaard 2011-05-06 18:26:02 UTC
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.

Comment 5 Vincent Danen 2011-05-06 20:34:50 UTC
Great, thank you for that correction.  The description of the flaw itself is fine?

Comment 6 Frank Ch. Eigler 2011-05-06 21:35:19 UTC
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.

Comment 25 Josh Bressers 2011-05-10 17:39:27 UTC
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).

Comment 28 Frank Ch. Eigler 2011-05-10 18:33:08 UTC
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.

Comment 29 Josh Bressers 2011-05-11 19:21:52 UTC
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.

Comment 32 Tomas Hoger 2011-05-20 11:53:27 UTC
Public now via upstream commit mentioned in the previous comment.

Comment 33 errata-xmlrpc 2011-05-31 14:04:48 UTC
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

Comment 34 errata-xmlrpc 2011-05-31 14:31:53 UTC
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


Note You need to log in before you can comment on or make changes to this bug.