Hi Elmar, Thank you for debcheckroot. I think it is a great project, which makes us one step closer to a verifiable Debian system. In this particular case, I'd like to point out the exact flags from fileserror.lis that you showed us: "..._.GM" and "..._..M". According to the description on your website, it means the modification of the file permissions, not the actual content.
Since I was curious, I tried debcheckroot on my system, and found the same binaries at fileserror.lis (amongst a few others): ..._.GM /usr/bin/ssh-agent openssh-client_1:8.4p1-5_amd64 root root 755 ..._.GM /usr/bin/crontab cron_3.0pl1-137_amd64 root root 755 ..._..M /usr/bin/pkexec policykit-1_0.105-31+deb11u1_amd64 root root 755 Here is the actual u/g and permissions: -rwxr-sr-x 1 root crontab Feb 23 2021 /usr/bin/crontab -rwsr-xr-x 1 root root Jan 13 22:32 /usr/bin/pkexec -rwxr-sr-x 1 root ssh Mar 13 2021 /usr/bin/ssh-agent It is indeed different from the original deb-package permissions but I found the reason for that: # egrep -e dpkg-statoverride /var/lib/dpkg/info/cron.postinst dpkg-statoverride --update --add root crontab 2755 /usr/bin/crontab # egrep -e chmod -e chgrp /var/lib/dpkg/info/openssh-client.postinst chgrp ssh /usr/bin/ssh-agent chmod 2755 /usr/bin/ssh-agent # egrep -e set_perms /var/lib/dpkg/info/policykit-1.postinst set_perms() { set_perms root root 4755 /usr/bin/pkexec So while I truly consider the debcheckroot very useful, I think in this case it was a false positive due to the side effects of the postinst scripts of the relevant packages. Thank you, Vitaly On Friday, 6 May 2022 16:52:15 MSK Elmar Stellnberger wrote: > Dear Sylvain > > Am 04.05.22 um 13:17 schrieb Sylvain: > > I've just tried debcheckroot too. It throws error. I'll try to fix them. > > Am 06.05.22 um 15:05 schrieb Sylvain Sécherre: > > Here's the fileserror.lis: > > ..._.GM /usr/bin/crontab cron_3.0pl1-137_amd64 root root 755 > > ..._..M /usr/bin/pkexec policykit-1_0.105-31+deb11u1_amd64 root root 755 > > ..._.GM /usr/bin/ssh-agent openssh-client_1:8.4p1-5_amd64 root root 755 > > ... > > I hope you won´t mind that I am citing the output of debcheckroot you > have given me. > These three files point to an infection with a rootkit. Don´t care > about modified configuration files like in /etc too much (but you may > still have a look at them). Executable files on the other hand must > never be modified. If these three files are different it means that > someone has altered your system. If you look at the man pages of these > executables then you also know that a maker of a rootkit would have > interest to modify exactly these files. > > > The file filesunverified.lis is very long, while pkgcorrupt.lis is empty. > > If you have updated your system some time ago and there are newer > versions on the update server now then debcheckroot can certainly not > find these packages any more. You could try to update your system and > then verify again. Normally the rootkit will persist. However connecting > your computer to a network may be detrimental since the rootkit owner > may simply uninstall his rootkit once he knows that his malware has been > discovered. > I would at least save suspicious executables first and additionally > the packages with known good of the same version. > > Regards, > Elmar >