Title: Event Console: Fix events on central site if these events are dedicated for remote sites
Class: fix
Compatible: compat
Component: ec
Date: 1702905058
Edition: cre
Level: 1
Version: 2.2.0p18
Title: KUBE: Addition of support for Kubernetes version 1.28
Class: feature
Compatible: compat
Component: checks
Date: 1697615780
Edition: cre
Level: 1
Version: 2.3.0b1
With this release of Checkmk, we introduce support for version 1.28 of Kubernetes. In Checkmk 2.3,
support for Kubernetes version 1.23 is removed. The supported versions are listed below:
Checkmk 2.2: 1.22, 1.23, 1.24, 1.25, 1.26, 1.27
Checkmk 2.3: 1.24, 1.25, 1.26, 1.27, 1.28
The list of supported versions may not apply to future patch versions. For such cases, a
new werk will be released.
[//]: # (werk v2)
# opsgenie: Fix notification acknowledgement if host or service are back to OK
key | value
---------- | ---
date | 2024-01-05T14:04:50+00:00
version | 2.3.0b1
class | fix
edition | cre
component | notifications
level | 1
compatible | yes
Previously, Opsgenie notification wouldn't acknowledge notifications if
host or service state went back to OK in the meantime.
Werk 16067 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: Fix possible "Internal server error" while saving large formulars
Class: fix
Compatible: compat
Component: multisite
Date: 1698237843
Edition: cre
Knowledge: doc
Level: 1
Version: 2.3.0b1
Werk #15393 already solved this for most users but in rare cases, the
formulars were still so big that an "Internal server error" occurred on saving.
This change should fix that behaviour even for such cases.
------------------------------------<diff>-------------------------------------------
Title: Fix possible "Internal server error" while saving large formulars
Class: fix
Compatible: compat
Component: multisite
Date: 1698237843
Edition: cre
Knowledge: doc
Level: 1
- Version: 2.3.0i1
? ^
+ Version: 2.3.0b1
? ^
Werk #15393 already solved this for most users but in rare cases, the
formulars were still so big that an "Internal server error" occurred on saving.
This change should fix that behaviour even for such cases.
-
[//]: # (werk v2)
# folder_config/host_config: No longer accept non-existent site
key | value
---------- | ---
date | 2023-12-22T08:11:28+00:00
version | 2.3.0b1
class | fix
edition | cre
component | rest-api
level | 1
compatible | yes
You can no longer set a non-existent site on folders and hosts.
When called with a non-existent site as an attribute the
endpoints now return the status code 400.
Title: Disabled automation users could still authenticate
Class: security
Compatible: incomp
Component: wato
Date: 1702309789
Edition: cre
Level: 1
Version: 2.3.0b1
Prior to this Werk an automation user whose password was disabled also described as "disable the login to this account" was still able to authenticate.
The information that a user was disabled was not checked for automation users.
We found this vulnerability internally.
<b>Affected Versions</b>:
LI: 2.2.0
LI: 2.1.0
LI: 2.0.0
LI: 1.6.0
LI: 1.5.0 (probably older versions as well)
<b>Mitigations</b>:
If the need arises to block an automation user one can change the password or remove that user from the system.
<b>Vulnerability Management</b>:
We have rated the issue with a CVSS Score of 8.8 (High) with the following CVSS vector:
<tt>CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H</tt>.
We assigned CVE-2023-31211 to this vulnerability.
<b>Changes</b>:
This Werk adds a check for the disabled information. During update you will be warned if a automation user is currently disabled.
Title: Local privilege escalation in agent plugin 'mk_tsm'
Class: security
Compatible: incomp
Component: checks
Date: 1702411459
Edition: cre
Level: 1
Version: 2.3.0b1
By crafting a malicious command that then shows up in the output of `ps` users of monitored hosts could gain root privileges.
This was achieved by exploiting the insufficient quoting when using ksh's `eval` to create the required environment.
This issue was found during internal review.
### Affected Versions
* 2.2.0
* 2.1.0
* 2.0.0 (EOL) and older
### Mitigations
If updating is not possible, disable the Tivoli Storage Manager plugin.
### Vulnerability Management
We have rated the issue with a CVSS score of 8.8 (High) with the following CVSS vector:
`CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H`
We have assigned `CVE-2023-6735`.
### Changes
With this change we no longer use `eval` and fixe the quoting.
This prevents variable exports being missinterpreted as commands to execute.
[//]: # (werk v2)
# Limit the service description length to 250
key | value
---------- | ---
date | 2024-01-08T11:56:11+00:00
version | 2.3.0b1
class | feature
edition | cre
component | wato
level | 1
compatible | yes
Since this release WATO prevents creation of a service with
too long service description.
Title: jar_signature: Prevent privilege escalation to root
Class: security
Compatible: incomp
Component: checks
Date: 1702395666
Edition: cre
Level: 3
Version: 2.3.0b1
jar_signature agent plugin (configured by the 'Signatures of certificates in JAR files' bakery rule)
was vulnerable to privilege escalation to root by the oracle user.
A malicious oracle user could replace the jarsigner binary with another script and put
it in the JAVA_HOME directory. The script would be executed by the root user.
The jarsigner is now executed by the oracle user, preventing the privilege escalation.
This werk is incompatible for users that use the jar_signature plugin. Too avoid risk, users
should deploy the new version of the plugin or disable it.
This issue was found during internal review.
### Affected Versions
* 2.2.0
* 2.1.0
* 2.0.0 (EOL) and older
### Mitigations
If updating is not possible, disable the jar_signature plugin.
### Vulnerability Management
We have rated the issue with a CVSS score of 8.8 (High) with the following CVSS vector:
`CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H`
We have assigned `CVE-2023-6740`.
### Changes
The jarsigner binary is now executed by the oracle user.
[//]: # (werk v2)
# check_mk_agent: Set LC_ALL before running the agent
key | value
---------- | ---
compatible | yes
version | 2.3.0b1
date | 2024-01-02T10:09:48+00:00
level | 1
class | fix
component | checks
edition | cre
Previously, Checkmk agents would be run with a preset LC_ALL
environment variable if neither C.UTF-8 or C.utf-8 locales were
installed.
That led to invalid agent output and crashes in section parsing
in multiple checks for some of the locales.
Linux, AIX, Solaris, FreeBSD and OpenWrt agents were affected.
Now, LC_ALL variable is set to C for the described case.