Icinga 2 DSL Injection via Unescaped Import Template Name
Icinga 2 is an open source monitoring system. From 2.4 until 2.14.9, 2.15.4, and 2.16.2, the /v1/objects API writes attacker-controlled template names into generated configuration without escaping them. An authenticated ApiUser with an objects/create/* permission can inject Icinga 2 DSL configuration, escape the intended object, create additional objects, and exceed the user's assigned privileges. This issue is fixed in versions 2.14.9, 2.15.4, and 2.16.2.
Icinga 2: Stack overflow via deeply nested JSON objects
Icinga 2 is an open source monitoring system. Prior to 2.14.9, 2.15.4, and 2.16.2, parsing deeply nested JSON can exhaust the call stack because nesting depth is not bounded. The affected JSON parsing paths are reachable by unauthenticated network clients through the Icinga 2 service on TCP port 5665, allowing a remote attacker to crash the process, while possible code execution has not been demonstrated. This issue is fixed in versions 2.14.9, 2.15.4, and 2.16.2.
Icinga 2: Improper access control for JSON-RPC update certificate messages
Icinga 2 is an open source monitoring system. From 2.8 until 2.14.9, 2.15.4, and 2.16.2, certificate update JSON-RPC message handling does not validate that the sender is a trusted endpoint. An unauthenticated network attacker able to connect to TCP port 5665 can replace the node certificate and trusted CA certificate, impersonate a trusted node, and take control of the node. This issue is fixed in versions 2.14.9, 2.15.4, and 2.16.2.
Icinga 2 signals sent as root to processes based on PID file written by the Icinga 2 daemon user
Icinga 2 is an open source monitoring system. From 2.10.0 to before 2.15.1, 2.14.7, and 2.13.13, the safe-reload script (also used during systemctl reload icinga2) and logrotate configuration shipped with Icinga 2 read the PID of the main Icinga 2 process from a PID file writable by the daemon user, but send the signal as the root user. This can allow the Icinga user to send signals to processes it would otherwise not permitted to. A fix is included in the following Icinga 2 versions: 2.15.1, 2.14.7, and 2.13.13.
Icinga 2 Denial of Service (DoS) By Dereferencing Invalid Reference
Icinga 2 is an open source monitoring system. From 2.10.0 to before 2.15.1, 2.14.7, and 2.13.13, when creating an invalid reference, such as a reference to null, dereferencing results in a segmentation fault. This can be used by any API user with access to an API endpoint that allows specifying a filter expression to crash the Icinga 2 daemon. A fix is included in the following Icinga 2 versions: 2.15.1, 2.14.7, and 2.13.13.
Icinga 2 API users could access restricted values in filter expressions
Icinga 2 is an open source monitoring system. In Icinga 2 versions 2.4 through 2.15.0, filter expressions provided to the various /v1/objects endpoints could access variables or objects that would otherwise be inaccessible for the user. This allows authenticated API users to learn information that should be hidden from them, including global variables not permitted by the variables permission and objects not permitted by the corresponding objects/query permissions. The vulnerability is fixed in versions 2.15.1, 2.14.7, and 2.13.13.
Icinga 2 certificate renewal might incorrectly renew an invalid certificate
Icinga 2 is a monitoring system which checks the availability of network resources, notifies users of outages, and generates performance data for reporting. Prior to versions 2.12.12, 2.13.12, and 2.14.6, the VerifyCertificate() function can be tricked into incorrectly treating certificates as valid. This allows an attacker to send a malicious certificate request that is then treated as a renewal of an already existing certificate, resulting in the attacker obtaining a valid certificate that can be used to impersonate trusted nodes. This only occurs when Icinga 2 is built with OpenSSL older than version 1.1.0. This issue has been patched in v
Icinga 2 has a TLS Certificate Validation Bypass for JSON-RPC and HTTP API Connections
Icinga is a monitoring system which checks the availability of network resources, notifies users of outages, and generates performance data for reporting. The TLS certificate validation in all Icinga 2 versions starting from 2.4.0 was flawed, allowing an attacker to impersonate both trusted cluster nodes as well as any API users that use TLS client certificates for authentication (ApiUser objects with the client_cn attribute set). This vulnerability has been fixed in v2.14.3, v2.13.10, v2.12.11, and v2.11.12.
Missing TLS service certificate validation in GelfWriter, ElasticsearchWriter, InfluxdbWriter and Influxdb2Writer
Icinga is a monitoring system which checks the availability of network resources, notifies users of outages, and generates performance data for reporting. In versions 2.5.0 through 2.13.0, ElasticsearchWriter, GelfWriter, InfluxdbWriter and Influxdb2Writer do not verify the server's certificate despite a certificate authority being specified. Icinga 2 instances which connect to any of the mentioned time series databases (TSDBs) using TLS over a spoofable infrastructure should immediately upgrade to version 2.13.1, 2.12.6, or 2.11.11 to patch the issue. Such instances should also change the credentials (if any) used by the TSDB writer feature
Passwords used to access external services inadvertently exposed through API
Icinga is a monitoring system which checks the availability of network resources, notifies users of outages, and generates performance data for reporting. In versions prior to 2.11.10 and from version 2.12.0 through version 2.12.4, some of the Icinga 2 features that require credentials for external services expose those credentials through the API to authenticated API users with read permissions for the corresponding object types. IdoMysqlConnection and IdoPgsqlConnection (every released version) exposes the password of the user used to connect to the database. IcingaDB (added in 2.12.0) exposes the password used to connect to the Redis serve
Results of queries for ApiListener objects include the ticket salt which allows in turn to steal (more privileged) identities
Icinga is a monitoring system which checks the availability of network resources, notifies users of outages, and generates performance data for reporting. From version 2.4.0 through version 2.12.4, a vulnerability exists that may allow privilege escalation for authenticated API users. With a read-ony user's credentials, an attacker can view most attributes of all config objects including `ticket_salt` of `ApiListener`. This salt is enough to compute a ticket for every possible common name (CN). A ticket, the master node's certificate, and a self-signed certificate are enough to successfully request the desired certificate from Icinga. That ce
Icinga 2 v2.8.0 through v2.11.7 and v2.12.2 has an issue where revoked certificates due for renewal will automatically be renewed, ignoring the CRL. This issue is fixed in Icinga 2 v2.11.8 and v2.12.3.
An issue was discovered in Icinga2 before v2.12.0-rc1. The prepare-dirs script (run as part of the icinga2 systemd service) executes chmod 2750 /run/icinga2/cmd. /run/icinga2 is under control of an unprivileged user by default. If /run/icinga2/cmd is a symlink, then it will by followed and arbitrary files can be changed to mode 2750 by the unprivileged icinga2 user.
An issue was discovered in Icinga 2.x through 2.8.1. The lack of a constant-time password comparison function can disclose the password to an attacker.
An issue was discovered in Icinga 2.x through 2.8.1. By sending specially crafted messages, an attacker can cause a NULL pointer dereference, which can cause the product to crash.
An issue was discovered in Icinga 2.x through 2.8.1. By editing the init.conf file, Icinga 2 can be run as root. Following this the program can be used to run arbitrary code as root. This was fixed by no longer using init.conf to determine account information for any root-executed code (a larger issue than CVE-2017-16933).
An issue was discovered in Icinga 2.x through 2.8.1. By sending specially crafted (authenticated and unauthenticated) requests, an attacker can exhaust a lot of memory on the server side, triggering the OOM killer.
An issue was discovered in Icinga 2.x through 2.8.1. The daemon creates an icinga2.pid file after dropping privileges to a non-root account, which might allow local users to kill arbitrary processes by leveraging access to this non-root account for icinga2.pid modification before a root script executes a "kill `cat /pathname/icinga2.pid`" command, as demonstrated by icinga2.init.d.cmake.
etc/initsystem/prepare-dirs in Icinga 2.x through 2.8.1 has a chown call for a filename in a user-writable directory, which allows local users to gain privileges by leveraging access to the $ICINGA2_USER account for creation of a link.