Quoting marc (marcxdv@???):

> > >
> > >> https://www.theregister.com/2021/04/29/stealthy_linux_backdoor_malware_spotted/
> > > ..how it works:
> > > https://blog.netlab.360.com/stealth_rotajakiro_backdoor_en/
> >
> >
> > This backdoor is targetting systemd and gvfs.
>
> So the below words aren't directed at anybody in particular:
>
> It is easy to gloat
>
> And it is true that this particular bit of malware tries to blend in
> amongst the many cryptic helper processes that both systemd-based
> distributions and gnome desktops launch. A simpler system, where
> there are fewer processes provides fewer hiding places.
>
> So simple is good, and it is even better to know what each user
> process in "ps ax" does, and investigate if the listing looks
> different...
>
> However, it also needs to be said that there are rootkits which
> patch ps and ls to hide their executables. Even scarier ones
> patch the kernel or even hard disk controller firmware...

May I interject, here?

It's irrational to talk about rootkits as if they were a security threat
(and my apologies in advance if, as seems likely, you're fully aware of
the difference; in these discussions, there will always be other readers
who don't.

By definition, a rootkit is a set of coverup tools installed by an
intruder _after stealing root via other means entirely). The point is
that focussing on what bad guys do after they broken into your system
and cracked the root account is largely a waste of time: After they
have completely broken security, they can do anything at all, and what
particular thing they choose do isn't very interesting -- or relevant
to system administration. What _is_ interesting and relevant is how
the bad guys got in and how they escalated privilege to root. And those
questions are the ones relevant to system administration.

> And as has been pointed out: We don't know how this malware gets
> installed in the first place. Something which has gotten fashionable
> very recently is the "supply-chain attack", where the bad guys don't
> break into your system directly, but into the systems which
> build the software you run...
>
> ... and in the case of devuan the attack risk is a bit larger
> than for some other distributions, in that it is effectively
> two distributions - debian plus the local changes. In a way
> this doubles the risk... so it seems best to stay humble and
> careful.

Quite correct (though I could cavil about 'double') -- but with a
significan number of competent system administrators testing and running
Devuan, it would take a really bold would-be master criminal to do all
the work and vetting to become a Debian or Devuan package maintainer,
and his/her glory days would probably be short and the remainder of
his/her days haunted by fear of very annoyed Linux people.

But you're _actually_ talking about bad guys compromising the
binary-package build infrastructure. Which, well, good luck. Even the
most striking attacks against distro infrastructure to date, the ones
against certain Debian Project and Gentoo Project in 2003, came nowhere
near compromising the package collections.

And that was not a freak accident. Distros are strongly motivated to
be actually competent about their supply-chain infrastructure security,
and so far have consistently been. Here is Wichert Ackerman's
comprehensive write-up about details of the 2003 debian.org compromise,
for details:
https://web.archive.org/web/20070324011514/http://www.wiggy.net/debian/developer-securing/

> Put simply if you build packages for a distribution, you are likely
> to be a more attractive target than a normal user.

Note that neither Debian Project nor Devuan Project (nor Gentoo, nor...)
accepts developer packages built on outside private hosts.


> And then the other heuristic: I think it is best to either run sshd or
> ssh on particular machine, not both.

Er, anyone who compromises a user account from remote via an sshd can
then immediately install an ssh client. Also, anyone who (somehow)
remotely compromises an ssh client and thereby gains user-level shell
access can immediately run an sshd bound to a high-numbered port (but
IMO that would be silly, as the intruder could do easier and more useful
things to create harm). Either way, there's no impediment to 'hopping
along from one compromised system to another'.

Calling either of those pieces of software a security risk in itself,
whether present singly or together, strikes me as a failure of
perspective, but that would be a much longer discussion than I wish to
have here.

Realistically, when we're talking about ssh-mediated compromise of
system security, we're basically talking about stolen and reused
security tokens (passwords or ssh keys). Like as happened in 2002 at my
then-employer:
http://linuxmafia.com/faq/Security/breakin-without-remote-vulnerability.html

If you were to speculate that my employer was VA Linux Systems and that
the embarassing theft of a token happened when a VA sysadmin ssh'd out
to shells.sourceforge.net (a shared public host that he didn't know
someone had rooted), and then ssh'd or scp'd back into the sensitive
corporate network, I would say "Hmm, no comment.'

-- 
Cheers,            Grammarian's bar joke #16:  A run-on sentence walks into a
Rick Moen          bar it starts flirting. With a cute little sentence fragment.
rick@???                                                           
McQ! (4x80)