Title: Don't show automation secret in the audit log (addresses CVE-2024-28830)
Class: security
Compatible: incomp
Component: wato
Date: 1718799000
Edition: cre
Level: 2
Version: 2.1.0p45
By default only admin users are able to see the audit log. Guests and normal
monitoring users do not have acces to the audit log.
Werk #13330 already fixed a problem where passwords were shown in the audit log.
This werk now addresses the problem, that still automation secrets of
automation user were logged in clear text to the audit log, e.g. on change of
the automation secret via REST-API or the user interface.
Existing automation secrets in the audit log should be removed automatically
during the update but please double check that no automation secrets remain in
the log (see next paragraph for details).
A backup of the original audit log (before automation secrets were removed) is
copied to "~/audit_log_backup". If anything goes wrong during the update, you
have to copy the files back to ~var/check_mk/wato/log and remove the automation
secrets manually. If the update works as expected, you can remove the backup
files.
In distributed setups which do not replicate the configuration, automation
secrets are replaced during the update of each site.
In setups which replicate the configuration from central to remote sites no
automation secrets should be present in the logs of the remote site, since only
information about the activation is logged. Only if you switched to a
replicated setup after the upgrade to the 2.0, automation secrets can be
present in the logs. Since automation secrets may be in this scenario as well,
the steps described before also apply.
<em>Affected Versions</em>:
LI: 2.3.0
LI: 2.2.0
LI: 2.1.0
LI: 2.0.0 (EOL)
<em>Mitigations</em>:
Remove automation secrets manually within the files located in
~var/check_mk/wato/log.
<em>Vulnerability Management</em>:
We have rated the issue with a CVSS Score of <2.7 (Low)> with the following
CVSS vector: <code>CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N</code> and assigned CVE
<code>CVE-2024-28830</code>.
Werk 17056 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: Don't show automation secret in the audit log (addresses CVE-2024-28830)
Class: security
Compatible: incomp
Component: wato
Date: 1718799000
Edition: cre
Level: 2
Version: 2.2.0p28
By default only admin users are able to see the audit log. Guests and normal
monitoring users do not have acces to the audit log.
Werk #13330 already fixed a problem where passwords were shown in the audit log.
This werk now addresses the problem, that still automation secrets of
automation user were logged in clear text to the audit log, e.g. on change of
the automation secret via REST-API or the user interface.
Existing automation secrets in the audit log should be removed automatically
during the update but please double check that no automation secrets remain in
the log (see next paragraph for details).
A backup of the original audit log (before automation secrets were removed) is
copied to "~/audit_log_backup". If anything goes wrong
during the update, you have to copy the files back to ~var/check_mk/wato/log
and remove the automation secrets manually. If the update works as expected,
you can remove the backup files.
In distributed setups which do not replicate the configuration, automation
secrets are replaced during the update of each site.
In setups which replicate the configuration from central to remote sites no
automation secrets should be present in the logs of the remote site, since only
information about the activation is logged. Only if you switched to a
replicated setup after the upgrade to the 2.0, automation secrets can be
present in the logs. Since automation secrets may be in this scenario as well,
the steps described before also apply.
<em>Affected Versions</em>:
LI: 2.3.0
LI: 2.2.0
LI: 2.1.0
LI: 2.0.0 (EOL)
<em>Mitigations</em>:
Remove automation secrets manually within the files located in
~var/check_mk/wato/log.
<em>Vulnerability Management</em>:
We have rated the issue with a CVSS Score of <2.7 (Low)> with the following
CVSS vector: <code>CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N</code> and assigned CVE
<code>CVE-2024-28830</code>.
------------------------------------<diff>-------------------------------------------
Title: Don't show automation secret in the audit log (addresses CVE-2024-28830)
Class: security
Compatible: incomp
Component: wato
Date: 1718799000
Edition: cre
Level: 2
Version: 2.2.0p28
By default only admin users are able to see the audit log. Guests and normal
monitoring users do not have acces to the audit log.
Werk #13330 already fixed a problem where passwords were shown in the audit log.
This werk now addresses the problem, that still automation secrets of
automation user were logged in clear text to the audit log, e.g. on change of
the automation secret via REST-API or the user interface.
Existing automation secrets in the audit log should be removed automatically
during the update but please double check that no automation secrets remain in
the log (see next paragraph for details).
A backup of the original audit log (before automation secrets were removed) is
- copied to "~/var/check_mk/wato/log/sanitize_backup". If anything goes wrong
? - ^^^^^^^ -------- ---------
+ copied to "~/audit_log_backup". If anything goes wrong
? ^^^^
during the update, you have to copy the files back to ~var/check_mk/wato/log
and remove the automation secrets manually. If the update works as expected,
you can remove the backup files.
In distributed setups which do not replicate the configuration, automation
secrets are replaced during the update of each site.
In setups which replicate the configuration from central to remote sites no
automation secrets should be present in the logs of the remote site, since only
information about the activation is logged. Only if you switched to a
replicated setup after the upgrade to the 2.0, automation secrets can be
present in the logs. Since automation secrets may be in this scenario as well,
the steps described before also apply.
<em>Affected Versions</em>:
LI: 2.3.0
LI: 2.2.0
LI: 2.1.0
LI: 2.0.0 (EOL)
<em>Mitigations</em>:
Remove automation secrets manually within the files located in
~var/check_mk/wato/log.
<em>Vulnerability Management</em>:
We have rated the issue with a CVSS Score of <2.7 (Low)> with the following
CVSS vector: <code>CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N</code> and assigned CVE
<code>CVE-2024-28830</code>.
Title: Proxmox monitoring: Fix incorrect backup monitoring results
Class: fix
Compatible: incomp
Component: checks
Date: 1718360139
Edition: cre
Level: 1
Version: 2.2.0p28
For certain Proxmox VMs, the service <i>Proxmox VE VM Backup Status</i> might have incorrectly
alerted about missing backups. This was caused by a limitation in the Proxmox agent regarding the
processing of logs and tasks. Specifically, log files larger than 5,000 lines were truncated.
A possible indicator that monitored VMs are affected by this issue is the presence of files named
<tt>erroneous-...</tt> in <tt>tmp/check_mk/special_agents/agent_proxmox_ve</tt>. Especially if these
files end with messages such as "Log for VMID=... not finalized", at least some VMs are likely
affected. To immediately benefit from this werk, users should delete the folder
<tt>tmp/check_mk/special_agents/agent_proxmox_ve</tt>. Otherwise, it can take up the maximum log
age for this werk come into effect after updating Checkmk (the maximum log age is configured in
the Proxmox agent rule).
[//]: # (werk v2)
# fix tablespaces section of mk-sql for older SQL Servers
key | value
---------- | ---
date | 2024-06-21T09:19:49+00:00
version | 2.3.0p7
class | fix
edition | cre
component | checks
level | 1
compatible | yes
Since this release, the tablespaces section correctly delivers
all required data, thereby preventing the stalling of some
services in SQL Server monitoring
[//]: # (werk v2)
# increase performance of mk-sql for some cases
key | value
---------- | ---
date | 2024-06-21T09:14:33+00:00
version | 2.3.0p7
class | feature
edition | cee
component | checks
level | 1
compatible | yes
Due to parallelization and extensive use of asynchronous
processing, the execution time of the plugin decreased by
up to 3 times for instances with many databases.
Werk 17056 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# Don't show automation secret in the audit log (addresses CVE-2024-28830)
key | value
---------- | ---
date | 2024-06-19T12:10:00+00:00
version | 2.3.0p7
class | security
edition | cre
component | wato
level | 2
compatible | no
By default only admin users are able to see the audit log. Guests and normal
monitoring users do not have acces to the audit log.
Werk #13330 already fixed a problem where passwords were shown in the audit log.
This werk now addresses the problem, that still automation secrets of
automation user were logged in clear text to the audit log, e.g. on change of
the automation secret via REST-API or the user interface.
Existing automation secrets in the audit log should be removed automatically
during the update but please double check that no automation secrets remain in
the log (see next paragraph for details).
A backup of the original audit log (before automation secrets were removed) is
copied to "~/audit_log_backup". If anything goes wrong
during the update, you have to copy the files back to ~var/check_mk/wato/log
and remove the automation secrets manually. If the update works as expected,
you can remove the backup files.
In distributed setups which do not replicate the configuration, automation
secrets are replaced during the update of each site.
In setups which replicate the configuration from central to remote sites no
automation secrets should be present in the logs of the remote site, since only
information about the activation is logged. Only if you switched to a
replicated setup after the upgrade to the 2.0, automation secrets can be
present in the logs. Since automation secrets may be in this scenario as well,
the steps described before also apply.
*Affected Versions*:
* 2.3.0
* 2.2.0
* 2.1.0
* 2.0.0 (EOL)
*Mitigations*:
Remove automation secrets manually within the files located in
~var/check_mk/wato/log.
*Vulnerability Management*:
We have rated the issue with a CVSS Score of <2.7 (Low)> with the following
CVSS vector: `CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N` and assigned CVE
`CVE-2024-28830`.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# Don't show automation secret in the audit log (addresses CVE-2024-28830)
key | value
---------- | ---
date | 2024-06-19T12:10:00+00:00
version | 2.3.0p7
class | security
edition | cre
component | wato
level | 2
compatible | no
By default only admin users are able to see the audit log. Guests and normal
monitoring users do not have acces to the audit log.
Werk #13330 already fixed a problem where passwords were shown in the audit log.
This werk now addresses the problem, that still automation secrets of
automation user were logged in clear text to the audit log, e.g. on change of
the automation secret via REST-API or the user interface.
Existing automation secrets in the audit log should be removed automatically
during the update but please double check that no automation secrets remain in
the log (see next paragraph for details).
A backup of the original audit log (before automation secrets were removed) is
- copied to "~/var/check_mk/wato/log/sanitize_backup". If anything goes wrong
? - ^^^^^^^ -------- ---------
+ copied to "~/audit_log_backup". If anything goes wrong
? ^^^^
during the update, you have to copy the files back to ~var/check_mk/wato/log
and remove the automation secrets manually. If the update works as expected,
you can remove the backup files.
In distributed setups which do not replicate the configuration, automation
secrets are replaced during the update of each site.
In setups which replicate the configuration from central to remote sites no
automation secrets should be present in the logs of the remote site, since only
information about the activation is logged. Only if you switched to a
replicated setup after the upgrade to the 2.0, automation secrets can be
present in the logs. Since automation secrets may be in this scenario as well,
the steps described before also apply.
*Affected Versions*:
* 2.3.0
* 2.2.0
* 2.1.0
* 2.0.0 (EOL)
*Mitigations*:
Remove automation secrets manually within the files located in
~var/check_mk/wato/log.
*Vulnerability Management*:
We have rated the issue with a CVSS Score of <2.7 (Low)> with the following
CVSS vector: `CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N` and assigned CVE
`CVE-2024-28830`.
[//]: # (werk v2)
# Proxmox monitoring: Fix incorrect backup monitoring results
key | value
---------- | ---
compatible | no
version | 2.3.0p7
date | 2024-06-14T10:15:39+00:00
level | 1
class | fix
component | checks
edition | cre
For certain Proxmox VMs, the service <i>Proxmox VE VM Backup Status</i> might have incorrectly
alerted about missing backups. This was caused by a limitation in the Proxmox agent regarding the
processing of logs and tasks. Specifically, log files larger than 5,000 lines were truncated.
A possible indicator that monitored VMs are affected by this issue is the presence of files named
<tt>erroneous-...</tt> in <tt>tmp/check_mk/special_agents/agent_proxmox_ve</tt>. Especially if these
files end with messages such as "Log for VMID=... not finalized", at least some VMs are likely
affected. To immediately benefit from this werk, users should delete the folder
<tt>tmp/check_mk/special_agents/agent_proxmox_ve</tt>. Otherwise, it can take up the maximum log
age for this werk come into effect after updating Checkmk (the maximum log age is configured in
the Proxmox agent rule).
[//]: # (werk v2)
# MultipleChoice formspec: use list as default value instead of tuple
key | value
---------- | ---
date | 2024-06-20T06:07:52+00:00
version | 2.3.0p7
class | fix
edition | cre
component | checks
level | 1
compatible | yes
During the creation of certain rules with MultipleChoice formspec,
the following warning appeared due to default values being saved as a list instead of a tuple:
_"Unable to read current options of this rule. Falling back to default values. When saving this rule now, your previous settings will be overwritten. The problem was: [...]: The datatype must be list, but is tuple."_
This werk corrects this behavior by allowing the use of any `Sequence` of strings as values.