Werk 16434 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# Synthetic Monitoring: Privilege Escalation
key | value
---------- | ---
date | 2024-06-24T14:56:31+00:00
version | 2.3.0p11
class | security
edition | cee
component | agents
level | 1
compatible | yes
The Robotmk scheduler was affected by a privilege escalation issue. This issue affects users, which
have configured the rule `Robotmk scheduler (Windows)`. Specifically, an attacker is able to exploit
the issue, if
1. `Automated environment setup (via RCC)` was configured in the `Robotmk scheduler (Windows)` rule,
2. the same plan was configured without configuring `Execute plan as a specific user`
3. and a user on the host, onto which the scheduler has been deployed, was compromised.
In this event, the attacker could gain SYSTEM privileges on the host. If `Execute plan as a specific
user` _is_ configured, then the attacker could compromise that specific user, rather than SYSTEM.
There is a second similar, but distinct issue. If
- there are two or more plans configured with `Execute plan as a specific user` with distinct users
- and one of the configured users was already compromised.
The attacker could then compromise the other user.
*Background*:
The Robotmk scheduler is started by the Checkmk agent that runs with SYSTEM privileges.
Moreover, Robotmk allows the user to automatically build Python environments via RCC. During setup
the scheduler would enable a RCC feature called `shared holotree usage`. This feature allows all
users on the host to edit these Python environments. Thus, any compromised user on the host is also
able to compromise a user, which executes code from these shared environments.
With this Werk, `shared holotree usage` will no longer be enabled. Affected users will have their
access to the vulnerable Python environments revoked. Moreover, the permissions inside of the
working directory of Robotmk have been reworked. Users now only have access to directories, which
are required for their own executions.
Note, you must update both Checkmk and redeploy the latest Robotmk Scheduler.
*Affected Versions*:
* 2.3.0
*Mitigations*:
If updating is not possible:
* Do not use the rule `Automated environment setup (via RCC)`.
* Always use the same user for `Execute plan as a specific user`.
*Vulnerability Management*:
We have rated the issue with a CVSS Score of 7.8 (High) with the following CVSS vector:
`CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`.
CVE-2024-39934 has been assigned to this issue.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# Synthetic Monitoring: Privilege Escalation
key | value
---------- | ---
date | 2024-06-24T14:56:31+00:00
- version | 2.3.0p8
? ^
+ version | 2.3.0p11
? ^^
class | security
edition | cee
component | agents
level | 1
compatible | yes
The Robotmk scheduler was affected by a privilege escalation issue. This issue affects users, which
have configured the rule `Robotmk scheduler (Windows)`. Specifically, an attacker is able to exploit
the issue, if
1. `Automated environment setup (via RCC)` was configured in the `Robotmk scheduler (Windows)` rule,
2. the same plan was configured without configuring `Execute plan as a specific user`
3. and a user on the host, onto which the scheduler has been deployed, was compromised.
In this event, the attacker could gain SYSTEM privileges on the host. If `Execute plan as a specific
user` _is_ configured, then the attacker could compromise that specific user, rather than SYSTEM.
There is a second similar, but distinct issue. If
- there are two or more plans configured with `Execute plan as a specific user` with distinct users
- and one of the configured users was already compromised.
The attacker could then compromise the other user.
*Background*:
The Robotmk scheduler is started by the Checkmk agent that runs with SYSTEM privileges.
Moreover, Robotmk allows the user to automatically build Python environments via RCC. During setup
the scheduler would enable a RCC feature called `shared holotree usage`. This feature allows all
users on the host to edit these Python environments. Thus, any compromised user on the host is also
able to compromise a user, which executes code from these shared environments.
With this Werk, `shared holotree usage` will no longer be enabled. Affected users will have their
access to the vulnerable Python environments revoked. Moreover, the permissions inside of the
working directory of Robotmk have been reworked. Users now only have access to directories, which
are required for their own executions.
Note, you must update both Checkmk and redeploy the latest Robotmk Scheduler.
*Affected Versions*:
* 2.3.0
*Mitigations*:
If updating is not possible:
* Do not use the rule `Automated environment setup (via RCC)`.
* Always use the same user for `Execute plan as a specific user`.
*Vulnerability Management*:
We have rated the issue with a CVSS Score of 7.8 (High) with the following CVSS vector:
`CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`.
CVE-2024-39934 has been assigned to this issue.
Werk 16438 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# Filesystem: Use MiB instead of MB in Check Summary
key | value
---------- | ---
date | 2024-07-04T09:29:10+00:00
version | 2.3.0p11
class | fix
edition | cre
component | checks
level | 1
compatible | yes
In version 2.3.0, the Filesystem Checks have been adapted to render bytes in the format
`11.1 kb`. This has been changed back to `10.9 KiB`. This is how it was rendered in the 2.2.0.
It also consistent with the graphs used by these checks.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# Filesystem: Use MiB instead of MB in Check Summary
key | value
---------- | ---
date | 2024-07-04T09:29:10+00:00
- version | 2.3.0p10
? ^
+ version | 2.3.0p11
? ^
class | fix
edition | cre
component | checks
level | 1
compatible | yes
In version 2.3.0, the Filesystem Checks have been adapted to render bytes in the format
`11.1 kb`. This has been changed back to `10.9 KiB`. This is how it was rendered in the 2.2.0.
It also consistent with the graphs used by these checks.
Werk 16437 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# omd: Improve Runtime with Many Sites
key | value
---------- | ---
compatible | yes
version | 2.3.0p11
date | 2024-07-04T08:44:52+00:00
level | 2
class | fix
component | omd
edition | cre
With this Werk, all invocations of the <tt>omd</tt> command line tool are faster.
This Werk should not affect behaviour in any other way. The performance improvements
mostly affect hosts, which have a high number of sites.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# omd: Improve Runtime with Many Sites
key | value
---------- | ---
compatible | yes
- version | 2.3.0p10
? ^
+ version | 2.3.0p11
? ^
date | 2024-07-04T08:44:52+00:00
level | 2
class | fix
component | omd
edition | cre
With this Werk, all invocations of the <tt>omd</tt> command line tool are faster.
This Werk should not affect behaviour in any other way. The performance improvements
mostly affect hosts, which have a high number of sites.
Werk 17072 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# Fix "Parsing of section rmon_stats failed" for Cisco SNMP devices
key | value
---------- | ---
date | 2024-07-10T07:45:41+00:00
version | 2.3.0p11
class | fix
edition | cre
component | checks
level | 1
compatible | no
For certain Cisco devices, the _Check\_MK Discovery_ service and the service discovery page
displayed the error message mentioned above. To solve this issue, users have to execute the _Remove
all and find new_ action in the actions menu of the service discovery page for affected hosts.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# Fix "Parsing of section rmon_stats failed" for Cisco SNMP devices
key | value
---------- | ---
date | 2024-07-10T07:45:41+00:00
- version | 2.3.0p10
? ^
+ version | 2.3.0p11
? ^
class | fix
edition | cre
component | checks
level | 1
compatible | no
For certain Cisco devices, the _Check\_MK Discovery_ service and the service discovery page
displayed the error message mentioned above. To solve this issue, users have to execute the _Remove
all and find new_ action in the actions menu of the service discovery page for affected hosts.
Werk 17011 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# Fix local IP restriction of internal HTTP endpoints
key | value
---------- | ---
date | 2024-06-19T13:46:09+00:00
version | 2.3.0p11
class | security
edition | cre
component | wato
level | 1
compatible | yes
Checkmk has some complex functionalities that are hidden behind an internal HTTP endpoint page.
These pages are only meant to be accessed by internal processes, e.g. a cron runner or creating diagrams for notifications.
Therefore these pages are protected to be only accessible locally.
In order to recognize the client IP through the usage of a reverse proxy Checkmk uses the `X-Forwarded-For` header.
That header is added and complemented by `mod_proxy` and usually trustworthy.
When the site apache is exposed directly to the network though (e.g. the default docker setup) no proxy apache is there to curate this header.
To mitigate this the site apache is supposed to filter these internal page URIs to be only accessible by localhost.
This mitigation failed due to some outdated configuration and wrong configuration ordering.
This only affects systems which expose the site apache port to the network typically 5000.
If you run Checkmk behind a reverse proxy (the default if you installed a installation package) you are not affected!
This vulnerability was identified in a commissioned penetration test conducted by PS Positive Security GmbH.
**Affected Versions**:
* 2.3.0
* 2.2.0
* 2.1.0
* 2.0.0 (probably older versions as well)
**Mitigations**:
You can add the following configuration to the site apache configuration, e.g. `etc/apache/conf.d/zzz_werk17011.conf`:
<Location "/###SITE###/check_mk/run_cron.py">
Order deny,allow
Deny from all
Require local
Satisfy any
</Location>
# Webservice for graph images used by notifications
<Location "/###SITE###/check_mk/ajax_graph_images.py">
Order deny,allow
Deny from all
Require local
Satisfy any
</Location>
**Indicators of Compromise**:
You can check the apache access log `var/log/apache/access_log` for calls to `run_cron.py` or `ajax_graph_images.py` from network hosts.
E.g. `grep --extended-regexp "^[^-].+(run_cron|ajax_graph_images.py)" var/log/apache/access_log`
**Vulnerability Management**:
We have rated the issue with a CVSS Score of 5.3 (Medium) with the following CVSS vector:
`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N`.
We assigned CVE-2024-6163 to this vulnerability.
**Changes**:
This Werk fixes the configuration syntax and ordering.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# Fix local IP restriction of internal HTTP endpoints
key | value
---------- | ---
date | 2024-06-19T13:46:09+00:00
- version | 2.3.0p10
? ^
+ version | 2.3.0p11
? ^
class | security
edition | cre
component | wato
level | 1
compatible | yes
Checkmk has some complex functionalities that are hidden behind an internal HTTP endpoint page.
These pages are only meant to be accessed by internal processes, e.g. a cron runner or creating diagrams for notifications.
Therefore these pages are protected to be only accessible locally.
In order to recognize the client IP through the usage of a reverse proxy Checkmk uses the `X-Forwarded-For` header.
That header is added and complemented by `mod_proxy` and usually trustworthy.
When the site apache is exposed directly to the network though (e.g. the default docker setup) no proxy apache is there to curate this header.
To mitigate this the site apache is supposed to filter these internal page URIs to be only accessible by localhost.
This mitigation failed due to some outdated configuration and wrong configuration ordering.
This only affects systems which expose the site apache port to the network typically 5000.
If you run Checkmk behind a reverse proxy (the default if you installed a installation package) you are not affected!
This vulnerability was identified in a commissioned penetration test conducted by PS Positive Security GmbH.
**Affected Versions**:
* 2.3.0
* 2.2.0
* 2.1.0
* 2.0.0 (probably older versions as well)
**Mitigations**:
You can add the following configuration to the site apache configuration, e.g. `etc/apache/conf.d/zzz_werk17011.conf`:
<Location "/###SITE###/check_mk/run_cron.py">
Order deny,allow
Deny from all
Require local
Satisfy any
</Location>
# Webservice for graph images used by notifications
<Location "/###SITE###/check_mk/ajax_graph_images.py">
Order deny,allow
Deny from all
Require local
Satisfy any
</Location>
**Indicators of Compromise**:
You can check the apache access log `var/log/apache/access_log` for calls to `run_cron.py` or `ajax_graph_images.py` from network hosts.
E.g. `grep --extended-regexp "^[^-].+(run_cron|ajax_graph_images.py)" var/log/apache/access_log`
**Vulnerability Management**:
We have rated the issue with a CVSS Score of 5.3 (Medium) with the following CVSS vector:
`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N`.
We assigned CVE-2024-6163 to this vulnerability.
**Changes**:
This Werk fixes the configuration syntax and ordering.
Werk 17116 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# Fix unknown services for Nutanix Prism
key | value
---------- | ---
date | 2024-07-10T14:20:49+00:00
version | 2.3.0p11
class | fix
edition | cre
component | checks
level | 1
compatible | yes
This fixes a regression introduced in Checkmk 2.3.0p7 that caused several services to vanish during discovery or go to UNKNOWN during checking.
The affected plugins where
* Nutanix Prism: General Info about a Cluster
* Nutanix Prism: Cluster CPU
* Nutanix Prism: Host IO
* Nutanix Prism: Cluster Memory
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# Fix unknown services for Nutanix Prism
key | value
---------- | ---
date | 2024-07-10T14:20:49+00:00
- version | 2.3.0p10
? ^
+ version | 2.3.0p11
? ^
class | fix
edition | cre
component | checks
level | 1
compatible | yes
This fixes a regression introduced in Checkmk 2.3.0p7 that caused several services to vanish during discovery or go to UNKNOWN during checking.
The affected plugins where
* Nutanix Prism: General Info about a Cluster
* Nutanix Prism: Cluster CPU
* Nutanix Prism: Host IO
* Nutanix Prism: Cluster Memory
Werk 17092 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# Fix missing CSRF token issues
key | value
---------- | ---
date | 2024-07-03T09:07:10+00:00
version | 2.3.0p11
class | fix
edition | cre
component | wato
level | 1
compatible | yes
Werk #17090 in Checkmk 2.3.0p8 and 2.2.0p29 introduced additional CSRF token checks in the GUI.
This caused some buttons to not work anymore because the CSRF token was missing, including, but likely not limited to:
* "Synchronize users" in Setup > Users to manually trigger the LDAP sync (the background sync still runs)
* "Show analysis" and "Show bulks" in Setup > Events > Notifications
* Reordering notification rules via drag-and-drop in the same view
* "Bake agents" in the agent bakery (as a workaround, use "Bake and sign agents")
* "Acknowledge last baking result" when a bake job failed (as a workaround, delete the failed job instead)
This Werk fixes the issues by adding the token.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# Fix missing CSRF token issues
key | value
---------- | ---
date | 2024-07-03T09:07:10+00:00
- version | 2.3.0p9
? ^
+ version | 2.3.0p11
? ^^
class | fix
edition | cre
component | wato
level | 1
compatible | yes
Werk #17090 in Checkmk 2.3.0p8 and 2.2.0p29 introduced additional CSRF token checks in the GUI.
This caused some buttons to not work anymore because the CSRF token was missing, including, but likely not limited to:
* "Synchronize users" in Setup > Users to manually trigger the LDAP sync (the background sync still runs)
* "Show analysis" and "Show bulks" in Setup > Events > Notifications
* Reordering notification rules via drag-and-drop in the same view
* "Bake agents" in the agent bakery (as a workaround, use "Bake and sign agents")
* "Acknowledge last baking result" when a bake job failed (as a workaround, delete the failed job instead)
This Werk fixes the issues by adding the token.
Werk 17081 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# Reduce risk of hanging processes
key | value
---------- | ---
date | 2024-07-03T11:30:56+00:00
version | 2.3.0p11
class | fix
edition | cce
component | multisite
level | 1
compatible | yes
Currently files required for the licensing of Checkmk are locked for reading and writing. If a process does not release its acquired file lock for any reason, subsequent processes will continue to what for that lock, causing to the entire site to freeze.
This locking mechanism has now been removed to reduce the risk of this happening.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# Reduce risk of hanging processes
key | value
---------- | ---
date | 2024-07-03T11:30:56+00:00
- version | 2.3.0p9
? ^
+ version | 2.3.0p11
? ^^
class | fix
edition | cce
component | multisite
level | 1
compatible | yes
Currently files required for the licensing of Checkmk are locked for reading and writing. If a process does not release its acquired file lock for any reason, subsequent processes will continue to what for that lock, causing to the entire site to freeze.
This locking mechanism has now been removed to reduce the risk of this happening.
Werk 17117 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# multipath: Allow for dots in the UUID
key | value
---------- | ---
date | 2024-07-10T15:17:28+00:00
version | 2.3.0p11
class | fix
edition | cre
component | checks
level | 1
compatible | yes
Previously devices with dots in their UUID have not been discovered.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# multipath: Allow for dots in the UUID
key | value
---------- | ---
date | 2024-07-10T15:17:28+00:00
- version | 2.3.0p10
? ^
+ version | 2.3.0p11
? ^
class | fix
edition | cre
component | checks
level | 1
compatible | yes
Previously devices with dots in their UUID have not been discovered.
Werk 17076 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# Fix float rule values not checking all validations
key | value
---------- | ---
date | 2024-06-25T07:08:34+00:00
version | 2.3.0p11
class | fix
edition | cre
component | wato
level | 1
compatible | no
In Checkmk, it's possible for any rule value to specify custom
validation functions to stop users from accidentally entering invalid
data. Before this werk, the set of rule fields that allowed floating
point values to be set in rare cases did not check these custom
validation functions when setting up a rule.
With this werk, we restore the expected functionality and check
the validity of all floating point values in a rule.
**Incompatibility**
Some users might have created rules which should not have been valid.
You will find out if such a rule is present in your setup when you
update your site. The update process will raise an error warning you of
any rule values that break custom validators. This error will tell you
about the invalid rule and the reason it is invalid. Please abort the
update process, fix the invalid value and restart the update process.
**Plugin developers**
If you have created a rule value with the `validate` (ValueSpec) or
`custom_validate` (Form Spec) argument set, your rule will now correctly
use provided functions to check the validity of the data. No change to
the rule is necessary.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# Fix float rule values not checking all validations
key | value
---------- | ---
date | 2024-06-25T07:08:34+00:00
- version | 2.3.0p10
? ^
+ version | 2.3.0p11
? ^
class | fix
edition | cre
component | wato
level | 1
compatible | no
In Checkmk, it's possible for any rule value to specify custom
validation functions to stop users from accidentally entering invalid
data. Before this werk, the set of rule fields that allowed floating
point values to be set in rare cases did not check these custom
validation functions when setting up a rule.
With this werk, we restore the expected functionality and check
the validity of all floating point values in a rule.
**Incompatibility**
Some users might have created rules which should not have been valid.
You will find out if such a rule is present in your setup when you
update your site. The update process will raise an error warning you of
any rule values that break custom validators. This error will tell you
about the invalid rule and the reason it is invalid. Please abort the
update process, fix the invalid value and restart the update process.
**Plugin developers**
If you have created a rule value with the `validate` (ValueSpec) or
`custom_validate` (Form Spec) argument set, your rule will now correctly
use provided functions to check the validity of the data. No change to
the rule is necessary.