gmetad: stack based buffer overflow in interactive port

[Carlo Marcelo Arenas Belon]

a buffer overflow has been reported in the interactive port for gmetad (TCP/8652) which could result in code executed remotely or at least a DoS by crashing the gmetad daemon with a segfault and as can be seen in :

  http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=223

more information about this problem has been reported in :

  http://www.securityfocus.com/bid/33299
  http://secunia.com/advisories/33506

a CVE was already requested by the Red Hat security team as shown by :

  http://www.openwall.com/lists/oss-security/2009/01/15/3

[Tomas (tomas-redhat-bugs)]

A stack-based buffer overflow was discovered in the gmetad server, part of the ganglia monitoring system. Quoting original report:

  In process_path() a char element[256] is allocated to contain the pieces
  of the path as it is processed. If a request is made with a path element
  longer than that the strncpy call will write to invalid memory location,
  since there is no length checking performed on the input data to make sure
  it is less than the size of element.

Full report:
http://<email address hidden>/msg04929.html

Upstream bug:
  http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=223

Upstream fix:
  http://ganglia.svn.sourceforge.net/viewvc/ganglia?view=rev&revision=1946
and status file note:
  http://ganglia.svn.sourceforge.net/viewvc/ganglia?view=rev&revision=1947

[Kostas (kostas-redhat-bugs)]

Unfortunately the fix introduces an off by one error so it still needs work.

[Tomas (tomas-redhat-bugs)]

This overflow occurs in the strncpy call (which uses input length as a bound, not a destination buffer size) and it is detected by the FORTIFY_SOURCE. Therefore, this can no be exploited for code execution, overflow is detected before data are written past the end of the buffer and program execution is terminated. This is DoS-only flaw on Fedora or Red Hat HPC Solution.

[Arenas (arenas-redhat-bugs)]

could a CVE be requested by redhat's CNA to easy up tracking for all affected parties?, AFAIK there is a securityfocus BID already assigned in :

  http://www.securityfocus.com/bid/33299

[Tomas (tomas-redhat-bugs)]

We do not assign ids for already public issues, to minimize the risk of duplicating Mitre's assignments. Request for id was done couple of days ago via a list that is monitored by Mitre for new issues:
  http://www.openwall.com/lists/oss-security/2009/01/15/3

[Tomas (tomas-redhat-bugs)]

(In reply to comment #1)
> Unfortunately the fix introduces an off by one error so it still needs work.

Current version of the patch, including your fix for off-by-one:
http://ganglia.svn.sourceforge.net/viewvc/ganglia/trunk/monitor-core/gmetad/server.c?r1=1233&r2=1950

[Tomas (tomas-redhat-bugs)]

The patch was updated again upstream, fixing another off-by-one in the request[] buffer:
http://ganglia.svn.sourceforge.net/viewvc/ganglia?view=rev&revision=1953

Whole patch:
http://ganglia.svn.sourceforge.net/viewvc/ganglia/trunk/monitor-core/gmetad/server.c?r1=1233&r2=1953

[Fedora (fedora-redhat-bugs)]

ganglia-3.1.1-3.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/ganglia-3.1.1-3.fc10

[Fedora (fedora-redhat-bugs)]

ganglia-3.0.7-4.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/ganglia-3.0.7-4.fc9

[Tomas (tomas-redhat-bugs)]

CVE-2009-0241:
Stack-based buffer overflow in the process_path function in
gmetad/server.c in Ganglia 3.1.1 allows remote attackers to cause a
denial of service (crash) via a request to the gmetad service with a
long pathname.

[Arenas (arenas-redhat-bugs)]

Created attachment 329974
simplified patch to address buffer overflow in interactive port

already being used by the updated ganglia packages for Gentoo and Debian and proposed upstream in :

  http://bugzilla.ganglia.info/cgi-bin/bugzilla/attachment.cgi?id=189&action=view

including hunks from the committed fixes in trunk and that are relevant for this reported problem.

applies cleanly for 3.0.6, 3.0.7 (-30 lines offset) as well as 3.1.1

[Vincent (vincent-redhat-bugs)]

This has been corrected in upstream 3.1.2 (which is in current Fedora 11+), and this was also corrected in EPEL4 and 5 via:

* Tue Jan 20 2009 Kostas Georgiou <email address hidden> - 3.0.7
- New upstream release
- [480236] fix for a buffer overflow and an off-by-one bug in gmetad