Re: debcheckroot v2.0 released
Elmar Stellnberger:
>>> 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.
Not necessarily. There are a lot more options to write a malicious
initrd other than infecting /sbin/mkinitramfs. A rootkit could re-mount
the real /sbin/mkinitramfs to a compromised hidden file
/sbin/mkinitramfs, use LD_PRELOAD tricks and probably much more.
> 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.
How often did you see initrd being infected?
>> 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.
Later on you don't have to re-generate the sha256 lists. Just verify
their signatures.
>> 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.
Not using apt/dpkg comes at the expense of not being able to fully
verify the whole system. What if there are outdated packages on the
system which aren't available from anymore from repository? Using
snapshot.debian.org?
Also, for quickly repeatable verification it would be best to prepare as
much as possible in background / during upgrade. Other tasks can be done
at the same time. Then booting from read-only to debcheckroot purposes
could safe a lot time. The less time it needs, the more it gets within
reach to automate the process without sacrificing much boot time.
Also by not using apt/dpkg, any packages downloaded would have to be gpg
verified manually.
I also don't see debcheckroot make use of gpg signature verification of
downloaded files?
Reinventing apt is difficult. See these attack on package managers:
https://www2.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html
Package metadata could be outdated. Downloaded package contents could be
malicious or altered to pass verification.
>> 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
That article https://www.elstel.org/software/GnuPG-usage.html.en starts
with "How to use GnuPG securely". That isn't the best way to communicate
"Key signatures are not trustworthy in general" which is a pretty broad
claim.
If "Key signatures are not trustworthy in general" then all apt package
downloads could be considered compromised since APT relies on gnupg for
verification. With that was true, and with mindset, and that being
unfixable, we could as well as give up.
>> To a rootkit hunter which laymen can use it's a long way to go. Some
>
> debcheckroot is targeted at technically experienced users.
That's sad. Understood.
> No way to
> hunt rootkits authored by the NSA otherwise.
Yes, forget about NSA and alike. Let's not assume quasi-omnipotent
attackers. That leads to defeatist mindset which isn't productive.
> 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.
Why couldn't it be fully automated without manual interpretation needed?
> 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.
Usability and popularity. Both hard. Software is only step 1.
>> 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.
Full disk encryption is proven effective. If one travels and a bag gets
stolen by a criminal, no data can be accessed.
Keyloggers are really bad but unrelated from that.
>> 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.
Yes, Android has security features which are working fine, reliable,
would be replicable on Linux desktops in principle, but aren't yet.
That's the point of that writeup.
https://www.whonix.org/wiki/Kicksecure#iPhone_and_Android_Level_Security_for_Linux_Desktop_Distributions
debcheckroot could help getting something like verified boot for Debian.
Kind regards,
Patrick
Reply to: