Title: MS Exchange: Use consistent units (ms/s) in rules & graphs
Class: fix
Compatible: compat
Component: checks
Date: 1720433457
Edition: cre
Level: 1
Version: 2.2.0p31
The checks msexch_isclienttype, msexch_isstore, msexch_rpcclientaccess reported
their values in ms in the summary/ruleset but displayed the same value as
seconds in the graph. With this werk, all MS Exchange checks now report their
values consistently.
Title: Delete PDF tmp files older one day
Class: fix
Compatible: compat
Component: wato
Date: 1720422296
Edition: cre
Level: 1
Version: 2.2.0p31
Werk #15125 introduced a cleanup mechanism for old PFD tmp files but deleted
files older 48hours.
Now files older than one day are deleted.
Title: redis: Add Log Rotation
Class: fix
Compatible: compat
Component: omd
Date: 1720420406
Edition: cre
Level: 1
Version: 2.2.0p31
Previously, the file <code>var/log/redis-server.log</code> would not be rotated. If you are unable to upgrade,
you can adjust the file in <code>$OMD_ROOT/etc/logrotate.d/redis</code>.
Title: Fix automatic host removal in case one remote site is not logged in
Class: fix
Compatible: compat
Component: wato
Date: 1720418941
Edition: cre
Level: 1
Version: 2.2.0p31
The automatic host removal job is executed regularly in the background to remove
hosts from the monitoring once they cease to exist. In particular for but not
limited to automatically registered hosts.
This job failed in case one remote site was configured but not logged in, not
only affecting the not logged in site, but all sites. The not logged in site is
now being skipped, leaving the mechanism intact for all other sites.
Werk 17082 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# Fixed another instance of hanging processes
key | value
---------- | ---
date | 2024-07-05T06:55:15+00:00
version | 2.3.0p10
class | fix
edition | cce
component | multisite
level | 1
compatible | yes
As explained in werk [#17080](https://checkmk.com/werk/17080) the wrong conditions could lead to processes not releasing crucial file locks and the site subsequently freezing.
However, the werk did not address all the conditions.
With this werk, the cleanup of open resources was improved, which together with werk [#17081](https://checkmk.com/werk/17081) fixes another instance of processes not releasing their locks.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# Fixed another instance of hanging processes
key | value
---------- | ---
date | 2024-07-05T06:55:15+00:00
version | 2.3.0p10
class | fix
edition | cce
component | multisite
level | 1
compatible | yes
+ As explained in werk [#17080](https://checkmk.com/werk/17080) the wrong conditions could lead to processes not releasing crucial file locks and the site subsequently freezing.
+ However, the werk did not address all the conditions.
+ With this werk, the cleanup of open resources was improved, which together with werk [#17081](https://checkmk.com/werk/17081) fixes another instance of processes not releasing their locks.
Werk 17082 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# Fixed another instance of hanging processes
key | value
---------- | ---
date | 2024-07-05T06:55:15+00:00
version | 2.3.0p10
class | fix
edition | cce
component | multisite
level | 1
compatible | yes
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# Fixed another instance of hanging processes
key | value
---------- | ---
date | 2024-07-05T06:55:15+00:00
version | 2.3.0p10
class | fix
edition | cce
component | multisite
level | 1
compatible | yes
+
[//]: # (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
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 v2)
# Delete PDF tmp files older one day
key | value
---------- | ---
date | 2024-07-08T07:04:56+00:00
version | 2.3.0p10
class | fix
edition | cre
component | wato
level | 1
compatible | yes
Werk #15125 introduced a cleanup mechanism for old PFD tmp files but deleted
files older 48hours.
Now files older than one day are deleted.
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.0p8
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
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` and requested a CVE.
? --------------------
+ `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.