:: Re: [DNG] ..are we|Devuan safe from…
Inizio della pagina
Delete this message
Reply to this message
Autore: marc
Data:  
To: dng
Oggetto: Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?
> >
> >> 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...

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.

Put simply if you build packages for a distribution, you are likely
to be a more attractive target than a normal user. There are many
guides and documents on how to improve security - not all particularly good.

My 2c: I believe running a modern javascript enabled browser
presents by far the biggest security risk to the average user, so
would encourage splitting browsing and code development/compilation into
either different user accounts, containers, VMs or even real devices.

And then the other heuristic: I think it is best to either run sshd or
ssh on particular machine, not both. Maybe even make the install an XOR.
Having both ssh client and server available makes it a lot easier for a bad guy
to hop along from one compromised system to another.

regards

marc