Bug 480960 - (CVE-2009-0242) CVE-2009-0242 ganglia: gmetad temporary DoS via resource consumption
CVE-2009-0242 ganglia: gmetad temporary DoS via resource consumption
Status: CLOSED NOTABUG
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
http://nvd.nist.gov/nvd.cfm?cvename=C...
source=fedora,reported=20090115,publi...
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-21 10:16 EST by Tomas Hoger
Modified: 2015-02-16 10:43 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-05 03:57:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tomas Hoger 2009-01-21 10:16:26 EST
Common Vulnerabilities and Exposures assigned an identifier CVE-2009-0242 to the following vulnerability:

Ganglia 3.1.1 allows remote attackers to cause a denial of service via
a request to the gmetad service with a path does not exist, which
causes Ganglia to (1) perform excessive CPU computation and (2) send
the entire tree, which consumes network bandwidth.

References:
http://www.mail-archive.com/ganglia-developers@lists.sourceforge.net/msg04929.html
Comment 1 Tomas Hoger 2009-01-21 10:57:21 EST
This issue is related to the one tracked via bug #480236, though it's not clear to me whether this actually is an issue.  The assignment was made based on the DoS part of the original report:
  http://www.openwall.com/lists/oss-security/2009/01/21/4

Part of the patch that should take care of that DoS should be:

@@ -600,8 +606,8 @@
                if (process_request(&client, request))
                   {
                      err_msg("Got a malformed path request from %s", remote_ip);
-                     /* Send them the entire tree to discourage attacks. */
-                     strcpy(request, "/");
+                     close(client.fd);
+                     continue;
                   }
             }
          else

Now let's see how we can get process_request to return 1.  There are few possibilities:
- path can be empty
- path does not start with '/'
- path contains certain prohibited characters
- there is some invalid filter specified

The consequence of the process_request returning 1 is that request (aka path) is set to "/".  With that in mind, only the first case need to be considered, as it's the only case when attacker's invalid input is shorter than the valid input that would have the same end result (at an attacker can always specify valid path "/" to get data for the whole tree).  So it seems there no issue for gmetad versions that do not process multiple paths in one request.

It can be little more interesting in the case when the multiple request patch is used.  Reporter claims the worst case is you get ~ 2048/3 times data for the whole tree "/x:/x:/x:...".  Though it seems to be possible to get even more using valid paths - "/:/:/:/:..." - i.e. ~ 2048/2.  Proposed multi item request patch does not seem to make this any worse, as it skips all empty paths.

So it seems there's no real issue here, as the same affect can be achieved using valid requests with valid paths.  Can anyone more familiar with ganglia check and confirm this?  Or test on an existing real configuration?  Thanks!
Comment 2 Kostas Georgiou 2009-01-21 18:22:49 EST
I don't really see an issue here, you can get the full tree anyway without sending anything with a connection to the non interactive port (8651). I would say that the patch is there more to make sure that a buggy client doesn't end up unnecessarily downloading extra data than to prevent a remote DoS.

By default both ports only accept connections from localhost btw.
Comment 3 Josh Bressers 2009-01-22 15:16:08 EST
This is not a security issue.

I have created an NVD statement for this issue:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-0242

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