Bug 468966
| Summary: | Possible buffer overflow in cman config loader can lead to memory corruption | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Fabio Massimo Di Nitto <fdinitto> |
| Component: | cman | Assignee: | Fabio Massimo Di Nitto <fdinitto> |
| Status: | CLOSED ERRATA | QA Contact: | Cluster QE <mspqa-list> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 5.3 | CC: | agk, ccaulfie, cfeist, cluster-maint, edamato, rlerch |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | cman-2.0.100-1.el5 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-09-02 11:08:29 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Fabio Massimo Di Nitto
2008-10-29 08:47:41 UTC
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 |