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
Reply to: