Description of problem: a static array (with max 52 entries) is used during config load operations to store data. It is possible to overflow this buffer and corrupt memory (it's not possible to exploit it for code execution). Version-Release number of selected component (if applicable): all versions of RHEL5 are affected How reproducible: always Steps to Reproduce: 1. create a "big" cluster.conf: <cluster> .. standard cluster conf stuff here .. <junk> <extrajunk foo="bar"/> <- repeat this line 60 times for example (as long as it's more than 53) </junk> </cluster> 2. fire up ccsd (this will work just fine) 3. cman_tool -d join Actual results: openais/cman will start spinning 100% of the CPU. gdb bt will show that the system is haning on libxml operations because libxml is trying to parse what might be invalid data. Expected results: should work just fine. Additional info: this has been fixed already in cluster.git master branch: http://git.fedorahosted.org/git/cluster.git?p=cluster.git;a=commitdiff;h=67fee9128e54c6c3fc3eae306b5b501f3029c3be It needs backporting to RHEL5 branch as the file name has changed.
Just a small correction from the test case: in order to have a visible effect on RHEL5, the <junk> entry needs to be within a <cman> block (others are affected too) and the config file big enough to show that's overflowing memory. Fabio
Fixes in STABLE2 branch with commit 5387db82a08b8d8bed5ab20226512816ef29b867
Fixed in RHEL5 branch with commit 469bdb2968d5be3029b916083ceadcb5d813c214
Extrainfo: RHEL4 branch doesn't seem to be affected. Actual results from main descrition is not accurate: openais/cman will start spinning 100% of the CPU. gdb bt will show that the system is haning on libxml operations since libxml is exponentially slow on large XML blocks. The data returned from libxml will slowly overflow the memory. It takes sometime (often a lot of seconds and more than cman_tool join timeout) to notice the overflow in cman.
rgmanager-2.03.09-1.fc9,gfs2-utils-2.03.09-1.fc9,cman-2.03.09-1.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/rgmanager-2.03.09-1.fc9,gfs2-utils-2.03.09-1.fc9,cman-2.03.09-1.fc9
rgmanager-2.03.09-1.fc9, gfs2-utils-2.03.09-1.fc9, cman-2.03.09-1.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
CVE id CVE-2008-6560 was assigned to this bug by Mitre: Buffer overflow in CMAN - The Cluster Manager before 2.03.09-1 on Fedora 9 and Red Hat Enterprise Linux (RHEL) 5 allows attackers to cause a denial of service (CPU consumption and memory corruption) via a cluster.conf file with many lines. NOTE: it is not clear whether this issue crosses privilege boundaries in realistic uses of the product. The assignment seem to have been made because of this Fedora update: https://admin.fedoraproject.org/updates/F9/FEDORA-2008-9458 This was tagged as security, as it was fixing few temporary file handling issues. Unless I'm mistaken, this bug should be regular bug fix, not a security fix, as cluster.conf is admin-controlled, so no trust boundary is crossed when this bug is exploited. Or is there any reasonable use case where cluster.conf may be edited by non-admins?
(In reply to comment #7) > Unless I'm mistaken, this bug should be regular bug fix, not a > security fix, as cluster.conf is admin-controlled, so no trust boundary is > crossed when this bug is exploited. Or is there any reasonable use case where > cluster.conf may be edited by non-admins? Well it really depends on what is considered admins or non-admins. I don't want to go all philosophical but there are automated tools (GUI, scripts etc) that can interact with cluster.conf to update sections and so on. In theory cluster.conf should owned by root:root by default. The configuration loader does not check who owns the file at read time. So in theory a less careful sysadmin could have a root:clusteradmin cluster.conf where one of the clusteradmin accounts has been compromised etc. I personally don't have strong objections to pass this specific patch as bug fix but I am not enough of a security expert to draw the line above. So I am OK with whatever call you want to make. Fabio
(In reply to comment #12) > In theory cluster.conf should owned by root:root by default. The configuration > loader does not check who owns the file at read time. So in theory a less > careful sysadmin could have a root:clusteradmin cluster.conf where one of the > clusteradmin accounts has been compromised etc. For clusteradmin case, there's still assumption that attacker needs to get (cluster)admin account, and hence (cluster)admin privileges. So this does not qualify as security flaw. Thank you, Fabio!
(In reply to comment #13) > (In reply to comment #12) > > In theory cluster.conf should owned by root:root by default. The configuration > > loader does not check who owns the file at read time. So in theory a less > > careful sysadmin could have a root:clusteradmin cluster.conf where one of the > > clusteradmin accounts has been compromised etc. > > For clusteradmin case, there's still assumption that attacker needs to get > (cluster)admin account, and hence (cluster)admin privileges. So this does not > qualify as security flaw. Thank you, Fabio! clusteradmin might be an unprivileged account tho. Anyway.. I am happy with whatever you decide :)
Agree with comment #13 - not security: cluster.conf is a system configuration file only meant to be editable by a sysadmin, not an untrusted user of the machine.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2009-1341.html