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
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!
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.
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