[//]: # (werk v2)
# Update OpenSSL to version 3.0.13
key | value
---------- | ---
date | 2024-04-17T10:08:23+00:00
version | 2.4.0b1
class | security
edition | cre
component | omd
level | 1
compatible | yes
OpenSSL was updated to version 3.0.13.
OpenSSL 3 uses requirements regarding allowed configurations, such as allowed ciphers, renegotiation, and so on.
In some scenarios, this can break monitoring for hosts with TLS configurations that are no longer considered secure.
We have published a blog post to help you mitigate these issues, should they affect you: https://checkmk.com/blog/how-monitor-servers-broken-tls-checkmk.
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).
[//]: # (werk v2)
# Brute-force protection ineffective for some login methods
key | value
---------- | ---
date | 2024-04-09T12:24:12+00:00
version | 2.4.0b1
class | security
edition | cre
component | wato
level | 1
compatible | yes
Prior to this Werk, the mechanism to lock user accounts after too many failed login attempts was only effective for the web form login method.
Login attempts via the REST API and basic authentication did not count towards the lockout mechanism.
As a result, an attacker could try to brute-force user passwords without triggering the lockout mechanism.
This Werk adds the same locking mechanism to login via the REST API and basic authentication _for human user accounts_.
Note that automation accounts are remain unaffected by the lockout mechanism to avoid having them locked by malicious intent.
It is therefore important to use long, random automation secrets.
This issue was found during internal review.
**Affected Versions**:
* 2.3.0 (beta)
* 2.2.0
* 2.1.0
* 2.0.0 (EOL)
**Mitigations**:
If updating is not possible, the brute-force attempts can be hindered by using a strong password policy.
**Vulnerability Management**:
We have rated the issue with a CVSS Score of 5.9 (Medium) with the following CVSS vector: `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N`
and assigned CVE `CVE-2024-28825`.
Title: check_mailboxes: Fixed handling of error "Not allowed to access Non IPM folder."
Class: fix
Compatible: compat
Component: packages
Date: 1712910849
Edition: cre
Level: 1
Version: 2.1.0p42
Due to a recent change in Microsoft 365, the access to Exchange mailbox folders via the active check <code>check_mailboxes</code> could fail with an error message like this:
C+:
Unhandled exception: ErrorAccessDenied('Not allowed to access Non IPM folder.')
C-:
With this werk we update the version of the package <code>exchangelib</code> to v5.2.1, fixing the respective error handling.
Werk 15843 was adapted. The following is the new Werk, a diff is shown at the end of the message.
Title: mk_oracle(ps1): Follow-up to privilege escalation fix
Class: fix
Compatible: incomp
Component: checks
Date: 1712314947
Edition: cre
Level: 2
Version: 2.2.0p25
You might be affected by this Werk if you use <tt>mk_oracle</tt> on Windows.
Werk <a href="https://checkmk.com/werk/16232">Werk #16232</a> introduced a
regression, thereby disrupting Oracle monitoring on Windows.
This Werk addresses above mentioned issue that affects versions 2.1.0p41,
2.2.0p24, and 2.3.0b4.
Since this release, Oracle monitoring on Windows is fully supported under
either of the following conditions:
1. The monitoring is performed using an account without administrator rights.
2. Specific Oracle executable binaries — namely, <tt>sqlplus.exe</tt>,
<tt>tnsping.exe</tt> and, if presented, <tt>crsctl.exe</tt> - are not modifiable
by non-admin users.
If you are still unable to monitor Oracle, for example, you can't use an
unprivileged account for monitoring and changing of permission is not possible,
consider one of the following actions:
1. Enable <tt>Run as local group</tt> for group <tt>Administrators</tt> in
<tt>Run plugins and local checks using non-system account</tt> ruleset.
2. Adjust <tt>Oracle Binaries Permissions Check</tt> settings in <tt>ORACLE databases (Linux,
Solaris, AIX, Windows)</tt> ruleset.
More information about can be found at <a href="https://checkmk.atlassian.net/wiki/x/AQA1B">here</a>.
------------------------------------<diff>-------------------------------------------
Title: mk_oracle(ps1): Follow-up to privilege escalation fix
Class: fix
Compatible: incomp
Component: checks
Date: 1712314947
Edition: cre
Level: 2
Version: 2.2.0p25
You might be affected by this Werk if you use <tt>mk_oracle</tt> on Windows.
Werk <a href="https://checkmk.com/werk/16232">Werk #16232</a> introduced a
regression, thereby disrupting Oracle monitoring on Windows.
This Werk addresses above mentioned issue that affects versions 2.1.0p41,
2.2.0p24, and 2.3.0b4.
- Since this release, Oracle monitoring on Windows is fully supported under
? -
+ Since this release, Oracle monitoring on Windows is fully supported under
- condition you use an account without administrator rights or the certain
- executable binaries, <tt>sqlplus.exe</tt>, <tt>tnsping.exe</tt> and, if
- presented, <tt>crsctl.exe</tt> are write-protected, with the possible
- exception being the Administrator.
+ either of the following conditions:
+ 1. The monitoring is performed using an account without administrator rights.
+ 2. Specific Oracle executable binaries — namely, <tt>sqlplus.exe</tt>,
+ <tt>tnsping.exe</tt> and, if presented, <tt>crsctl.exe</tt> - are not modifiable
+ by non-admin users.
- If you are unable or prefer not to use an unprivileged account then you may
- need to adjust permissions for above mentioned binaries: remove <tt>Write</tt>,
- <tt>Full Control</tt> and <tt>Modify</tt> permissions for any non-Administrator
- user and group.
+ If you are still unable to monitor Oracle, for example, you can't use an
+ unprivileged account for monitoring and changing of permission is not possible,
+ consider one of the following actions:
+ 1. Enable <tt>Run as local group</tt> for group <tt>Administrators</tt> in
+ <tt>Run plugins and local checks using non-system account</tt> ruleset.
+ 2. Adjust <tt>Oracle Binaries Permissions Check</tt> settings in <tt>ORACLE databases (Linux,
+ Solaris, AIX, Windows)</tt> ruleset.
More information about can be found at <a href="https://checkmk.atlassian.net/wiki/x/AQA1B">here</a>.
+
Title: agent_netapp_ontap: handle shelves without elements
Class: fix
Compatible: compat
Component: checks
Date: 1712751995
Edition: cre
Level: 1
Version: 2.2.0p25
The agent did not handle the cases where shelves had no fans, temperature sensors or PSUs.
This led to crashes during the agent execution.
With this werk we now correctly handle these scenarios and the corresponding services are not discovered if no items are found.
[//]: # (werk v2)
# time_periods: Fix timeperiod iCalendar (ics) import
key | value
---------- | ---
date | 2024-04-17T09:19:29+00:00
version | 2.4.0b1
class | fix
edition | cre
component | wato
level | 1
compatible | yes
This Werk solves a problem with importing events that take more than
one day. Before this Werk, only the first day of the event was
imported. Now all days involved are imported.
[//]: # (werk v2)
# mk_postgres.py: Add 'PG_BINARY_PATH' to Bakery Rule
key | value
---------- | ---
date | 2024-04-16T15:15:06+00:00
version | 2.4.0b1
class | feature
edition | cee
component | agents
level | 1
compatible | yes
[Werk #15619](https://checkmk.com/werk/15619) added support for reading `PG_BINARY_PATH` from
`postgres.cfg`. This Werk allows setting this value with the agent bakery.
[//]: # (werk v2)
# Inventory: Add Windows support for Hardware > System > Uuid
key | value
---------- | ---
date | 2024-04-16T13:09:47+00:00
version | 2.4.0b1
class | feature
edition | cre
component | inv
level | 1
compatible | yes
This element is already available for Linux, now the windows agent also supports
reading this value.
You have to update `mk_inventory.vbs` on the monitored host, to provide the
necessary data.