Re: debcheckroot v2.0 released
Am 19.11.19 um 13:29 schrieb Patrick Schleizer:
Anyone using this yet?
I would speculate, not many are using it. It needs step by step
instructions. Otherwise, most users are lost at hello.
Well, I have a couple of downloads every day, the more serious ones with
wget.
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.
I guess "nobody" is going to do that. Sounds complicated. And I am
The issue is that you do not need to check the initrd in deed under
normal circumstances. If the initrd is infected so will be
/sbin/mkinitramfs. I have never seen the initrd being infected alone as
this would need to be updated on every new kernel configuration update
like when you install firmware.
[tor-dev] First-time tails/tor user feedback
https://lists.torproject.org/pipermail/tor-dev/2012-April/003472.html
Eliminating Stop-Points in the Installation and Use ofAnonymity Systems:
a Usability Evaluation of the Tor Browser Bundle
https://petsymposium.org/2012/papers/hotpets12-1-usability.pdf
I would also suggest a different design / additional feature. Rather
than requiring a network connection or DVD, could you add a feature
please similar to "apt-file" or "command-not-found"? What I mean by that:
These tools download a cache while the system is running. debcheckroot
could download/generate/prepare all the sha256 files on the disk. Yes,
within the running system. Don't worry about verifying integrity of
these files just yet. That will be answered later. Yes, these sha256
files could be maliciously altered. But that is something you can check
later at debcheckroot runtime.
What you suggest here does not make sense to me. If you have to check
®enerate these sha256 lists later on it is the same work as if you do
not use them.
Generating the (sha256) files required for later verification could be
done using an apt or dpkg hook.
No, it is a feature of the tool that it does not require the dpkg
infrastructure. - an important one. I have even successfully verified an
old Debian6 installation with debcheckroot-v2.0. - no binaries required,
only plain Python available almost everywhere.
Then, later when debcheckroot runs, it would rely on these files. But to
check that these files haven't been altered, it could check them against
repository signing keys. So debcheckroot would need a bit root of trust
built-in or better configurable. For example, it could be sufficient to
point debcheckroot at clean Debian repository signing keys. These would
then be used to check the sha256 files.
Key signatures are not trustworthy in general. I have argued this a 100
times; see also https://www.elstel.org/software/GnuPG-usage.html.en
The advantage of this would be that debcheckroot can be run from Live
USD or Live DVD. Offline. No need for a network connection since all
files to be verified would already be prepared.
debcheckroot can already perfectly run offline from the live cd of any
distribution. I think you didn´t read the docs.
To a rootkit hunter which laymen can use it's a long way to go. Some
debcheckroot is targeted at technically experienced users. No way to
hunt rootkits authored by the NSA otherwise. You have to be a tough user
to take this challenge! Well you can of course also use it for other
kinds of rootkits by other governments or from criminals but
interpreting the results requires some kind of knowledge about a Linux
system. You need to know what the kernel is, what an initrd is, what you
can find under /bin, /usr/bin, /sbin and /usr/sbin.
The tool has primarily been written against 5 eyes rootkits but I think
it is still missing some features to take this challenge. f.i. it should
be possible to unpack *.deb-s in an own boot run, separate from
downloading and verification. That would shield against attacks targeted
at the unpacking which affect the very system debcheckroot runs on.
Supporting file only repos for customly downloaded and installed
packages like my printer driver would also be an issue.
Once, the more people are using debcheckroot via Tails the harder it
will get for intelligence to spoof these downloads. Effectiveness of
debcheckroot is also an issue of a critical mass of users who apply the
tool at least from time to time.
Most people do not take the threat posed by rootkits authored by western
intelligence serious, though. I believe only a very few users are using
Tails with --download-only as this was not well supported with
debcheckroot-v2.0 but nobody had complained. It would have been possible
to download via Tor using deblive linked from
https://www.elstel.org/debcheckroot/ (https://www.elstel.org/deblive/)
but I guess hardly anyone or nobody at all did. With debcheckroot-v2.1
using Tails should be well supported, at least the way I do so. When you
know that repository signing keys can be stolen (there is an own key
stealing programme) things like 'torsocks apt-get update' can make sense.
rhetorical question questions. How to I create a Live DVD / USB to check
my running system? Download such a Live DVD / USB image somewhere? How
The serious user should have a Tails CD handy. At best buy that with a
Linux magazine at your local newspaper kiosk. Downloading it insecurely
directly via the internet may not be a good idea.
do I mount the internal hard drive? Or mount an internal full disk
encrypted disk? Then run debcheckroot on it? Could this be fully
I disadvise full disk encryption because you may easily loose your data.
Better carry an M2 stick with you. Disk encryption can be cracked easily
by installing a keylogger which will log the keyboard key strokes to get
the encryption key.
automated so these tests can be run routinely, easy? Graphical user
interface? Run debcheckroot fully automated at boot (from read-only boot
You can not run that fully automatically as it needs a human being to
analyse and interpret the results.
medium such as Live DVD), verify all files, then continue booting from
the internal disk (kexec)? That would be similar to the verified boot
feature which is already a default feature in iPhone, Android, and ChromeOS.
Can we get iPhone and Android Level Security for Linux Desktop
Distributions?
I believe there is no security for Android and iPhone systems as you can
not unmount and check the boot partition of these devices.
Dear readers of debian-security
I have just released debcheckroot-v2.0:
https://www.elstel.org/debcheckroot/
The new tool can be used to check a Debian installation also against
previously unknown rootkits. It has many improvements towards
debcheckroot-v1.0:
# usage of direct comparison or creation and usage of sha-256 lists
instead of the unsafe md5sums provided in the package header
# allow usage of multiple changeable media: i.e. DVD & BD-SL
verification rather than just BD-DL verification
# testing of symbolic links, of user, group and file-mode
# scanning the home directory for odd filenames that contain control
characters, on request: listing all hidden binary files in the home
directory
# download only mode + shuffling of download order for package download
via Tails/Tor and subsequent offline verification
# use of Python3 instead of Perl with built in support for tar, xzip,
gzip and bzip2; no more external helper programs required, works from
any live cd!
Finally debcheckroot-v1.0 did no more work with current versions of
Debian as Debian now uses xzip instead of gzip. The new program supports
any of xzip, gzip and bz2 for compression of the data.tar.xz and the
controls .tar.xz inside the .deb ar-archive. Files are merely unpacked
in memory so debcheckroot keeps being quite efficient.
I would be happy to discuss the new release here or to assist anyone who
wants to test the new tool!
Regards,
Elmar
Reply to: