Török Edwin: > On 09/17/2013 09:45 PM, adrelanos wrote: >> Situation: >> >> * You have a Debian machine, which might be compromised by a backdoor >> due to a targeted attack. You don't know and want to make sure it's not. >> For example, a server or a client internet machine. > > Why not just reinstall from a trusted source, then restore /etc, /home and > /var from backups > and audit the changes introduced by that only? > >> >> In reality, it seems like many files are auto-generated and not owned by >> any packages. Some of them even hold binary code, which gets executed >> during boot. Some examples: >> - /boot/grub/video_fb.mod >> - (dpkg -S /boot/grub/video_fb.mod reports not owned by any packages) > > It is copied from /usr/lib/grub/i386-pc: > $ dpkg -L grub-pc-bin | grep video_fb > /usr/lib/grub/i386-pc/video_fb.mod
Thanks for the technical information. That will help to audit those. >> - /lib/modules/3.10-2-686-pae/modules.symbols >> - /etc/ssl/certs/GeoTrust_Global_CA.pem >> - /etc/ld.so.cache >> - /etc/rc*.d/* >> - /usr/lib/python2.7/dist-packages/pygtk.pyc >> - and many more... >> >> It could be quite difficult to get a signed version of some of them or >> to deterministically freshly generate them? > > Aren't they generated by the package's postinst script? Probably yes, but it the postinst script calls something like update-mime-database, I am not sure how to compare it's outputs. I must check first if it's outputs are deterministic (when using the same versions, of course). Maybe I have to run such commands on the trusted system to generate those files and then compare with the untrusted system. Sounds like quite some package specific work. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]

