icinga CVE Vulnerabilities & Metrics

icingaweb2-module-incubator is a working project of bleeding edge Icinga Web 2 libraries. In affected versions the class `gipfl\Web\Form` is the base for various concrete form implementations [1] and provides protection against cross site request forgery (CSRF) by default. This is done by automatically adding an element with a CSRF token to any form, unless explicitly disabled, but even if enabled, the CSRF token (sent during a client's submission of a form relying on it) is not validated. This enables attackers to perform changes on behalf of a user which, unknowingly, interacts with a prepared link or website. The version 0.22.0 is available to remedy this issue. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Icinga Director is a tool designed to make Icinga 2 configuration handling easy. Not any of Icinga Director's configuration forms used to manipulate the monitoring environment are protected against cross site request forgery (CSRF). It enables attackers to perform changes in the monitoring environment managed by Icinga Director without the awareness of the victim. Users of the map module in version 1.x, should immediately upgrade to v2.0. The mentioned XSS vulnerabilities in Icinga Web are already fixed as well and upgrades to the most recent release of the 2.9, 2.10 or 2.11 branch must be performed if not done yet. Any later major release is also suitable. Icinga Director will receive minor updates to the 1.8, 1.9, 1.10 and 1.11 branches to remedy this issue. Upgrade immediately to a patched release. If that is not feasible, disable the director module for the time being.

icingaweb2-module-jira provides integration with Atlassian Jira. Starting in version 1.3.0 and prior to version 1.3.2, template and field configuration forms perform the deletion action before user input is validated, including the cross site request forgery token. This issue is fixed in version 1.3.2. There are no known workarounds.

Icinga Web 2 is an open source monitoring web interface, framework and command-line interface. Authenticated users, with access to the configuration, can create SSH resource files in unintended directories, leading to the execution of arbitrary code. This issue has been resolved in versions 2.8.6, 2.9.6 and 2.10 of Icinga Web 2. Users unable to upgrade should limit access to the Icinga Web 2 configuration.

Icinga Web 2 is an open source monitoring web interface, framework and command-line interface. Installations of Icinga 2 with the IDO writer enabled are affected. If you use service custom variables in role restrictions, and you regularly decommission service objects, users with said roles may still have access to a collection of content. Note that this only applies if a role has implicitly permitted access to hosts, due to permitted access to at least one of their services. If access to a host is permitted by other means, no sensible information has been disclosed to unauthorized users. This issue has been resolved in versions 2.8.6, 2.9.6 and 2.10 of Icinga Web 2.

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 to authenticate against the TSDB. There are no workarounds aside from upgrading.

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 server. ElasticsearchWriter (added in 2.8.0)exposes the password used to connect to the Elasticsearch server. An attacker who obtains these credentials can impersonate Icinga to these services and add, modify and delete information there. If credentials with more permissions are in use, this increases the impact accordingly. Starting with the 2.11.10 and 2.12.5 releases, these passwords are no longer exposed via the API. As a workaround, API user permissions can be restricted to not allow querying of any affected objects, either by explicitly listing only the required object types for object query permissions, or by applying a filter rule.

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 certificate may in turn be used to steal an endpoint or API user's identity. Versions 2.12.5 and 2.11.10 both contain a fix the vulnerability. As a workaround, one may either specify queryable types explicitly or filter out ApiListener objects.

Icinga Web 2 is an open source monitoring web interface, framework, and command-line interface. A vulnerability in which custom variables are exposed to unauthorized users exists between versions 2.0.0 and 2.8.2. Custom variables are user-defined keys and values on configuration objects in Icinga 2. These are commonly used to reference secrets in other configurations such as check commands to be able to authenticate with a service being checked. Icinga Web 2 displays these custom variables to logged in users with access to said hosts or services. In order to protect the secrets from being visible to anyone, it's possible to setup protection rules and blacklists in a user's role. Protection rules result in `***` being shown instead of the original value, the key will remain. Backlists will hide a custom variable entirely from the user. Besides using the UI, custom variables can also be accessed differently by using an undocumented URL parameter. By adding a parameter to the affected routes, Icinga Web 2 will show these columns additionally in the respective list. This parameter is also respected when exporting to JSON or CSV. Protection rules and blacklists however have no effect in this case. Custom variables are shown as-is in the result. The issue has been fixed in the 2.9.0, 2.8.3, and 2.7.5 releases. As a workaround, one may set up a restriction to hide hosts and services with the custom variable in question.

Icinga Web 2 is an open source monitoring web interface, framework and command-line interface. Between versions 2.3.0 and 2.8.2, the `doc` module of Icinga Web 2 allows to view documentation directly in the UI. It must be enabled manually by an administrator and users need explicit access permission to use it. Then, by visiting a certain route, it is possible to gain access to arbitrary files readable by the web-server user. The issue has been fixed in the 2.9.0, 2.8.3, and 2.7.5 releases. As a workaround, an administrator may disable the `doc` module or revoke permission to use it from all users.

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.

Icinga Icinga Web2 2.0.0 through 2.6.4, 2.7.4 and 2.8.2 has a Directory Traversal vulnerability which allows an attacker to access arbitrary files that are readable by the process running Icinga Web 2. This issue is fixed in Icinga Web 2 in v2.6.4, v2.7.4 and v2.8.2.

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.

Icinga Web 2 before 2.6.2 allows parameters that break navigation dashlets, as demonstrated by a single '$' character as the Name of a Navigation item.

Icinga Web 2 before 2.6.2 allows injection of PHP ini-file directives via vectors involving environment variables as the channel to send information to the attacker, such as a name=${PATH}_${APACHE_RUN_DIR}_${APACHE_RUN_USER} parameter to /icingaweb2/navigation/add or /icingaweb2/dashboard/new-dashlet.

Icinga Web 2 has XSS via the /icingaweb2/monitoring/list/services dir parameter, the /icingaweb2/user/list query string, the /icingaweb2/monitoring/timeline query string, or the /icingaweb2/setup query string.

Icinga Web 2 before 2.6.2 has XSS via the /icingaweb2/navigation/add icon parameter.

Icinga Web 2 before 2.6.2 has CSRF via /icingaweb2/config/moduledisable?name=monitoring to disable the monitoring module, or via /icingaweb2/config/moduleenable?name=setup to enable the setup module.

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.

Icinga Core through 1.14.0 initially executes bin/icinga as root but supports configuration options in which this file is owned by a non-root account (and similarly can have etc/icinga.cfg owned by a non-root account), which allows local users to gain privileges by leveraging access to this non-root account, a related issue to CVE-2017-14312. This also affects bin/icingastats, bin/ido2db, and bin/log2ido.

Cross-site scripting (XSS) vulnerability in the Classic-UI with the CSV export link and pagination feature in Icinga before 1.14 allows remote attackers to inject arbitrary web script or HTML via the query string to cgi-bin/status.cgi.

Multiple off-by-one errors in Icinga, possibly 1.10.2 and earlier, allow remote attackers to cause a denial of service (crash) via unspecified vectors to the (1) display_nav_table, (2) print_export_link, (3) page_num_selector, or (4) page_limit_selector function in cgi/cgiutils.c or (5) status_page_num_selector function in cgi/status.c, which triggers a stack-based buffer overflow.

Stack-based buffer overflow in the cmd_submitf function in cgi/cmd.c in Nagios Core, possibly 4.0.3rc1 and earlier, and Icinga before 1.8.6, 1.9 before 1.9.5, and 1.10 before 1.10.3 allows remote attackers to cause a denial of service (segmentation fault) via a long message to cmd.cgi.

Multiple off-by-one errors in Nagios Core 3.5.1, 4.0.2, and earlier, and Icinga before 1.8.5, 1.9 before 1.9.4, and 1.10 before 1.10.2 allow remote authenticated users to obtain sensitive information from process memory or cause a denial of service (crash) via a long string in the last key value in the variable list to the process_cgivars function in (1) avail.c, (2) cmd.c, (3) config.c, (4) extinfo.c, (5) histogram.c, (6) notifications.c, (7) outages.c, (8) status.c, (9) statusmap.c, (10) summary.c, and (11) trends.c in cgi/, which triggers a heap-based buffer over-read.

Cross-site request forgery (CSRF) vulnerability in cmd.cgi in Icinga 1.8.5, 1.9.4, 1.10.2, and earlier allows remote attackers to hijack the authentication of users for unspecified commands via unspecified vectors, as demonstrated by bypassing authentication requirements for CVE-2013-7106.

Multiple stack-based buffer overflows in Icinga before 1.8.5, 1.9 before 1.9.4, and 1.10 before 1.10.2 allow remote authenticated users to cause a denial of service (crash) and possibly execute arbitrary code via a long string to the (1) display_nav_table, (2) page_limit_selector, (3) print_export_link, or (4) page_num_selector function in cgi/cgiutils.c; (5) status_page_num_selector function in cgi/status.c; or (6) display_command_expansion function in cgi/config.c. NOTE: this can be exploited without authentication by leveraging CVE-2013-7107.

Multiple stack-based buffer overflows in the get_history function in history.cgi in Nagios Core before 3.4.4, and Icinga 1.6.x before 1.6.2, 1.7.x before 1.7.4, and 1.8.x before 1.8.4, might allow remote attackers to execute arbitrary code via a long (1) host_name variable (host parameter) or (2) svc_description variable.

The database creation script (module/idoutils/db/scripts/create_mysqldb.sh) in Icinga 1.7.1 grants access to all databases to the icinga user, which allows icinga users to access other databases via unspecified vectors.

Multiple cross-site scripting (XSS) vulnerabilities in config.c in config.cgi in Icinga before 1.4.1, when escape_html_tags is disabled, allow remote attackers to inject arbitrary web script or HTML via a JavaScript expression, as demonstrated by the onload attribute of a BODY element located after a check-host-alive! sequence, a different vulnerability than CVE-2011-2179.

Multiple cross-site scripting (XSS) vulnerabilities in config.c in config.cgi in (1) Nagios 3.2.3 and (2) Icinga before 1.4.1 allow remote attackers to inject arbitrary web script or HTML via the expand parameter, as demonstrated by an (a) command action or a (b) hosts action.