Earlier quoted context omitted.
> As a hobbyist malware programmer myself, I know that you don't know what you're really talking about Let's see some of your code.
you write malware in Python..?
I think you meant to reply to dead_mall
Why GNU/Linux Viruses Are Fairly Uncommon
111–117 of 117 posts
Re: Why GNU/Linux Viruses Are Fairly Uncommon
#112Earlier quoted context omitted.
> 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 pa…
Science is hard. Superstition is fast and might save your job, at least for awhile.
Re: Why GNU/Linux Viruses Are Fairly Uncommon
#113Earlier quoted context omitted.
Should you really be installing programs that are impossible to build? Also phantomjs is discontinued.
That's a great question, but it does not invalidate the point that there is nothing about Nix that states that binary packages cannot and do not happen.
Try for example FHS environments. That should make it possible to install software in a conventional way.
Re: Why GNU/Linux Viruses Are Fairly Uncommon
#114Earlier quoted context omitted.
Are you a Python developer? How do you deal with the Ubuntu versions being different than the PyPI versions?
Are you a Python developer?[1] How do you deal with your project depending on an older version of a package with pip? Basically, it's just like that (but instead of specifying your version in requires.txt/setup.py, you just install a package with a particular version). You've got an older library version that gets automatic security updates but does not break backwards compatibility (or it's a bug in the distro). Ubu…
With requirements.txt, pyproject.toml/poetry, or pipenv depending on who the audience is, what conventions already exist in that community, and whether I need non-python dependencies as well. Friends don't let friends use setup.py (except sometimes you need to).
The Ubuntu versions of Flask, pymongo, and elastic are all out of date in the 18.04 (LTS) repos. Many are also out of date (although not as much) in all Canonical repos. Flask at least is missing security patches (bad) or the version number is misleading because they silently backported the fix (almost worse) in LTS. I've had backwards compatibility broken repeatedly by upgrading Canonical LTS versions of elastic and also numpy. It's actually happened so often that the set of tests in my CI that test with Ubuntu packages is named "what did they break this time" and can't fail the build.
I asked if you're a Python developer as it's my experience that sysadmins often think about this problem from the perspective of "use the repos, one less thing for me to manage" and developers think of it from the perspective of "I need the version of Flask that comes from PyPI, since that's what other devs will/have use(d)". I have very seldom encountered Python developers who use the distro-provided packages, and usually when I have it's because they didn't know about pip/PyPI. I apologise that the ambiguity caused offense, words are hard on computers :partyparrot:
Re: Why GNU/Linux Viruses Are Fairly Uncommon
#115Earlier quoted context omitted.
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 pa…
Science is hard. Superstition is fast and might save your job, at least for awhile.
I want this on a shirt.
Re: Why GNU/Linux Viruses Are Fairly Uncommon
#116Earlier quoted context omitted.
> I think the real answer is that relatively few people use GNU/Linux 95% of the server market, though. Which is a huge proportion of attack space. Why steal one sod's credit card numbers when you can steal 100s of them at the same time.
When you attack a server, you don't use a virus, you use a phish or something else to gain access to it to do your dirty bidding. What people call "viruses" usually refer only to attacks that work by getting people to execute random crap on their computer with their privileges. Servers are set up and administered in a way such that it is far harder to get somebody to run the payload containing the virus in the first…
>Servers are set up and administered in a way such that it is far harder to get somebody to run the payload containing the virus in the first place
So this is why the 'curl | bash' idiom feels like an anti-pattern to me...
Re: Why GNU/Linux Viruses Are Fairly Uncommon
#117Earlier quoted context omitted.
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: https://i.imgur.com/xpSiMMY.png https://i.imgur.com/ACLydv0.png
Interesting! Looks like my memory failed me, the one time I don't double check...