Threat Intelligence Database

linuxfabrik-lib provides Python modules for database access, caching, shell execution, and API integrations. Prior to version 6.0.0, lib.url.fetch() followed cross-origin redirects while forwarding caller-supplied credential headers other than Authorization and Cookie, allowing a malicious redirect-capable server to receive headers such as X-Auth-Token from authenticated monitoring requests. This issue is fixed in version 6.0.0.

### Summary The SQLite databases are created at predictable (static) paths in `/tmp`. Any user can therefore create a symlink at these paths in /tmp pointing to arbitrary files. The monitoring scripts then follows these symlinks and then creates their database at the symlink target. This becomes really dangerous for the scripts which can be executed as root with sudo. With this, an attacker can write to abitrary paths. ### PoC The docker-stats check command here as an example. Because writing to /tmp is the default behaviour, the other check commands which use a SQLite database are also very likely affected. ``` # Create the symlink as nagios user nagios@test-server:/tmp$ ln -s /root/nagios-was-here /tmp/linuxfabrik-monitoring-plugins-docker-stats.db # Trigger the execution nagios user nagios@test-server:/tmp$ sudo /usr/lib64/nagios/plugins/docker-stats ``` Check whether or not file was created. ``` root@test-server:/# file /root/nagios-was-here /root/nagios-was-here: SQLite 3.x database, last written using SQLite version 3046001, file counter 2, database pages 3, cookie 0x2, schema 4, UTF-8, version-valid-for 2 ``` ### Impact In it's basic form, this vulnerbility can lead to a denial of service, impacting users who use the provided sudoers file and who didn't take any special precautions like systemd's `PrivateTemp`. It requires that an attacker already compromised the nagios account (which is quite a high barrier to be honest). If any application on the server relies on a SQLite database, there are scenarios where this vulnerability allows for content in existing SQLite databases to be modified. An attacker could let the symlink point to an existing SQLite database and create in /tmp a specially-crafted SQLite Rollback Journal (`.db-journal`) or Write-Ahead-Log (`.db-wal`), which is then applied to the database. ### Fix A proposed fix would be to create a separate directory inside /tmp per user (e.g.,` /tmp/linuxfabrik-monitoring-plugins-{os.geteuid()}`). After creating this directory (or using an already existing one), check the following: ``` # Use os.lstat() instead of os.stat() so we don't accidentally follow symlinks dir_stat = os.lstat(TMP_DIR_PATH) # Ensure the directory is a real dir and not a Symlink if not stat.S_ISDIR(dir_stat.st_mode): # abort the execution sys.exit(1) # Verify the owner if dir_stat.st_uid != os.getuid(): # abort the execution sys.exit(1) # Verify the permissions if (dir_stat.st_mode & 0o077) != 0: # abort the execution sys.exit(1) ```

### Summary When a check plugin places user provided input inside a command which is passed to `shell_exec`, an attacker can abuse this to run arbitrary commands. This is mainly dangerous for plugins which are listed in the sudoers file, because this allows an attacker controlling the nagios user to get root privileges. ### Details An example for this is the `restic-check` plugin, where the `--repo` argument is placed inside the command argument of `shell_exec`. As an example, an attacker could use the `--repo` argument `|touch /root/nagios-was-here|`. The full restic command is assembled to the string `restic --json --repo=|touch /root/nagios-was-here| --password-file= check` before it is passed to `shell_exec`. `shell_exec` then splits the command up in three parts at the | boundaries and executes the parts separately, which also executes the embedded command `touch /root/nagios-was-here`. ### PoC This PoC shows how the nagios user can use this to create a file inside `/root`. ``` nagios@test-vm:/$ sudo /usr/lib64/nagios/plugins/restic-check --repo '|touch /root/nagios-was-here|' ``` ### Impact The vulnerability is a local privilege escalation. ### Fix #### Switch from | to an array Remove the | split functionality. Instead, modify shell_exec to accept either a string or an array of strings. If an array is provided, the commands are chained together like they currently are when using |. If a string is provided, no split should be performed. You could also introduce a separate function like `shell_exec_with_user_input()` which implements this such that the current shell_exec function can stay like it is. This leaves the problem that an attacker can still specify arbitrary arguments inside a command. An example for this would be to use the `--repo` argument `sftp://example.com --cache-dir /tmp`, which would lead to the execution of: `restic --json --repo=sftp://example.com --cache-dir /tmp --password-file=None check`. Please note that this example should mainly highlight the problem in general. To prevent the problem, there is either escaping or again array-syntax. Escaping would use `shlex.quote` to place the user provided argument inside quotes and which also escapes everything which needs to be escaped. Using array syntax would mean providing the full command as an array like `['restic', '--json', '--repo', 'sftp://example.com']`. The array can then be given as-is to `Popen`. With this method, the proposed `shell_exec_with_user_input` would accept an array of array of strings. ### Patches The fix follows the array-syntax approach proposed above: * `linuxfabrik-lib` 5.0.0: `lib.shell.shell_exec()` requires the command as a list of arguments (argv) and always runs with `shell=False`. The `|` split functionality, command strings and the `shell=` parameter have been removed, so user-provided input can no longer break out of a command. `lib.shell.safe_cli_value()` additionally guards positional arguments (such as an ssh destination or a ping target) against option injection, and `lib.ssh` builds argument lists as well. * Linuxfabrik Monitoring Plugins: all plugins assemble their external commands as argv lists (commit 23bb570f4). Contained in every release after v5.2.0.

### Summary In the [Debian.sudoers](https://github.com/Linuxfabrik/monitoring-plugins/blob/main/assets/sudoers/Debian.sudoers) file, `apt-get` is allowed for the nagios user. The full command including the arguments are not enforced and can therefore be choosen arbitrarily. This allows to easily get a root shell as the nagios user: ### PoC By choosing a particular argument, you can get (as a nagios user) a root shell: ``` sudo apt-get update -o APT::Update::Pre-Invoke::="/bin/sh" ``` Since the nagious user can use sudo to run apt-get as root, the resulting shell is also running as root. ### Impact The vulnerability is a local privilege escalation, impacting users who use the provided sudoers file. It requires that an attacker already compromised the nagios account (which is quite a high barrier to be honest). ### Fix Since only one place where `apt-get` is currently used (in [deb-updates](https://github.com/Linuxfabrik/monitoring-plugins/blob/998302a5fb43e89df1359f4cbb6558f81c96ae4f/check-plugins/deb-updates/deb-updates#L124)) was found, it should be enough to allow only the specific arguments used there. Here an example how the line in the sudoers file could look like: ``` /usr/lib64/nagios/plugins/strongswan-connections,\ /usr/lib64/nagios/plugins/systemd-unit,\ /usr/bin/apt-get update --quiet 2 ```