Checkmk werks level1

checkmk-werks-lvl1@lists.checkmk.com

1 participants
15873 discussions

[2.4.0] Checkmk Werk 15328 adapted: mk_oracle: Follow-up to privilege escalation fix: sqlnet.ora

by Checkmk werks level 1

Werk 15328 was adapted. The following is the new Werk, a diff is shown at the end of the message. [//]: # (werk v2) # mk_oracle: Follow-up to privilege escalation fix: sqlnet.ora key | value ---------- | --- compatible | no version | 2.4.0b1 date | 2024-04-05T09:38:28+00:00 level | 1 class | fix component | checks edition | cre You are affected by this Werk if you use mk_oracle agent plugin on unix. <tt>mk_oracle</tt> only works if it can find a <tt>sqlnet.ora</tt> in your <tt>$TNS_ADMIN</tt> folder. In the past, <tt>mk_oracle</tt> executed all oracle binaries as root, so <tt>sqlnet.ora</tt> was always readable. With <a href="https://checkmk.com/werk/16232">Werk #16232</a> the oracle binaries are executed with a low privileged user, so it might be the case, that <tt>sqlnet.ora</tt> can not be read by this user. <tt>mk_oracle</tt> will exit early if it can not read <tt>sqlnet.ora</tt>. The error message might look like: <code> /etc/check_mk/sqlnet.ora can not be read by user "oracle"! Either use 'sqlnet.ora permission group' bakery rule, or directly modify permissions of the file. </code> The error message will also be visible in the <tt>oracle_instance</tt> check. If you use the agent bakery to roll out mk_oracle to unix servers using <tt>.rpm</tt>, <tt>.deb</tt> or Solaris <tt>.pkg</tt> packages, you have to use the 'sqlnet.ora permission group' bakery rule to adapt the group of the <tt>sqlnet.ora</tt> file, otherwise your permission changes might be overwritten by updating the agent. Otherwise, it is sufficient to adapt the permissions. If you install the agent on Unix using the <tt>tgz</tt> package, you will have to manually adjust the permissions of the <tt>sqlnet.ora</tt> file. ------------------------------------<diff>------------------------------------------- [//]: # (werk v2) # mk_oracle: Follow-up to privilege escalation fix: sqlnet.ora key | value ---------- | --- compatible | no version | 2.4.0b1 date | 2024-04-05T09:38:28+00:00 level | 1 class | fix component | checks edition | cre You are affected by this Werk if you use mk_oracle agent plugin on unix. <tt>mk_oracle</tt> only works if it can find a <tt>sqlnet.ora</tt> in your <tt>$TNS_ADMIN</tt> folder. In the past, <tt>mk_oracle</tt> executed all oracle - binaries as root, so <tt>sqlnet.ora</tt> was alwas readable. With <a + binaries as root, so <tt>sqlnet.ora</tt> was always readable. With <a ? + href="https://checkmk.com/werk/16232">Werk #16232</a> the oracle binaries are executed with a low privileged user, so it might be the case, that <tt>sqlnet.ora</tt> can not be read by this user. <tt>mk_oracle</tt> will exit early if it can not read <tt>sqlnet.ora</tt>. The error message might look like: <code> /etc/check_mk/sqlnet.ora can not be read by user "oracle"! Either use 'sqlnet.ora permission group' bakery rule, or directly modify permissions of the file. </code> The error message will also be visible in the <tt>oracle_instance</tt> check. If you use the agent bakery to roll out mk_oracle to unix servers using <tt>.rpm</tt>, <tt>.deb</tt> or Solaris <tt>.pkg</tt> packages, you have to use the 'sqlnet.ora permission group' bakery rule to adapt the group of the <tt>sqlnet.ora</tt> file, otherwise your permission changes might be overwritten by updating the agent. - Otherwise it is sufficient to adapt the permissions. + Otherwise, it is sufficient to adapt the permissions. ? + If you install the agent on Unix using the <tt>tgz</tt> package, you will have to manually adjust the permissions of the <tt>sqlnet.ora</tt> file. +

2 months

[2.4.0] Checkmk Werk 16248 created: Set group on sqlnet.ora for custom installation paths

by Checkmk werks level 1

[//]: # (werk v2) # Set group on sqlnet.ora for custom installation paths key | value ---------- | --- date | 2024-07-16T06:35:14+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes You're affected by this werk, if you are monitoring oracle databases and the agent bakery. Since [Werk #15328](https://checkmk.com/werk/15328), the group ownership of `sqlnet.ora` can be set via the agent updater. However, the bakery did not yet honor custom installation paths, which are set via the rule `"Installation paths for agent files (Linux, UNIX)"`. From this werk on, the bakery and the agent updater do also set the configured group on `sqlnet.ora`.

2 months

[2.1.0] Checkmk Werk 16117 created: Fix path for snmpget in check_snmp and check_hpjd

by Checkmk werks level 1

Title: Fix path for snmpget in check_snmp and check_hpjd Class: fix Compatible: compat Component: checks Date: 1721119141 Edition: cre Level: 1 Version: 2.1.0p47 Werk 13585 introduced a bug in the path calculation for snmpget, so the check_snmp and check_hpjd active checks failed randomly. This has been fixed.

2 months

[2.1.0] Checkmk Werk 17092 adapted: Fix missing CSRF token issues

by Checkmk werks level 1

Werk 17092 was adapted. The following is the new Werk, a diff is shown at the end of the message. Title: Fix missing CSRF token issues Class: fix Compatible: compat Component: wato Date: 1719997630 Edition: cre Level: 1 Version: 2.1.0p45 Werk #17090 in Checkmk 2.3.0p8 and 2.2.0p29 introduced additional CSRF token checks in the GUI. This caused some buttons to not work anymore because the CSRF token was missing, including, but likely not limited to: LI: "Synchronize users" in Setup > Users to manually trigger the LDAP sync (the background sync still runs) LI: "Show analysis" and "Show bulks" in Setup > Events > Notifications LI: Reordering notification rules via drag-and-drop in the same view LI: "Bake agents" in the agent bakery (as a workaround, use "Bake and sign agents") LI: "Acknowledge last baking result" when a bake job failed (as a workaround, delete the failed job instead) This Werk fixes the issues by adding the token. ------------------------------------<diff>------------------------------------------- Title: Fix missing CSRF token issues Class: fix Compatible: compat Component: wato Date: 1719997630 Edition: cre Level: 1 - Version: 2.1.0p47 ? ^ + Version: 2.1.0p45 ? ^ Werk #17090 in Checkmk 2.3.0p8 and 2.2.0p29 introduced additional CSRF token checks in the GUI. This caused some buttons to not work anymore because the CSRF token was missing, including, but likely not limited to: LI: "Synchronize users" in Setup > Users to manually trigger the LDAP sync (the background sync still runs) LI: "Show analysis" and "Show bulks" in Setup > Events > Notifications LI: Reordering notification rules via drag-and-drop in the same view LI: "Bake agents" in the agent bakery (as a workaround, use "Bake and sign agents") LI: "Acknowledge last baking result" when a bake job failed (as a workaround, delete the failed job instead) This Werk fixes the issues by adding the token.

2 months

[2.1.0] Checkmk Werk 17115 adapted: HPE Proliant Servers: RAID Controllers: Adapt to changes in iLO firmware

by Checkmk werks level 1

Werk 17115 was adapted. The following is the new Werk, a diff is shown at the end of the message. Title: HPE Proliant Servers: RAID Controllers: Adapt to changes in iLO firmware Class: fix Compatible: compat Component: checks Date: 1720613772 Edition: cre Level: 1 Version: 2.1.0p47 This fixes crashes in the plugin "HPE Proliant Servers: RAID Controllers". A recent update of the HPE iLO firmware left Checkmk unable to interpret some of the reported states. ------------------------------------<diff>------------------------------------------- Title: HPE Proliant Servers: RAID Controllers: Adapt to changes in iLO firmware Class: fix Compatible: compat Component: checks Date: 1720613772 Edition: cre Level: 1 - Version: 2.1.0p46 ? ^ + Version: 2.1.0p47 ? ^ This fixes crashes in the plugin "HPE Proliant Servers: RAID Controllers". A recent update of the HPE iLO firmware left Checkmk unable to interpret some of the reported states.

2 months

[2.1.0] Checkmk Werk 17115 created: HPE Proliant Servers: RAID Controllers: Adapt to changes in iLO firmware

by Checkmk werks level 1

Title: HPE Proliant Servers: RAID Controllers: Adapt to changes in iLO firmware Class: fix Compatible: compat Component: checks Date: 1720613772 Edition: cre Level: 1 Version: 2.1.0p46 This fixes crashes in the plugin "HPE Proliant Servers: RAID Controllers". A recent update of the HPE iLO firmware left Checkmk unable to interpret some of the reported states.

2 months

[2.1.0] Checkmk Werk 17011 adapted: Fix local IP restriction of internal HTTP endpoints

by Checkmk werks level 1

Werk 17011 was adapted. The following is the new Werk, a diff is shown at the end of the message. Title: Fix local IP restriction of internal HTTP endpoints Class: security Compatible: compat Component: wato Date: 1718804769 Edition: cre Level: 1 Version: 2.1.0p47 Checkmk has some complex functionalities that are hidden behind an internal HTTP endpoint page. These pages are only meant to be accessed by internal processes, e.g. a cron runner or creating diagrams for notifications. Therefore these pages are protected to be only accessible locally. In order to recognize the client IP through the usage of a reverse proxy Checkmk uses the <code>X-Forwarded-For</code> header. That header is added and complemented by <code>mod_proxy</code> and usually trustworthy. When the site apache is exposed directly to the network though (e.g. the default docker setup) no proxy apache is there to curate this header. To mitigate this the site apache is supposed to filter these internal page URIs to be only accessible by localhost. This mitigation failed due to some outdated configuration and wrong configuration ordering. This only affects systems which expose the site apache port to the network typically 5000. If you run Checkmk behind a reverse proxy (the default if you installed a installation package) you are not affected! This vulnerability was identified in a commissioned penetration test conducted by PS Positive Security GmbH. Affected Versions: LI: 2.3.0 LI: 2.2.0 LI: 2.1.0 LI: 2.0.0 (probably older versions as well) Mitigations: You can add the following configuration to the site apache configuration, e.g. <code>etc/apache/conf.d/zzz_werk17011.conf</code>: C+: <Location "/###SITE###/check_mk/run_cron.py"> Order deny,allow Deny from all Require local Satisfy any </Location> # Webservice for graph images used by notifications <Location "/###SITE###/check_mk/ajax_graph_images.py"> Order deny,allow Deny from all Require local Satisfy any </Location> C-: Indicators of Compromise: You can check the apache access log <code>var/log/apache/access_log</code> for calls to <code>run_cron.py</code> or <code>ajax_graph_images.py</code> from network hosts. E.g. <code>grep --extended-regexp "^[^-].+(run_cron|ajax_graph_images.py)" var/log/apache/access_log</code> Vulnerability Management: We have rated the issue with a CVSS Score of 5.3 (Medium) with the following CVSS vector: <code>CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N</code>. We assigned CVE-2024-6163 to this vulnerability. Changes: This Werk fixes the configuration syntax and ordering. ------------------------------------<diff>------------------------------------------- Title: Fix local IP restriction of internal HTTP endpoints Class: security Compatible: compat Component: wato Date: 1718804769 Edition: cre Level: 1 - Version: 2.1.0p46 ? ^ + Version: 2.1.0p47 ? ^ Checkmk has some complex functionalities that are hidden behind an internal HTTP endpoint page. These pages are only meant to be accessed by internal processes, e.g. a cron runner or creating diagrams for notifications. Therefore these pages are protected to be only accessible locally. In order to recognize the client IP through the usage of a reverse proxy Checkmk uses the <code>X-Forwarded-For</code> header. That header is added and complemented by <code>mod_proxy</code> and usually trustworthy. When the site apache is exposed directly to the network though (e.g. the default docker setup) no proxy apache is there to curate this header. To mitigate this the site apache is supposed to filter these internal page URIs to be only accessible by localhost. This mitigation failed due to some outdated configuration and wrong configuration ordering. This only affects systems which expose the site apache port to the network typically 5000. If you run Checkmk behind a reverse proxy (the default if you installed a installation package) you are not affected! This vulnerability was identified in a commissioned penetration test conducted by PS Positive Security GmbH. Affected Versions: LI: 2.3.0 LI: 2.2.0 LI: 2.1.0 LI: 2.0.0 (probably older versions as well) Mitigations: You can add the following configuration to the site apache configuration, e.g. <code>etc/apache/conf.d/zzz_werk17011.conf</code>: C+: <Location "/###SITE###/check_mk/run_cron.py"> Order deny,allow Deny from all Require local Satisfy any </Location> # Webservice for graph images used by notifications <Location "/###SITE###/check_mk/ajax_graph_images.py"> Order deny,allow Deny from all Require local Satisfy any </Location> C-: Indicators of Compromise: You can check the apache access log <code>var/log/apache/access_log</code> for calls to <code>run_cron.py</code> or <code>ajax_graph_images.py</code> from network hosts. E.g. <code>grep --extended-regexp "^[^-].+(run_cron|ajax_graph_images.py)" var/log/apache/access_log</code> Vulnerability Management: We have rated the issue with a CVSS Score of 5.3 (Medium) with the following CVSS vector: <code>CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N</code>. We assigned CVE-2024-6163 to this vulnerability. Changes: This Werk fixes the configuration syntax and ordering.

2 months

[2.1.0] Checkmk Werk 17092 adapted: Fix missing CSRF token issues

by Checkmk werks level 1

Werk 17092 was adapted. The following is the new Werk, a diff is shown at the end of the message. Title: Fix missing CSRF token issues Class: fix Compatible: compat Component: wato Date: 1719997630 Edition: cre Level: 1 Version: 2.1.0p47 Werk #17090 in Checkmk 2.3.0p8 and 2.2.0p29 introduced additional CSRF token checks in the GUI. This caused some buttons to not work anymore because the CSRF token was missing, including, but likely not limited to: LI: "Synchronize users" in Setup > Users to manually trigger the LDAP sync (the background sync still runs) LI: "Show analysis" and "Show bulks" in Setup > Events > Notifications LI: Reordering notification rules via drag-and-drop in the same view LI: "Bake agents" in the agent bakery (as a workaround, use "Bake and sign agents") LI: "Acknowledge last baking result" when a bake job failed (as a workaround, delete the failed job instead) This Werk fixes the issues by adding the token. ------------------------------------<diff>------------------------------------------- Title: Fix missing CSRF token issues Class: fix Compatible: compat Component: wato Date: 1719997630 Edition: cre Level: 1 - Version: 2.1.0p45 ? ^ + Version: 2.1.0p47 ? ^ Werk #17090 in Checkmk 2.3.0p8 and 2.2.0p29 introduced additional CSRF token checks in the GUI. This caused some buttons to not work anymore because the CSRF token was missing, including, but likely not limited to: LI: "Synchronize users" in Setup > Users to manually trigger the LDAP sync (the background sync still runs) LI: "Show analysis" and "Show bulks" in Setup > Events > Notifications LI: Reordering notification rules via drag-and-drop in the same view LI: "Bake agents" in the agent bakery (as a workaround, use "Bake and sign agents") LI: "Acknowledge last baking result" when a bake job failed (as a workaround, delete the failed job instead) This Werk fixes the issues by adding the token.

2 months

[2.1.0] Checkmk Werk 17063 adapted: Delete PDF tmp files older one day

by Checkmk werks level 1

Werk 17063 was adapted. The following is the new Werk, a diff is shown at the end of the message. Title: Delete PDF tmp files older one day Class: fix Compatible: compat Component: wato Date: 1720422296 Edition: cre Level: 1 Version: 2.1.0p47 Werk #15125 introduced a cleanup mechanism for old PFD tmp files but deleted files older 48hours. Now files older than one day are deleted. ------------------------------------<diff>------------------------------------------- Title: Delete PDF tmp files older one day Class: fix Compatible: compat Component: wato Date: 1720422296 Edition: cre Level: 1 - Version: 2.1.0p46 ? ^ + Version: 2.1.0p47 ? ^ Werk #15125 introduced a cleanup mechanism for old PFD tmp files but deleted files older 48hours. Now files older than one day are deleted.

2 months

[2.1.0] Checkmk Werk 17078 adapted: MS Exchange: Use consistent units (ms/s) in rules & graphs

by Checkmk werks level 1

Werk 17078 was adapted. The following is the new Werk, a diff is shown at the end of the message. Title: MS Exchange: Use consistent units (ms/s) in rules & graphs Class: fix Compatible: compat Component: checks Date: 1720433457 Edition: cre Level: 1 Version: 2.1.0p47 The checks msexch_isclienttype, msexch_isstore, msexch_rpcclientaccess reported their values in ms in the summary/ruleset but displayed the same value as seconds in the graph. With this werk, all MS Exchange checks now report their values consistently. ------------------------------------<diff>------------------------------------------- Title: MS Exchange: Use consistent units (ms/s) in rules & graphs Class: fix Compatible: compat Component: checks Date: 1720433457 Edition: cre Level: 1 - Version: 2.1.0p46 ? ^ + Version: 2.1.0p47 ? ^ The checks msexch_isclienttype, msexch_isstore, msexch_rpcclientaccess reported their values in ms in the summary/ruleset but displayed the same value as seconds in the graph. With this werk, all MS Exchange checks now report their values consistently.

2 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level1