[//]: # (werk v2)
# symantec_av: Don't run sav command if it isn't owned by root
key | value
---------- | ---
date | 2024-02-28T08:58:09+00:00
version | 2.3.0b1
class | security
edition | cre
component | checks
level | 1
compatible | yes
Symantec Anti Virus plugin uses /opt/Symantec/symantec_antivirus/sav command
to monitor a Symantec Anti Virus installation.
To prevent privilege escalation, the plugin (which is run by root user) must
not run executables which can be changed by less privileged users.
In the default installation, sav command is owned by root and root is the only
user with write permissions, which prevents privilege escalation attacks.
With this Werk, the plugin checks if sav command is owned by root and root
is the only user with write permissions before running the command. If that's not
the case the command won't be run. This prevents privilege escalation attacks if
the permissions of the sav command have been changed.
We rate this with a CVSS of 0 (None) (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N).
This CVSS is primarily meant to please automatic scanners.
CMK-15318
[//]: # (werk v2)
# Frozen BI: Frozen icon now also indicates if the non-frozen version differs from the frozen one
key | value
---------- | ---
date | 2024-02-27T15:09:59+00:00
version | 2.3.0b1
class | feature
edition | cre
component | bi
level | 1
compatible | yes
[//]: # (werk v2)
# Path to mysql.ini under Windows for mk_sql
key | value
---------- | ---
date | 2024-02-23T11:26:08+00:00
version | 2.3.0b1
class | fix
edition | cre
component | checks
level | 1
compatible | yes
If you've been using mysql and the corresponding agent plugin *mk_sql*
under Windows, the plugin may have crashed and the agent output would then
show the following error:
```
<<<mysql_ping>>>
[[MySQL83]]
mysqladmin: File '\etc\check_mk\mysql.local.ini' not found (OS errno 2 - No such file or directory)
mysqladmin: [ERROR] Stopped processing the 'include' directive in file C:\ProgramData\checkmk\agent\config\mysql.ini at line 8.
```
Under Windows, the plugin config path `C:\ProgramData\checkmk\agent\config` is now used.
In contrast to the corresponding Linux plugin `mk_mysql`, the config path under Windows cannot be changed.
[//]: # (werk v2)
# Connection state of interface on Windows is supported out-of-the-box
key | value
---------- | ---
date | 2024-02-22T08:27:57+00:00
version | 2.3.0b1
class | feature
edition | cre
component | checks
level | 2
compatible | yes
Previously, users were required to install an additional plugin to
determine the state of a network interface on Windows.
With the current release, this functionality is now integrated directly into the
Windows agent, eliminating the need for extra plugins.
For enhanced consistency across operating systems, network interfaces that are
operational are now marked as `up`, and those that are not available are marked
as `down`, aligning with the terminology used on Linux.
[//]: # (werk v2)
# kaspersky_av: Don't run kav4fs-control or kesl-control if they aren't owned by root
key | value
---------- | ---
date | 2024-02-27T09:14:50+00:00
version | 2.3.0b1
class | security
edition | cre
component | checks
level | 1
compatible | yes
Kaspersky Anti-Virus plugin uses /opt/kaspersky/kav4fs/bin/kav4fs-control and
/opt/kaspersky/kesl/bin/kesl-control commands to monitor a Kaspersky Anti-Virus
installation.
To prevent privilege escalation, the plugin (which is run by root user) must
not run executables which can be changed by less privileged users.
In the default installation, kav4fs-control and kesl-control commands are owned
by root and root is the only user with write permissions, which prevents privilege
escalation attacks.
With this Werk, the plugin checks if control commands are owned by root and root
is the only user with write permissions before running the command. If that's not
the case the commands won't be run. This prevents privilege escalation attacks if
the permissions of the control commands have been changed.
We rate this with a CVSS of 0 (None) (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N).
This CVSS is primarily meant to please automatic scanners.
[//]: # (werk v2)
# service_discovery: allow discovery on fresh remote host
key | value
---------- | ---
compatible | yes
version | 2.3.0b1
date | 2024-02-22T16:55:08+00:00
level | 1
class | fix
component | rest-api
edition | cre
The werk 16465 addressed a problem that prevented fetching
information about the service discovery background job on a
remote site. However, this solution introduced a new limitation,
disallowing the execution of discovery in 'refresh' and
'tabula_rasa' modes for newly created hosts on remote sites.
This werk successfully resolves this subsequent issue.
[//]: # (werk v2)
# service discovery: introduce functionality to fetch job status from remote sites
key | value
---------- | ---
compatible | yes
version | 2.3.0b1
date | 2024-01-29T10:23:24+00:00
level | 1
class | fix
component | rest-api
edition | cre
Prior to this werk, the service discovery endpoints were restricted to the local
service discovery background job. This resulted in the following endpoints being
restricted to local setups only:
* Show the last service discovery background job on a host
* Wait for service discovery completion
This werk fixes this and now also supports distributed monitoring setups. To benefit
from this change both the central site as well the remote sites need to be updated
to the werk's version. This change does not affect local only setups.
[//]: # (werk v2)
# Cleanup old Microcore config during update procedure
key | value
---------- | ---
date | 2024-02-27T09:23:01+00:00
version | 2.3.0b1
class | fix
edition | cre
component | core
level | 1
compatible | yes
This change prevents a problem which might occur in case the `omd update` did
not finish successfully. In this situation, the Microcore might be started with
a configuration file from the previous version. This could lead to unexpected
behavior.
Instead of keeping the old configuration, the update procedure now deletes the
file which makes the Microcore fail during startup with a more helpful error
message.
[//]: # (werk v2)
# Privilege escalation in Windows agent
key | value
---------- | ---
compatible | yes
version | 2.3.0b1
date | 2024-02-26T14:44:18+00:00
level | 1
class | security
component | checks
edition | cre
In order to execute some system commands Checkmk Windows agent writes cmd files to `C:\Windows\Temp\` and afterwards executes them.
The permissions of the files were set restrictive but existing files were not properly handled.
If a cmd file already existed and was write protected the agent was not able to rewrite the file but did not handle this case and executed the file nevertheless.
We thank Michael Baer (SEC Consult Vulnerability Lab) for reporting this issue.
**Affected Versions**:
* 2.2.0
* 2.1.0
* 2.0.0
**Indicators of Compromise**:
The filename of the cmd file needed to be guessed therefore the proof-of-concept creates a lot of files in `C\Windows\Temp` with the filename `cmk_all_\d+_1.cmd`.
These file-creation events could be monitored.
**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 assigned CVE-2024-0670 to this vulnerability.
**Changes**:
This Werk changes the temp folder and adds a subfolder with more restrictive permissions in which the files are created.
Also errors are handled better.
[//]: # (werk v2)
# Make EC UPDATE command use a list of events
key | value
---------- | ---
date | 2024-02-26T14:48:45+00:00
version | 2.3.0b1
class | fix
edition | cee
component | ec
level | 1
compatible | yes
Event Console UPDATE command accepts a list of events instead of a single event.
With this change the GUI will send a list of events to be updated to the Event Console.
This allows for multiple events to be updated in a single command. Avoids the situation where
some events are updated and others are not.