Re: debcheckroot v2.0 released
Am 25.11.19 um 12:35 schrieb Patrick Schleizer:
How often did you see initrd being infected?
recently only once. So the attackers may change their vector; they have
already done so multiple times.
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
I have just extended debcheckroot to also support file repos. Now it can
check 100% of the packages I have installed. That was necessary because
f.i. the printer driver is vendor specific and can not be fetched from
an online repo. I will publish that as debcheckroot v2.2 soon. Outdated
packages are a problem though; I have supposed that Debian would
maintain sha256sums for packages not available online any more. However
I do not see any good possibility to resolve this without support from
the distributors. However I am not sure whether outdated updates would
still be available on snapshot.debian.org; I would not believe so,
though perhaps anyone else reading this list could help us. If it is not
about updates but about singleton packages one could download specific
packages from snapshot by hand if you really come across having
installed such a package.
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
I also don't see debcheckroot make use of gpg signature verification of
Reinventing apt is difficult. See these attack on package managers:
Package metadata could be outdated. Downloaded package contents could be
malicious or altered to pass verification.
Yes, tor is no ultimate remedy to this. As long as there are little
downloads anonymity may be compromised. The best way to shield against
such attacks may be to first generate sha256sum lists in a singleton
boot and then later on use them in another boot so that no malware from
unpacking packages can persist in memory. However that is no remedy to
altered package content. The only way I know to avoid this is to only
install from blue ray media without using online updates.
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
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.
Yes, that is what I presume. apt can install compromised updates. I know
this is at least an attack vector for Windows. To repeat it I would at
least doubt if not presume about any key which is stored online that it
is compromised. Most times people connect with ssh to such machines and
have a local certificate on the computer from which they connect. The
certificate can be copied and the password will be keylogged. Only a
very few people employ security strategies like switching keyboard and
monitor to a computer where you do not web-browse or email. I have
devices for that but most people don´t and as long as the distributors
do not advertise it I presume that they do not follow such a strategy.
Finally it would still be possible to get the key by physical access to
that computer. I would also believe that for a distro like Debian this
would pay of for intelligence services.
To me personally I don´t have a defeatist mindset even not if the
NSA/CIA or similar services are attacking me. They have once deleted the
partition table on a computer used only offline to analyse some rootkit.
Those who hack me also have physical access to my computers. There is no
way for a defeatist mindset though as I can not let my human rights
including that to live be violated.
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 it isn´t. People who care about security need to acquaint themselves
with some basic facts on how the system they use is working. As it is
Linux all the information should be available for the interested user. -
and people do not only need to do so for use of debcheckroot.
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.
I have already commented on this.
Why couldn't it be fully automated without manual interpretation needed?
That is not so easy to answer but an unsuspecting novice user simply
will not be safe. There are just too many pitfalls. You do not need to
know much but you need to understand some crucial facts to my believe.
The thing why you can not automate this is that there is a hack for any
automation how it can be bypassed. Whenever I have found something it
was due to some unexpected action taken by me and not because the tools
were so super. The NSA has a billion budget (correct me if someone knows
the exact amount) and you won´t be smarter in programming than they are.
Usability and popularity. Both hard. Software is only step 1.
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.
My attack scenarios always include key loggers. They are a too valuable
tool for intelligence to miss this possibility. On the other hand my
equipment hasn´t been stolen yet. Nonetheless anyone needs to know his
enemies and what kind of attacks to shield against.
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.
debcheckroot could help getting something like verified boot for Debian.
Well it is GPLv3. Anyone who would like to extend or develop it into
some other direction is free to do so if he has enough energy and
resources to do so.
I hope I have sufficiently answered you questions and your points of
discussion. If not simply re-ask.