Deutsche Telekom CERT Advisory DTC-A-20140820-001 notes a number of security flaws have been fixed in check-mk (a Nagios plug-in) versions 1.2.4p4 and 1.2.5i4. These include cross site scripting to remote code execution (due to insecure pickle() use). Further details are available from their advisory: http://packetstormsecurity.com/files/127941/DTC-A-20140820-001.txt Some (not all!) of the individual fixes: CVE-2014-5338 http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=4b71709456bfc2ffc27a3583f13cc2ac0e726709 CVE-2014-5339 http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=7998aa4d53d2fef7302c0761b9c8f47e2f626e18 CVE-2014-5340 http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=192d41525502dc8de10ac99f57bd988450c17566
Created check-mk tracking bugs for this issue: Affects: fedora-all [bug 1132339] Affects: epel-all [bug 1132341]
> CVE-2014-5340 > http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit; > h=192d41525502dc8de10ac99f57bd988450c17566 That commit notes: <b>Note:</b> This change makes the current Check_MK versions incompatible to older versions. In a mixed environment with old and new Check_MK versions or with old and newer Python versions you have to force WATO to use the old unsafe method by setting <tt>wato_legacy_eval = True<tt> in <tt>multisite.mk</tt>. This can also be done with the new global WATO setting <i>Use unsafe legacy encoding for distributed WATO</i>.
Murray I'm a bit concerned about comment #2 as the multisite.mk file is actually modified by admins in many occasions and overwriting it definitely not a good solution but at the same time upgrading the package without 'wato_legacy_eval' flag set to true will result in WATO breakages. Do you have any suggestion on how to handle the upgrade properly?
Hello Andrea, I do not have a solution that both fixes the issue and does not break any environments. Maybe wato_legacy_eval in wato.py (http://git.mathias-kettner.de/git/?p=check_mk.git;a=blobdiff;f=web/plugins/config/wato.py;h=317f59394bf731727b3662f5e38d6ffa21e3983c;hp=744dde1e35164c2442ad410f5d78ccc76431ca80;hb=192d41525502dc8de10ac99f57bd988450c17566;hpb=815e624ae4c406112721771de85e22cdef3cafe6) could be set to "True" for a time, allowing the upgrade and fixing the other issues. It could be changed back to False at a later date. On the other hand, this issue seems to be the pickle/important one :-/
check-mk-1.2.4p5-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
check-mk-1.2.4p5-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
check-mk-1.2.4p5-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
check-mk-1.2.4p5-2.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
check-mk-1.2.4p5-2.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
check-mk-1.2.4p5-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
check-mk-1.2.4p5-2.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
check-mk-1.2.4p5-2.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.
check-mk-1.2.4p5-1.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.
This issue has been addressed in the following products: Red Hat Gluster Storage 3.1 for RHEL 6 Native Client for RHEL 5 for Red Hat Storage Native Client for RHEL 6 for Red Hat Storage Via RHSA-2015:1495 https://rhn.redhat.com/errata/RHSA-2015-1495.html