Ctrl+f "iot"
Ctrl+f "Mirai"
Oh, it's a joke. Got it.
Why GNU/Linux Viruses Are Fairly Uncommon
61–70 of 117 posts
Re: Why GNU/Linux Viruses Are Fairly Uncommon
#62Earlier quoted context omitted.
This plus reproducible builds will go a long ways toward preventing it.
I would be careful about claiming built artifacts play much role in the visibility of repository-delivered malware. Consider "reflections on trusting trust" for attacks on reproducible builds, and also that all the major scripting languages (PyPI, Ruby gems, and npm) have had malicious packages inserted over the last year or so.
> all the major scripting languages (PyPI, Ruby gems, and npm) have had malicious packages inserted
None of those package repositories are maintained by a limited set of curators.
Debian's repositories and other linux distributions repositories are curated.
Uploading a malicious package to npm is as easy as typing 'npm publish'.
> "reflections on trusting trust"
It's a very useful piece of art and a thought experiment.
In practice, it's not interesting for the average package. Very few packages are self-hosting and in such a position to leverage that sort of clever trickery.
A good debian maintainer will also review code of their packages and make sure such trickery has no chance to be afood (e.g. by preventing a gem from downloading a custom ruby interpreter to bootstrap itself, but rather manually bootstrapping up themselves).
Re: Why GNU/Linux Viruses Are Fairly Uncommon
#63Earlier quoted context omitted.
You could even replace every command I run with a malware version simply by altering the $PATH in ~/.bashrc. If you manage to replace, say, apt-get with a malware version, you'll get admin permissions every time I run `sudo apt-get ...`.
If your sudo is configured correctly it will have an administrator defined PATH. However if you have sudo price to run apt-get, anything that could manipulate your rc files can just run sudo apt-get on its own. No need to trick you.
Unless it doesn't have your password, and sudo is configured to require auth to elevate. This is the STIG requirement for this exact reason
Edit: of course, it could just manipulate the path to include it's own evil sudo wrapper, but the chess match always sounds like this.
Re: Why GNU/Linux Viruses Are Fairly Uncommon
#64Ctrl+f "iot" Ctrl+f "Mirai" Oh, it's a joke. Got it.
Leaving your door wide open isn't anyone's fault but your own. All the configurations and procedures for secure devices were there but manufactures couldn't bother.
Re: Why GNU/Linux Viruses Are Fairly Uncommon
#65Earlier quoted context omitted.
Nix/Guix are quite cool to tackle this. They are progressing quite quickly towards reproducible builds, so you can avoid compromised servers sending malicious binaries. Also, since package definitions are quite declarative, I guess it's easier to perform static verification to spot malicious code getting introduced there. There's e.g. Vulnix that scans for CVEs [1]. [1] https://github.com/flyingcircusio/vulnix
NixOS (and NixPkgs) is great, but there are still plenty of binary only packages from difficult to build projects like PhantomJS in the ecosystem. It takes a serious commitment to build complex projects in Nix and maintain them. (edit) An example of binary packages in Nixpkgs: https://github.com/NixOS/nixpkgs/blob/master/pkgs/developmen...
Should you really be installing programs that are impossible to build? Also phantomjs is discontinued.
Re: Why GNU/Linux Viruses Are Fairly Uncommon
#66Earlier quoted context omitted.
I would be careful about claiming built artifacts play much role in the visibility of repository-delivered malware. Consider "reflections on trusting trust" for attacks on reproducible builds, and also that all the major scripting languages (PyPI, Ruby gems, and npm) have had malicious packages inserted over the last year or so.
> all the major scripting languages (PyPI, Ruby gems, and npm) have had malicious packages inserted None of those package repositories are maintained by a limited set of curators. Debian's repositories and other linux distributions repositories are curated. Uploading a malicious package to npm is as easy as typing 'npm publish'. > "reflections on trusting trust" It's a very useful piece of art and a thought experimen…
The point of "... trusting trust" is not really the specific bug, but rather the observation that the whole supply chain matters. Built artifacts as exist on disk in the repo are a relatively small piece of that.
> None of those package repositories are maintained by a limited set of curators.
It's always interesting to me how few people seemingly know this. Python package maintainers realize how easy it is to add packages to PyPI, but many admins and even SOC operators inherently trust it because they think that it "must be reviewed by someone".
Also, there have been plenty of security issues with Ubuntu and Debian: https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue52#Commu... https://www.linuxinsider.com/story/32240.html
Also there have been bugs in apt: https://www.fosslinux.com/6167/massive-security-bug-found-in...
Also the official ISO from the Mint website: https://arstechnica.com/information-technology/2016/02/linux...
Also the AUR malware mentioned on thread: https://www.bleepingcomputer.com/news/security/malware-found...
Also the kernel.org compromise: https://www.zdnet.com/article/linux-kernel-source-code-repos...
Edit: let's throw in the redhat ceph intrusion while we're at it (note that this includes InkTank). https://www.zdnet.com/article/red-hats-ceph-and-inktank-code...
Re: Why GNU/Linux Viruses Are Fairly Uncommon
#67Its a pet peeve of mine that the GNU/Linux world is 99% of the way to an incredible degree of security but distros are totally disinterested in going the last mile, often because its a lot of boring work. Mandatory Access Control should have been game changing in the security sphere, especially in the era of cgroups. Fine grained permissions controls in the kernel and filesystem would stomp out almost all potential m…
I like the pledge model. If one's assumptions are wrong, the program fails.
Re: Why GNU/Linux Viruses Are Fairly Uncommon
#68Earlier quoted context omitted.
Nix/Guix are quite cool to tackle this. They are progressing quite quickly towards reproducible builds, so you can avoid compromised servers sending malicious binaries. Also, since package definitions are quite declarative, I guess it's easier to perform static verification to spot malicious code getting introduced there. There's e.g. Vulnix that scans for CVEs [1]. [1] https://github.com/flyingcircusio/vulnix
I believe they aren’t just progressing towards reproducible builds, but that the whole system is already predicated on them. In Nix, you have to make special exceptions for packages that aren’t rebuildable from source.
[deleted]
Re: Why GNU/Linux Viruses Are Fairly Uncommon
#69Re: Why GNU/Linux Viruses Are Fairly Uncommon
#70Earlier quoted context omitted.
>Obviously this isn't something that could not be fixed in Windows, and maybe it already has been. There is nothing even remotely obvious about that statement. If it was anything near possible it wouldn't an ongoing problem, unsolved for the last 12 years, since the introduction of UAC in Windows Vista. Now I wouldn't say that Microsoft didn't progress. Far from it. Almost no one I knew kept Vista UAC enabled, as it…
The main flaws with UAC is that you don't know what application is asking for it (This actually ties into a deeper problem which is, you don't know where application binaries reside, and applications are less predictable on Linux). Instead you have to correlate with what you've done recently, which might not align with the process that requested permission.
This is not true. Here, I took these screenshots for you where I copied an unsigned binary to a random location and forced a UAC prompt:
https://i.imgur.com/BSJlSAf.png
https://i.imgur.com/4ZVNsPN.png
I also did the same with a signed binary:
