Title: Re-introduce missing requirement documentation for interface check
Class: fix
Compatible: compat
Component: checks
Date: 1722352726
Edition: cre
Level: 1
Version: 2.2.0p32
During consolidation of various interface checks, necessary
prerequisites for the Solaris and HP-UX were omitted from the
documentation.
In this werk, https://checkmk.com/integrations/interfaces is updated
include the necessary prerequisites to monitor network interfaces on all
operating systems again.
[//]: # (werk v2)
# users: allow user edit saving when 'authorized_sites' attribute is locked
key | value
---------- | ---
date | 2024-07-29T12:08:49+00:00
version | 2.3.0p12
class | fix
edition | cre
component | wato
level | 1
compatible | yes
Prior to this werk, an error occurred when attempting to save the user edit
page if the 'authorized_sites' attribute was locked. This werk resolves the issue.
Werk 15220 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: time period: put endpoint now returns 200 with edited time period config
Class: fix
Compatible: compat
Component: rest-api
Date: 1675855343
Edition: cre
Knowledge: doc
Level: 1
Version: 2.3.0b1
The time period put endpoint previously returned a 204 and no
data response. This werk is a fix to return the time period
object along with a status code of 200 to align with our
other put endpoints.
------------------------------------<diff>-------------------------------------------
Title: time period: put endpoint now returns 200 with edited time period config
Class: fix
Compatible: compat
Component: rest-api
Date: 1675855343
Edition: cre
Knowledge: doc
Level: 1
- Version: 2.2.0b1
? ^
+ Version: 2.3.0b1
? ^
The time period put endpoint previously returned a 204 and no
data response. This werk is a fix to return the time period
object along with a status code of 200 to align with our
other put endpoints.
-
Werk 17074 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# msexch_database: Use consistent units (ms/s) in rules & graphs
key | value
---------- | ---
date | 2024-06-18T07:20:14+00:00
version | 2.3.0p7
class | fix
edition | cee
component | checks
level | 1
compatible | yes
The msexch_database reported its values in ms in the summary/ruleset but
displayed the same value as seconds in the graph. With this werk, all
units will be reported consistently.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# msexch_database: Use consistent units (ms/s) in rules & graphs
key | value
---------- | ---
date | 2024-06-18T07:20:14+00:00
- version | 2.3.0p11
? ^^
+ version | 2.3.0p7
? ^
class | fix
edition | cee
component | checks
level | 1
compatible | yes
The msexch_database reported its values in ms in the summary/ruleset but
displayed the same value as seconds in the graph. With this werk, all
units will be reported consistently.
Werk 17010 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# XSS in SQL check parameters
key | value
---------- | ---
date | 2024-06-17T10:08:19+00:00
version | 2.3.0p8
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.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# XSS in SQL check parameters
key | value
---------- | ---
date | 2024-06-17T10:08:19+00:00
- version | 2.3.0p11
? ^^
+ version | 2.3.0p8
? ^
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 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.0p9
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.0p11
? ^^
+ version | 2.3.0p9
? ^
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 16794 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# "checkgroup_parameters:if": Rename to "checkgroup_parameters:interfaces"
key | value
---------- | ---
date | 2024-04-26T11:27:20+00:00
version | 2.3.0p1
class | fix
edition | cre
component | checks
level | 1
compatible | no
This only affects you if you are configuring rules through the REST API.
In order to make the "checkgroup_parameters:if" ruleset compliant with the new Ruleset API, it has been renamed to "checkgroup_parameters:interfaces".
Any configuration inside Checkmk will be automatically updated, however any outside references to the old name will have to be adjusted manually.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# "checkgroup_parameters:if": Rename to "checkgroup_parameters:interfaces"
key | value
---------- | ---
date | 2024-04-26T11:27:20+00:00
- version | 2.3.0b4
? ^^
+ version | 2.3.0p1
? ^^
class | fix
edition | cre
component | checks
level | 1
compatible | no
This only affects you if you are configuring rules through the REST API.
In order to make the "checkgroup_parameters:if" ruleset compliant with the new Ruleset API, it has been renamed to "checkgroup_parameters:interfaces".
Any configuration inside Checkmk will be automatically updated, however any outside references to the old name will have to be adjusted manually.
-
Werk 15313 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: Fix memory column in docker view
Class: fix
Compatible: compat
Component: wato
Date: 1701694701
Edition: cre
Level: 1
Version: 2.3.0b1
Memory used column was always empty.
------------------------------------<diff>-------------------------------------------
Title: Fix memory column in docker view
Class: fix
Compatible: compat
Component: wato
Date: 1701694701
Edition: cre
Level: 1
- Version: 2.2.0p17
? ^ ^ -
+ Version: 2.3.0b1
? ^ ^
Memory used column was always empty.
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.0p11
? ^^
+ 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.
Werk 15714 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: Add support for Checkmk Appliance 1.7+
Class: feature
Compatible: compat
Component: distros
Date: 1701285077
Edition: cre
Level: 2
Version: 2.3.0b1
------------------------------------<diff>-------------------------------------------
Title: Add support for Checkmk Appliance 1.7+
Class: feature
Compatible: compat
Component: distros
Date: 1701285077
Edition: cre
Level: 2
- Version: 2.2.0p17
? ^ ^ -
+ Version: 2.3.0b1
? ^ ^
-