Bug 468966 - Possible buffer overflow in cman config loader can lead to memory corruption
Possible buffer overflow in cman config loader can lead to memory corruption
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: cman (Show other bugs)
5.3
All Linux
medium Severity medium
: rc
: ---
Assigned To: Fabio Massimo Di Nitto
Cluster QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-29 04:47 EDT by Fabio Massimo Di Nitto
Modified: 2016-04-26 12:26 EDT (History)
6 users (show)

See Also:
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 07:08:29 EDT
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 Fabio Massimo Di Nitto 2008-10-29 04:47:41 EDT
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.
Comment 1 Fabio Massimo Di Nitto 2008-10-29 05:25:34 EDT
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
Comment 2 Fabio Massimo Di Nitto 2008-10-30 02:12:04 EDT
Fixes in STABLE2 branch with commit 5387db82a08b8d8bed5ab20226512816ef29b867
Comment 3 Fabio Massimo Di Nitto 2008-10-30 02:15:47 EDT
Fixed in RHEL5 branch with commit 469bdb2968d5be3029b916083ceadcb5d813c214
Comment 4 Fabio Massimo Di Nitto 2008-10-30 02:18:14 EDT
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.
Comment 5 Fedora Update System 2008-10-31 05:42:01 EDT
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
Comment 6 Fedora Update System 2008-11-06 21:55:45 EST
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.
Comment 7 Tomas Hoger 2009-04-01 04:35:23 EDT
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?
Comment 12 Fabio Massimo Di Nitto 2009-08-04 07:04:02 EDT
(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
Comment 13 Tomas Hoger 2009-08-04 10:13:31 EDT
(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!
Comment 14 Fabio Massimo Di Nitto 2009-08-04 10:18:35 EDT
(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 :)
Comment 15 Alasdair Kergon 2009-08-04 10:42:29 EDT
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.
Comment 17 errata-xmlrpc 2009-09-02 07:08:29 EDT
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

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