posted 2017-11-18
Icinga installs two sets of files with insecure permissions: after installation, the executables and the configuration files are all owned by the same unprivileged user and group (typically, icinga) that the daemon runs as. In one attack, the unprivileged user simply replaces the icinga executable with one that does his bidding. A slightly more complicated attack can be mounted by the unprivileged user by scheduling a malicious service check and then altering icinga.cfg to execute that check as root.
The ido2db daemon and its sample configuration file have the same issue.
The Icinga build system allows you to specify a runtime user and group (default: icinga) via the two ./configure parameters --with-icinga-user and --with-icinga-group:
AC_ARG_WITH(
icinga_user,
AC_HELP_STRING([--with-icinga-user=<user>],
[sets user name to run icinga]),
icinga_user=$withval,
icinga_user=icinga)
AC_ARG_WITH(
icinga_group,
AC_HELP_STRING([--with-icinga-group=<grp>],
[sets group name to run icinga]),
icinga_grp=$withval,
icinga_grp=icinga)
AC_SUBST(icinga_user)
AC_SUBST(icinga_grp)
The daemon runs as that user and group by default, because the
upstream configuration file icinga.cfg
incorporates those flag values into the icinga_user and
icinga_group settings in
sample-config/icinga.cfg.in:
# ICINGA USER
# This determines the effective user that Icinga should run as.
# You can either supply a username or a UID.
icinga_user=@icinga_user@
# ICINGA GROUP
# This determines the effective group that Icinga should run as.
# You can either supply a group name or a GID.
icinga_group=@icinga_grp@
The build system then installs most of the files for the package
with their owners/groups set to the user and group specified,
through the pervasive use of the following INSTALL_OPTS
in configure.ac:
This creates vulnerabilities because the Icinga daemons are intended to be run as root.
The default ownership is exploitable in at least two ways:
The Icinga runtime user owns the daemon executable, typically located at /usr/bin/icinga. That executable is run as root, and drops privileges to the runtime user itself. This invites a simple attack where the runtime user replaces the daemon executable with his own code. The ido2db daemon has the same problem.
In addition, the system executables
icingastats and
log2ido are installed to root's
$PATH and could conceivably be run as root. They
thus pose a similar risk.
The main configuration file icinga.cfg is
also owned by the unprivileged runtime user, but
icinga.cfg is where the runtime user and
group are specified. The unprivileged runtime user can schedule
a malicious service check (specified in the configuration files
he owns) and then put icinga_user=root in
icinga.cfg. The next time the daemon is
restarted, it will run as root and execute the command set by
the unprivileged user.
The configuration file ido2db.cfg-sample is vulnerable in the same manner if it is renamed to ido2db.cfg without adjusting its ownership.
Most users should reset all ownership and group information to safe values:
root # dirs="/bin /sbin /usr /etc"
root # icinga_user=icinga
root # icinga_group=icinga
root # find $dirs -user "${icinga_user}" -print0 | \ xargs --null chown --no-dereference --from="${icinga_user}" root
root # find $dirs -group "${icinga_group}" -print0 | \ xargs --null chown --no-dereference --from=":${icinga_group}" :0
The find commands above are intended to
omit precisely one Icinga directory, its
$localstatedir. The Icinga runtime user does need to be
able to write to its logfile and to record the results of its
service checks. On Gentoo, that information is stored under
/var/icinga as the result of passing
--localstatedir=/var/icinga to the
./configure script. Thus the owner and group of
/var/icinga (or wherever your
$localstatedir happens to be) should be left alone.
If you would like to allow a group of non-root users to modify the Icinga configuration, that is possible with two caveats:
g+w. However, the main configuration file
icinga.cfg must not have its
group changed or be made group-writable! Otherwise anyone in the
icingaconfig group would be able to gain root through the
exploit described earlier.