debcheckroot

interpretation of the results for v2.0

Here is a listing on how to interprete the results in fileserror.lis:

The information for md5sums is fetched from the package header. All other information is extracted from the archive of a package. If the archives contain configuration files the direct comparison or the sha256sum may not match since such files can be altered automatically by installation scripts. That does not happen with md5sums as they are hand-picked by package maintainers. f.i. there seem to be some files in the aspell-en package affected by this issue. Verifying installations from more than one data carrier is directly supported from v1.99.7 on. You are prompted to insert the right media if more than one media is listed in /etc/apt/sources.list. You should be able to run this program from a clean Tails, Debian live data carrier or from a live CD of any other distribution. A dot means that the corresponding feature has been checked and was found to be ok. An underscore indicates an unchecked feature.

security considerations

By default debcheckroot checks the packages in alphabetical order as they appear in /var/lib/dpkg/status. However this is a conspicuous download pattern so that intelligence services monitoring your Tor download may spot and attack you. To forgo this problem there are two options: --shuffle and --by-deps which shuffle the download order arbitrarily and which can additionally download dependent packages first. These options are mainly here for that downloads are not halted deliberately. The integrity of each downloaded archive is ascertained by the sha256sum contained in the repository index.

It is most secure to first download all required packages into ./cache and then verify offline by unplugging your network cable. You may use the --ofline option to prevent debcheckroot from trying to download missing packages. Most secure is to use three boots for a verification run: one to download, one to extract archives and generate sha256sums and one final run to verify. Extracting archives may unleash malware. See at the very bottom of this page on how to do this in detail. This does not prevent downloading packages with spoofed content though (f.i. if tor gets impersonated). The only way to avoid this is to install no updates and only from blue ray media.

If you should be attacked during a download the most likely behaviour will be that the download of a package is stalled for a more or less infinite time to make you interrupt and reinvoke debcheckroot. When you reinvoke debcheckroot it may re-download a spoofed repository description with tampered sha256sums. For every package download the sha256sum provided by the repository is checked. In order not to continue the download from a spoofed repository use the --no-repo-check-upd option. This option prevents debcheckroot from checking for an updated repository desciption. It should make debcheckroot look into the ./cache directory to get the repository description and thereby the already known sha256sums.

basic procedure / general hints

Basically there are two ways to verify your system: online and via BD-DL (Blue Ray Double Layer). Which choice may be the better will depend on what threat you want to shield against. If you are a company which wants to shield against criminal endeavor of other parties then we would recommend you online verification and a well configured and updated system. However if your suspected enemies are foreign intelligence services then just updating and configuring your system well can not shield you against them as these services have their own intelligence to implant and spot backdoors in oss and non-oss software also known as zero-days exploits. There are plenty of such weaknesses in any kind of software and just focusing on publicly known weaknesses by updating is ridiculous if you want to shield against intelligence. Updating may be required to shield against the malware of criminals though. For this case we provide the possiblity to download via Tails/Tor and to separate the verification from the archive unpacking; see for the section 'security considerations'.

Consequently you may choose not to update but to install from BD-DL only; that can even be an option if your computer is held online. Besides this issue you can not ultimately trust md5sums as this hashing algorithm is weak. Trailing garbage could be added to keep the md5sum. That is why we also have direct comparison / sha256sum checking. You may also simply install the same system with exactly the same packages in an empty partition from scratch by use of all the packages put in the ./cache directory and compare both root file systems file by file. This will be most effective.

The first thing to do when you experience your system being under attack is to put your machine offline and to keep it offline. Verify in a next step with BD or downloaded archives. You may perform the download by another machine than where you will run the verification task. Make sure you boot from a clean medium. Things like the Intel ME contained in all modern computers can be used by intelligence services to log in without your permission. Note that starting the verification out of an infected system may be useless (usually it is with some exceptions as unshielded mirroring of infected files between /bin and /usr/bin). debcheckroot has been designed the way that you can use it on any system that provides plain Python3. Booting from CD or SD-card with a read-only enforcing sdcard reader is recommended. debcheckroot does not do a chroot or use executables out of the infected system as would be required for debsums because this would infect your freshly booted system. The various unzip routines like the Python3-internal unxzip seem to be an attack vector though. Note that in todays world even the BIOS is an attack vector. Consequently you would have to boot a fresh system, verify or flash the BIOS and then reboot a fresh system (see: flashrom/coreboot) to start the verification. Note that the BIOS should be flashed by software not by a BIOS utility like ASUS EZ-Flash because flashing by the means of a manipulated BIOS/UEFI can be ineffective. If you buy a new computer look for flashrom as well as coreboot support; f.i. many computers from System76 have a disabled Intel ME even if you use UEFI instead of coreboot. The Intel ME can be used to log into a computer by secret services so that you may want to use a ME-free computer or do some things offline.

Things debcheckroot does not check at the moment are the initrd and the MBR (master boot record). You may unpack the initrd by hand and check the files contained there against a sha256sum list generated by debcheckroot. The MBR can first be backuped by confinedrv/diskutils. Then reinstall it with Grub from a fresh boot CD and look if the boot sector has altered. Under normal circumstances Grub would install the exactly same code into the MBR.

You may even want to unmount the hard disk and plug it into a known-to-be-clean computer for verification. Basically even the firmware of any component like the hard disk can be under attack. To place relevant malware into a firmware image it needs to be big enough though. That is just another reason why old BIOS based systems are more secure than newer UEFI based systems. By manipulating the firmware of your hard drive malware could be hidden either in additional backup blocks for use instead of bad sectors or simply on any place where your hdd returns read errors. Such errors could likely be distinguished from real hardware errors by doing a low level format of your drive with a vendor specific tool (like f.i. packed on the Ultimate boot CD): If the errors go away after flashing the HDD firmware or resetting the drive, that is somewhat suspicious.

• Why you should not use debsums in case of security issues
• debsums requires you to chroot into the infected target root (inadmissible)
• debsums uses locally stored md5sums which can be altered by an attacker; you need freshly downloaded checksums
• debsums requires a full Debian infrastructure; debcheckroot can be invoked from any Linux boot CD

• What makes debcheckroot the better tool
• debcheckroot has full built-in support of repos; you can verify online and do not need to specify the individual location of each package to test against locally
• debcheckroot fetches fresh package headers and content from the verification medium instead of locally stored and altered md5sum lists
• it also lists additional/spurious files that should not be here / that are not under control of the package management system
• debcheckroot stores the results in nicely formatted output files for later analysis; i.e. you do not have to pipe the screen output
• you can easily spot all your manual alterations of a system which you wanna reinstall
• debsums is somewhat inefficient because it unpacks the package headers into temporary files while debcheckroot only unpacks in memory; debsums does this only where there are no locally stored md5sums