[security] Privilege Escalation from crontab

[gquere]

---

BUG REPORT INFORMATION

OS: Centreon-Central-18.10-el7

Vulnerability
The crontab deployed when installing the package or when using the VM executes a perl script as root every day to backup the database:

# Cron for Centreon-Backup
30 3 * * * root /usr/share/centreon/cron/centreon-backup.pl >> /var/log/centreon/centreon-backup.log 2>&1

In this perl script, there are two command executions that use a path defined by a configuration file:

`$centreon_config->{CentreonDir}cron/centreon-backup-mysql.sh -b $TEMP_DB_DIR -d $today`;
`$centreon_config->{CentreonDir}cron/centreon-backup-mysql.sh -b $TEMP_DB_DIR -d $today -p`;

But the permissions to this configuration are too open, as the group may write to it:

[root@centreon-central cron]# ll /etc/centreon/conf.pm
-rw-rw-r-- 1 centreon centreon 743 21 déc.  08:00 /etc/centreon/conf.pm

This leads to a privesc to root from any user from the centreon group, of which apache is conveniently a member of:

bash-4.2$ whoami
apache
bash-4.2$ groups
apache centreon-engine centreon-broker centreon nagios

For instance, apache could change the path in the configuration file to execute a script to get sudo rights when the DB is saved:

[root@centreon-central cron]# cat /tmp/fakecentreon/cron/centreon-backup-mysql.sh 
#!/bin/bash

echo "" >> /etc/sudoers.d/centreon
echo "CENTREON   ALL = NOPASSWD: ALL" >> /etc/sudoers.d/centreon

It's realistic that apache would be the account to privesc from because of RCEs in Centreon's codebase.

[sc979]

Hi @gquere ,
I've merged modifiications on all branches. These will be released on next versions
I'm closing this issue.
Best regards