[//]: # (werk v2)
# Jira: Add proxy option
key | value
---------- | ---
date | 2024-07-02T08:21:14+00:00
version | 2.4.0b1
class | feature
edition | cee
component | notifications
level | 1
compatible | yes
The Jira notification plugin now has an option to configure a proxy.
[//]: # (werk v2)
# omd restore: Fix RuntimeError: Failed to determine site version
key | value
---------- | ---
compatible | yes
version | 2.4.0b1
date | 2024-06-11T12:03:43+00:00
level | 1
class | fix
component | omd
edition | cre
Due to a regression introduced by Werk <a href="https://checkmk.com/werk/16422">Werk #16422</a>, the
command `omd restore <NEW_SITE> <ARCHIVE_PATH>` could fail:
```
File "/omd/versions/2.3.0p6.cee/lib/python3/omdlib/main.py", line 3522, in _restore_backup_from_tar
old_site.replacements(),
^^^^^^^^^^^^^^^^^^^^^^^
File "/omd/versions/2.3.0p6.cee/lib/python3/omdlib/contexts.py", line 136, in replacements
raise RuntimeError("Failed to determine site version")
```
The failure only occured, if the user provided a site name, which differed from the original name,
and the original site did no longer exist. This crash also affected the `Migrate existing Site`
function of the appliance.
If you are affected by this crash, but are unable to update, then you can start be restoring the
site without a new name. The site can then be renamed with `omd mv`.
Werk 16878 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# global_settings: enable 'Hide Checkmk version' per default
key | value
---------- | ---
date | 2024-06-26T09:01:06+00:00
version | 2.4.0b1
class | security
edition | cre
component | wato
level | 1
compatible | yes
Displaying the version number on the login screen is generally regarded
as a security risk because it can enable attackers to identify potential
vulnerabilities associated with that specific version. Consequently, we
have changed the default setting to hide the version number. Users who wish
to view the version number can manually enable this option through the
Global Settings. It should be highlighted that users who have previously set
this option to show the version will not be affected by this change.
To aid automated scanning we assign a CVSS score of 0.0 (None) (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N).
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# global_settings: enable 'Hide Checkmk version' per default
key | value
---------- | ---
date | 2024-06-26T09:01:06+00:00
version | 2.4.0b1
class | security
edition | cre
component | wato
level | 1
compatible | yes
Displaying the version number on the login screen is generally regarded
as a security risk because it can enable attackers to identify potential
vulnerabilities associated with that specific version. Consequently, we
have changed the default setting to hide the version number. Users who wish
to view the version number can manually enable this option through the
Global Settings. It should be highlighted that users who have previously set
this option to show the version will not be affected by this change.
- To aid automated scanning we assign a CVSS score of 0.0 (None) (`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N`).
? - -
+ To aid automated scanning we assign a CVSS score of 0.0 (None) (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N).
[//]: # (werk v2)
# Allow filesystem service rule levels to go above 100%
key | value
---------- | ---
date | 2024-06-25T10:07:14+00:00
version | 2.4.0b1
class | feature
edition | cre
component | wato
level | 1
compatible | yes
Previously, the option `Levels for used/free space` of various
`Filesystem` rules did not allow percent values beyond 101.0 %. With
this werk any non-negative value can be set, allowing virtualized file
systems to be monitored more granularly.
[//]: # (werk v2)
# Fix float rule values not checking all validations
key | value
---------- | ---
date | 2024-06-25T07:08:34+00:00
version | 2.4.0b1
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.
[//]: # (werk v2)
# XSS in SQL check parameters
key | value
---------- | ---
date | 2024-06-17T10:08:19+00:00
version | 2.4.0b1
class | security
edition | cre
component | wato
level | 1
compatible | yes
Prior to this Werk an attacher could add HTML to one parameter of the *Check SQL database* rule which was executed on the overview page.
We found this vulnerability internally.
**Affected Versions**:
LI: 2.3.0
LI: 2.2.0
LI: 2.1.0
LI: 2.0.0 (probably older versions as well)
**Indicators of Compromis**:
The creation of such rules is logged in the audit log. You can therefore check the `wato_audit.log` either on the terminal or in the UI for entries that contain malicious HTML.
**Vulnerability Management**:
We have rated the issue with a CVSS Score of 6.5 (Medium) with the following CVSS vector: `CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L`
We assigned CVE-2024-6052 to this vulnerability.
**Changes**:
This Werk fixes the escaping.
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.4.0b1
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.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# Synthetic Monitoring: Privilege Escalation
key | value
---------- | ---
date | 2024-06-24T14:56:31+00:00
version | 2.4.0b1
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 vunerable Python environments revoked. Moreover, the permissions inside of the working
? --------
+ access to the vulnerable Python environments revoked. Moreover, the permissions inside of the
? +
- directory of Robotmk have been reworked. Users now only have access to directories, which are
? ----
+ working directory of Robotmk have been reworked. Users now only have access to directories, which
? ++++++++
- required for their own executions.
+ 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.
Title: Escape user input on load failure of visuals
Class: security
Compatible: compat
Component: multisite
Date: 1719397057
Edition: cre
Level: 1
Version: 2.1.0p45
An attacker could create phishing links that take Checkmk users to their
Checkmk installation and lure them into a malicious link if a visual
(view/dashboard/report) did not exist.
<em>Affected Versions</em>:
LI: 2.3.0
LI: 2.2.0
LI: 2.1.0
LI: 2.0.0 (EOL)
<em>Vulnerability Management</em>:
We have rated the issue with a CVSS Score of <4.3 (Medium)> with the following
CVSS vector: <code>CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N</code> and assigned CVE
<code>CVE-2024-38857</code>.
Title: Escape user input on load failure of visuals
Class: security
Compatible: compat
Component: multisite
Date: 1719397057
Edition: cre
Level: 1
Version: 2.2.0p28
An attacker could create phishing links that take Checkmk users to their
Checkmk installation and lure them into a malicious link if a visual
(view/dashboard/report) did not exist.
<em>Affected Versions</em>:
LI: 2.3.0
LI: 2.2.0
LI: 2.1.0
LI: 2.0.0 (EOL)
<em>Vulnerability Management</em>:
We have rated the issue with a CVSS Score of <4.3 (Medium)> with the following
CVSS vector: <code>CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N</code> and assigned CVE
<code>CVE-2024-38857</code>.
Title: SIGNL4: better support of service alerting and two-way status updates
Class: fix
Compatible: compat
Component: notifications
Date: 1698405465
Edition: cre
Level: 1
Version: 2.2.0p28