Re: Mitigating malicious packages in gnu/linux
On Tue, Nov 19, 2019 at 7:30 PM Georgi Guninski wrote: > * What do linux vendors to avoid malicious packages? Some folks do audits of changes to upstream code, some folks run static analysis tools on upstream code. > * As end user what can I do to mitigate malicious packages? Compartmentalise your computing, either with multiple computers or using something like Qubes: https://www.qubes-os.org/ > 1. This already happened in 2003 with the micq package in debian: unnoticed > easter egg causing DOS, see [1]. Detecting this requires inspection of code changes. It isn't clear how many people inspect changes in the software they use or maintain packages of. > 2. This already happened to Redhat in 2008? see [5], Red Hat OpenSSH Backdoor > Vulnerability Sounds like it would be blocked by a proper Reproducible Builds setup: https://reproducible-builds.org/ > 3. In 2015 Microsoft issued weird update, see [6],[7]. Weird indeed. > 4. Portable malware in portable languages (Java, Javascript), taking the > worst from windoze. Not sure what you refer to here. > 5. Google play. Google play has about 2.8M packages [2] for android. Debian > has about 31K packages [3] XXXold_stat. To our surprise google play is only > about 90 times bigger than debian per number of packages and the metrics > is unclear for size of binary packages or lines of code. Google scans for > malware, not sure how effective is this.Google's permissions of applications > are mitigating factor. We often hear stories about how Google Play is full of applications that spy on you. There hasn't been much research on that in Debian, but there are definitely privacy issues in Free Software too, some examples for Debian are listed here: https://wiki.debian.org/PrivacyIssues > 6. The art of backdooring: sufficiently sophisticated backdoor is > indistinguishable from secure code, see Obfuscation contest [4]. Anyone who sees code from the IOCCC or similar code in the real world will be immediately suspicious of it since it is obviously obfuscated. Code from the Underhanded Contests is far more concerning since it aims to look like real code but be subtly buggy: http://underhanded-c.org/ https://underhandedcrypto.com/ https://u.solidity.cc/ https://underhanded.rs/ > 7. Getting root vs reading $HOME vs euid == DAEMON. Getting root is important, > but there is more interesting in user's $HOME. Things like multiple devices, Qubes, Flatpak and other containerisation tools can help here, but all code has had bugs in the past that can help crossing those boundaries, including network firmware, network drivers, virtual machines, kernels, container tools etc. -- bye, pabs https://wiki.debian.org/PaulWise
Re: debcheckroot v2.0 released
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. > 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 saying that as a fairly technical user. (Maintaining Debian derivative distributions...) Users need very detailed step-by-step instructions. This is my experience from over 7 years of Whonix user support. Murphy's law. Anything can go wrong, will go wrong. Keep it simple stupid (KISS). Some stuff on usability: Quote To Toggle, or not to Toggle: The End of Torbutton https://blog.torproject.org/blog/toggle-or-not-toggle-end-torbutton > mike, am i completely anonymized if i log onto my facebook account? im using firefox 3.6 with tor and no script on windows 7 machine. thank you. Quote https://www.bbc.com/news/technology-20445632 > In order to make sure the mobile phone frequencies are not being tracked, I would fill up a washbasin with water and put the lid of a rice cooker over my head while I made a phone call," said one interviewee, a 28-year-old man who left the country in November 2010. [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. Generating the (sha256) files required for later verification could be done using an apt or dpkg hook. 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. 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 could be a Debian package that gets installed in the running system. And then starts preparing the sha256 files for later verification. It could also run the verification within the running system. That would just be an integrity check and no rootkit hunt. Since a system that is already running could be infected with a rootkit already. (Similar to debsums.) The same debcheckroot package then could also be used started from a Live USD or Live DVD and then "just" change the root (local of what debcheckroot should check) from the boot medium to the internal hard drive. debcheckroot could then verify that the existing sha256 files on the disk have valid signatures and if so, start the verification of all individual files. To a rootkit hunter which laymen can use it's a long way to go. Some 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 do I mount the internal hard drive? Or mount an internal full disk encrypted disk? Then run debcheckroot on it? Could this be fully automated so these tests can be run routinely, easy? Graphical user interface? Run debcheckroot fully automated at boot (from read-only boot 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? https://www.whonix.org/wiki/Kicksecure#iPhone_and_Android_Level_Security_for_Linux_Desktop_Distributions Cheers, Patrick Elmar Stellnberger: > 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 De
Mitigating malicious packages in gnu/linux
As end user and contributor of gnu/linux, I am concerned about malicious packages (either hostile developers or hacked developers or another reason) and have two questions: * What do linux vendors to avoid malicious packages? * As end user what can I do to mitigate malicious packages? Some thoughts and rants: 1. This already happened in 2003 with the micq package in debian: unnoticed easter egg causing DOS, see [1]. 2. This already happened to Redhat in 2008? see [5], Red Hat OpenSSH Backdoor Vulnerability 3. In 2015 Microsoft issued weird update, see [6],[7]. 4. Portable malware in portable languages (Java, Javascript), taking the worst from windoze. 5. Google play. Google play has about 2.8M packages [2] for android. Debian has about 31K packages [3] XXXold_stat. To our surprise google play is only about 90 times bigger than debian per number of packages and the metrics is unclear for size of binary packages or lines of code. Google scans for malware, not sure how effective is this.Google's permissions of applications are mitigating factor. 6. The art of backdooring: sufficiently sophisticated backdoor is indistinguishable from secure code, see Obfuscation contest [4]. 7. Getting root vs reading $HOME vs euid == DAEMON. Getting root is important, but there is more interesting in user's $HOME. [1](https://lists.debian.org/debian-devel/2003/02/msg00771.html) [2](https://www.statista.com/statistics/266210/number-of-available-applications-in-the-google-play-store/) [3](https://sources.debian.org/stats/) [4](https://ioccc.org/) [5](https://www.securityfocus.com/bid/30794/info) [6](https://j.ludost.net/blog/archives/2015/10/03/cheers_windows_admins_did_the_weird_garbled_windows_7_update_contains_message_to_microsoft/index.html) [7](https://j.ludost.net/blog/archives/2015/10/02/cheers_windows_admins_weird_garbled_windows_7_update/index.html) -- CV:https://j.ludost.net/resumegg.pdf site: http://www.guninski.com blog: https://j.ludost.net/blog
