ID: 0766
Title: Changed transid implemtation to work as CSRF protection (Fixes CVE-2014-2330)
Component: Multisite
Level: 3
Class: Bug Fix
Version: 1.2.5i2
This change fixes possible attacks against Check_MK Multisite users. In previous
versions a possible attacker could try to make the browsers of authenticated users
open URLs of the Check_MK Multisite GUI to execute actions e.g. within WATO without
knowledge of the attacked user.
To make such an attack possible, there are several things needed: The user must be
authenticated with multisite and have enough permission within multisite to execute
the actions the attacker wants to use, the attacker needs to know the exact URL to the
Multisite GUI. Then the attacker needs to make the user either click on a manipulated
link or open a manipulated webpage which makes the browser of the user, where the user
is authenticated with multisite, open the URL the attacker wants to make it open.
The multisite GUI makes use of transids (transaction ids) when processing form
submissions or actions. The transids were mainly used to prevent double execution
of actions when reloading the page which performed the action in the browser.
Now we changed internal handling of the transid to make it also prevent CSRF attacks.
The transid is now some kind of shared secret between the webserver and the browser
of the user. This ensures a form submission is intended by a previously requested page.
This change impicates an incompatible change: In case you use a script which opens
multisite pages to perform an action, e.g. set a downtime and use this with a regular
user account which authenticates by username/password, the script won't work anymore
after this change.
The way to go is to adapt the script and change the user to authenticate with an
automation secret instead of a password. For this kind of authentication, you will
need to user other URL parameters (_username=... and _secret=...).
ID: 0761
Title: New bulk host import mode in WATO
Component: WATO
Level: 2
Class: New Feature
Version: 1.2.5i1
You can now import a list of hosts into a WATO folder. The new feature can be
reached by clicking the <tt>Bulk Import</tt> button a WATO folder of your
choice. Simply add a list of host names to the text area, choose whether or not
you like to do an inventory afterwards and then click <tt>Import</tt>.
ID: 0597
Title: dell_chassis_slots: new check to monitor the status of the blade slots of the Dell Poweredge Blade Servers
Component: Checks & Agents
Level: 2
Class: New Feature
Version: 1.2.5i1
ID: 0596
Title: dell_chassis_status, dell_chassis_temp, dell_chassis_kvm, dell_chassis_io, dell_chassis_fans: new checks to monitor the overall status of various sections of the Dell Poweredge Chassis via CMC
Component: Checks & Agents
Level: 2
Class: New Feature
Version: 1.2.5i1
ID: 0595
Title: dell_chassis_power, dell_chassis_powersupplies: new checks for Dell Poweredge Chassis Ppower consumption
Component: Checks & Agents
Level: 2
Class: New Feature
Version: 1.2.5i1
These checks measure the overall power consumption of the chassis of the Dell Poweredge Blade Server
as well as the power consumption of the individual blade nodes as given by the Dell Chassis Management
Controller (CMC)
ID: 0749
Title: Allow to restrict visibility of events by their host contacts
Component: Event Console
Level: 2
Class: New Feature
Version: 1.2.5i1
The Event Console has now two new permissions:
<ol>
<li>See all events</li>
<li>See events not related to a known host</li>
</ol>
Both permissions default to <i>yes</i> in all roles. If you remove the <i>See all events</i>
permission then a user can only see events for hosts that either he is a monitoring contact for
or that are not known to the monitoring at all (i.e. no host with such a name or IP address
is configured as monitored host in your monitoring core). The visibility of the later
ones can be switched off with the second permission. The second permission is only relevant
if <i>See all events</i> is set to <i>no</i> - of course.
Furthermore you can now assign <i>Fallback Contact Groups</i> to an event. This
is done with a new rule option in the section <i>Outcome & Action</i>. As
soon as you assign contact groups these will be assumed for all hosts
that are not in the monitoring. That groups will be attached as an additional information
to each event created with that rule. These events will then be handled like as if the
host is known to the monitoring when it comes to the visibility.
ID: 0748
Title: Also custom views now have permissions
Component: Multisite
Level: 2
Class: New Feature
Version: 1.2.5i1
In that past only builtin views had permissions that you could disable in a
role and that way remove those views for certain users. Now this also works
for custom views - i.e. views that a user has created with a new unique name
and and that is published for other users.
Please note that regardless of a view's permission the owner of the view can
always see it. If you do not like this you can remove the permission for
creating custom views.
The default for new views is still that all roles have the permission for
this view.
ID: 0748
Title: Also custom views now have permissions
Component: Multisite
Level: 2
Class: New Feature
Version: 1.2.5i1
In that past only builtin views had permissions that you could disable in a
role and that way remove those views for certain users. Now this also works
for custom views - i.e. views that a user has created with a new unique name
and and that is published for other users.
Please note that regardless of a view's permission the owner of the view can
always see it. If you do not like this you can remove the permission for
creating custom views.
ID: 0715
Title: BI aggregates now acknowledgement information
Component: BI
Level: 2
Class: New Feature
Version: 1.2.5i1
Check_MK BI now also aggregates the information wether problems that make the aggregate
non-OK are acknowledged. Please refer to the updated <a href="checkmk_bi.html">documentation
about BI</a> for details.