Hello

> 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.

Apologies accepted :)

> 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.

Well, yes and no. Of course if the system is fully compromised, then
all bets are off. It does also mean that if a bad guy has broken into
a system with writable {disk,graphics,nic,bios} firmware, then the only
safe response is to throw away the hardware (owners of RPIs earlier
than v4 only need to throw away the sd card).

However, most system administrators don't do that. At best they reformat,
cross their fingers and continue.

And you will note the current rootkit under discussion has two modes - a root
mode where it pretends to be a systemd component, and a userlevel mode where
it pretends to be a bit of gnome. The latter implies that the rootkit author
doesn't have (reliable) user2root exploit available, and so hopefully the
system can be salvaged by just deleting that user account. And knowing when
to delete an account vs when to throw away the hardware seems to be
a good sysadmin competence :)

But more importantly: This is a mailing list for a distribution, and
distributions are where supply chain attacks can (or might already have)
happen(ed).

> > ... 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
> significant 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.

Some people subscribe to "with sufficient eyeballs, all bugs are shallow",
others to "three people can keep a secret, if two are dead". Interestingly
both apply - the latter when talking about who has access to the build
infrastructure...

> 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.

There is always a first time (or a time of first discovery). And
the Fates have a wicked sense of humor, and are likely to arrange
this for those who sneer about the insecure practices of others.
You know, like those who make fun of people's spelling online and
promptly have typos added to their condescending reply...

Pub quiz time: Don't they sit underneath a certain tree, which
has a strong linux connection ?

> 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.

I believe it was the lion worm in wuftpd which hid its compromise
in the mess that is the configure/autoconf/automake infrastructure.
And that was *many* years ago. Automated build environments have
only gotten more complex.

> > 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'.

My turn to apologise - I didn't mean it like that. Bad guys inevitably
install their own covert remote control protocol, usually independent
of ssh/sshd.

> 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.

The argument is simple: By partitioning the set of machines into
two (ssh vs sshd), the chain that a bad guy can compromise in the
network (using ssh weaknesses only) is only one hop long, rather than
arbitrarily long... graph theory for the win.

> 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.'

There you go :)

regards

marc