[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
snapshot.debian.org?

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
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.

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
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.

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.

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.

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.





Reply to: