Title: huawei_osn_laser: Fix parsing issue
Class: fix
Compatible: compat
Component: checks
Date: 1718637633
Edition: cre
Level: 1
Version: 2.2.0p28
Fixed a parsing issue in the huawei_osn_laser check plugin.
The problem appeared every time a serivce was supposed to have an OK state and caused the check plugin to crash, and thus not deliver any result.
The crash report ended with this line:
C+:
if "\n" in subresult[1]:
C-:
This has now been fixed.
Title: Fix XSS in confirmation pop-up
Class: security
Compatible: compat
Component: wato
Date: 1718016028
Edition: cre
Level: 1
Version: 2.2.0p28
Prior to this Werk, there was a potential for HTML elements from user inputs to be rendered in certain confirmation pop-ups, leading to an XSS vulnerability.
This vulnerability was identified during a commissioned penetration test conducted by PS Positive Security GmbH.
<em>Affected Versions</em>:
LI: 2.3.0
LI: 2.2.0
<em>Indicators of Compromise</em>:
Injected HTML elements in some specific user input fields with no proper escaping that are displayed in the confirmation pop-up.
<em>Vulnerability Management</em>:
We have rated the issue with a CVSS Score of 5.4 Medium with the following CVSS vector: <code>CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N</code>, and assigned <code>CVE-2024-28831</code>.
Title: Fix XSS in Crash Report Page
Class: security
Compatible: compat
Component: wato
Date: 1717679856
Edition: cre
Level: 1
Version: 2.2.0p28
Prior to this Werk, it was possible to inject HTML elements into Crash report
URL in the Global settings, leading to an <code>XSS</code> vulnerability in the Crash reports page.
This vulnerability was identified during a commissioned penetration test conducted by PS Positive Security GmbH.
<em>Affected Versions</em>:
LI: 2.3.0
LI: 2.2.0
LI: 2.1.0
LI: 2.0.0 (EOL)
<em>Indicators of Compromise</em>:
Check the crash report HTTP URL in the Global settings for suspicious HTML elements.
<em>Vulnerability Management</em>:
We have rated the issue with a CVSS Score of 4.8 Medium with the following CVSS vector: <code>CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:L/A:N</code>.
and assigned <code>CVE-2024-28832</code>.
[//]: # (werk v2)
# Fix unescaped details for process discovery checks in "Log: Details" column
key | value
---------- | ---
compatible | yes
version | 2.3.0p7
date | 2024-06-18T12:31:13+00:00
level | 1
class | fix
component | multisite
edition | cre
Werk #16701 already fixed the escaping for availability views.
This werk fixes the escaping in views with "Log: Details" columns.
If the long output is truncated, there will be a warning because we can not
render the table without the complete table styling, which is missing in that
case.
[//]: # (werk v2)
# MS Exchange: 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
Various msexch_* checks 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 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
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)
# Split old audit log files larger 300MB on update
key | value
---------- | ---
date | 2024-06-14T07:49:42+00:00
version | 2.3.0p7
class | fix
edition | cre
component | wato
level | 1
compatible | yes
Since 2.3.0 the wato audit log files are logrotated at a size of 300MB.
The update should take care of files bigger than 300MB but looked for files
greater 400MB in earlier versions.
This has now been adjusted to the size the logrotate happens.
[//]: # (werk v2)
# huawei_osn_laser: Fix parsing issue
key | value
---------- | ---
date | 2024-06-17T15:20:33+00:00
version | 2.3.0p7
class | fix
edition | cre
component | checks
level | 1
compatible | yes
Fixed a parsing issue in the huawei_osn_laser check plugin.
The problem appeared every time a serivce was supposed to have an OK state and caused the check plugin to crash, and thus not deliver any result.
The crash report ended with this line:
C+:
if "\n" in subresult[1]:
C-:
This has now been fixed.
[//]: # (werk v2)
# Fix XSS in confirmation pop-up
key | value
---------- | ---
date | 2024-06-10T10:40:28+00:00
version | 2.3.0p7
class | security
edition | cre
component | wato
level | 1
compatible | yes
Prior to this Werk, there was a potential for HTML elements from user inputs to be rendered in certain confirmation pop-ups, leading to an XSS vulnerability.
This vulnerability was identified during a commissioned penetration test conducted by PS Positive Security GmbH.
*Affected Versions*:
* 2.3.0
* 2.2.0
*Indicators of Compromise*:
Injected HTML elements in some specific user input fields with no proper escaping that are displayed in the confirmation pop-up.
*Vulnerability Management*:
We have rated the issue with a CVSS Score of 5.4 (Medium) with the following CVSS vector: `CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N`, and assigned `CVE-2024-28831`.
[//]: # (werk v2)
# Fix XSS in Crash Report Page
key | value
---------- | ---
date | 2024-06-06T13:17:36+00:00
version | 2.3.0p7
class | security
edition | cre
component | wato
level | 1
compatible | yes
Prior to this Werk, it was possible to inject HTML elements into Crash report
URL in the Global settings, leading to an `XSS` vulnerability in the Crash reports page.
This vulnerability was identified during a commissioned penetration test conducted by PS Positive Security GmbH.
*Affected Versions*:
* 2.3.0
* 2.2.0
* 2.1.0
* 2.0.0 (EOL)
*Indicators of Compromise*:
Check the crash report HTTP URL in the Global settings for suspicious HTML elements.
*Vulnerability Management*:
We have rated the issue with a CVSS Score of 4.8 Medium with the following CVSS vector: `CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:L/A:N`.
and assigned `CVE-2024-28832`.