Checkmk werks level1 June 2024

checkmk-werks-lvl1@lists.checkmk.com

1 participants
272 discussions

[2.4.0] Checkmk Werk 16434 adapted: Synthetic Monitoring: Privilege Escalation

by Checkmk werks level 1

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.4.0b1 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 vunerable 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` and requested a CVE. ------------------------------------<diff>------------------------------------------- [//]: # (werk v2) # Synthetic Monitoring: Privilege Escalation key | value ---------- | --- date | 2024-06-24T14:56:31+00:00 version | 2.4.0b1 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 vunerable 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` and requested a CVE.

2 months, 3 weeks

[2.4.0] Checkmk Werk 17001 created: Enable several host actions no matter the tree depth of existing hosts

by Checkmk werks level 1

[//]: # (werk v2) # Enable several host actions no matter the tree depth of existing hosts key | value ---------- | --- date | 2024-06-24T11:19:49+00:00 version | 2.4.0b1 class | fix edition | cre component | multisite level | 1 compatible | yes This Werk fixes the previous [Werk #16638](https://checkmk.com/werk/16638). For host actions "Run bulk service discovery", "Rename multiple hosts" and "Detect network parent hosts" only hosts in the current folder and in the first level subfolders were taken into account. This is fixed to the expected recursive behavior: If a host exists in the current folder or any of its subfolders - no matter their tree depth - the host actions are enabled.

2 months, 3 weeks

[2.4.0] Checkmk Werk 16878 created: global_settings: enable 'Hide Checkmk version' per default

by Checkmk werks level 1

[//]: # (werk v2) # global_settings: enable 'Hide Checkmk version' per default key | value ---------- | --- date | 2024-06-26T09:01:06+00:00 version | 2.4.0b1 class | security edition | cre component | wato level | 1 compatible | yes Displaying the version number on the login screen is generally regarded as a security risk because it can enable attackers to identify potential vulnerabilities associated with that specific version. Consequently, we have changed the default setting to hide the version number. Users who wish to view the version number can manually enable this option through the Global Settings. It should be highlighted that users who have previously set this option to show the version will not be affected by this change. To aid automated scanning we assign a CVSS score of 0.0 (None) (`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N`).

2 months, 3 weeks

[2.4.0] Checkmk Werk 17031 created: TrippLite UPS: discover devices with .1.3.6.1.4.1.850.1 as sysObjectID

by Checkmk werks level 1

[//]: # (werk v2) # TrippLite UPS: discover devices with .1.3.6.1.4.1.850.1 as sysObjectID key | value ---------- | --- date | 2024-06-26T16:13:34+00:00 version | 2.4.0b1 class | feature edition | cre component | checks level | 1 compatible | yes TrippLite UPSs use OID .1.3.6.1.4.1.850.1 as sysObjectID. These devices are currently not discovered and monitored. This has now been changed and they will be discovered.

2 months, 3 weeks

[2.4.0] Checkmk Werk 17080 created: Hanging background jobs/frozen site

by Checkmk werks level 1

[//]: # (werk v2) # Hanging background jobs/frozen site key | value ---------- | --- date | 2024-06-26T12:45:00+00:00 version | 2.4.0b1 class | fix edition | cee component | multisite level | 1 compatible | yes Background jobs could previously hang without ever finishing under the wrong conditions. This could lead to the entire site freezing if the job had acquired crucial file locks (i.e. a lock on licensing files). This is usually accompanied by the error ``` Bad file descriptor ``` in the logs.

2 months, 3 weeks

[2.4.0] Checkmk Werk 16435 created: agent_netapp_ontap: Fix TypeError for SnapVault

by Checkmk werks level 1

[//]: # (werk v2) # agent_netapp_ontap: Fix TypeError for SnapVault key | value ---------- | --- date | 2024-06-26T11:18:02+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes Previously, `agent_netapp_ontap` would crash if the API returned any `SnapMirror` objects: ``` File "/omd/sites/mysite/local/lib/python3/cmk/special_agents/agent_netapp_ontap.py", line 827, in write_sections write_section("snapvault", fetch_snapmirror(connection), logger) File "/omd/sites/mysite/local/lib/python3/cmk/special_agents/agent_netapp_ontap.py", line 32, in write_section writer.append_json(element.model_dump(exclude_unset=True, exclude_none=False)) File "/omd/sites/mysite/lib/python3/cmk/special_agents/v0_unstable/agent_common.py", line 62, in append_json self.writeline(json.dumps(data, sort_keys=True)) File "/omd/sites/mysite/lib/python3.12/json/__init__.py", line 238, in dumps **kw).encode(obj) File "/omd/sites/mysite/lib/python3.12/json/encoder.py", line 200, in encode chunks = self.iterencode(o, _one_shot=True) File "/omd/sites/mysite/lib/python3.12/json/encoder.py", line 258, in iterencode return _iterencode(o, 0) File "/omd/sites/mysite/lib/python3.12/json/encoder.py", line 180, in default raise TypeError(f'Object of type {o.__class__.__name__} ' ```

2 months, 3 weeks

[2.2.0] Checkmk Werk 17000 created: Preserve search term after deletion of topics, bookmarks or custom sidebar elements

by Checkmk werks level 1

Title: Preserve search term after deletion of topics, bookmarks or custom sidebar elements Class: fix Compatible: compat Component: multisite Date: 1718097357 Edition: cre Level: 1 Version: 2.2.0p28 Recently, deleting topics, bookmarks or custom sidebar elements under "Customize" led to a page reload that ignored a given inpage search ("Find on this page ..."). This is fixed to preserving the search term after deletion.

2 months, 3 weeks

[2.2.0] Checkmk Werk 17057 created: Use correct filter for virtual host tree links

by Checkmk werks level 1

Title: Use correct filter for virtual host tree links Class: fix Compatible: compat Component: multisite Date: 1719321845 Edition: cre Level: 1 Version: 2.2.0p28 Since 2.2.0 the virtual host tree links for "Show the service problems contained in this branch" missed the filters for "service states" (WARN/CRIT/UNKN) and "downtimes" (no).

2 months, 3 weeks

[2.3.0] Checkmk Werk 16716 created: Mitigate timing-unsafe comparisons to prevent byte-by-byte brute forcing attack

by Checkmk werks level 1

[//]: # (werk v2) # Mitigate timing-unsafe comparisons to prevent byte-by-byte brute forcing attack key | value ---------- | --- date | 2024-06-25T10:10:15+00:00 version | 2.3.0p8 class | security edition | cee component | agents level | 1 compatible | yes A theorical brute force attack could be performed due to timing-unsafe secrets comparison. This fix changes the way secrets are verified in communication with the agent. To aid automated scanning we assign a CVSS score of 0.0 (None) (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N).

2 months, 3 weeks

[2.3.0] Checkmk Werk 17057 created: Use correct filter for virtual host tree links

by Checkmk werks level 1

[//]: # (werk v2) # Use correct filter for virtual host tree links key | value ---------- | --- compatible | yes version | 2.3.0p8 date | 2024-06-25T13:24:05+00:00 level | 1 class | fix component | multisite edition | cre Since 2.2.0 the virtual host tree links for "Show the service problems contained in this branch" missed the filters for "service states" (WARN/CRIT/UNKN) and "downtimes" (no).

2 months, 3 weeks

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level1 June 2024