Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?

[Rick Moen]

Quoting marc (marc...@welz.org.za):

> Hello

And almost certainly goodbye.  But before that:

> > 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 :) 

You know what's really tragic, here?  I was trying to be nice -- since
your wording had left it very unclear whether you actually thought
rootkits are an attack vector.  I said it's likely you didn't, being
generous of spirit, and apologised if that were the case -- an
obvious pro-forma apology, as a way to be nice.  It would, of course, be
obvious that I had objectively offered no offence, therefore I wasn't
actually apologising, just trying to be nice about your unclear wording.

But hey, if you want to be ungracious, and act like you don't want to be
friends, I guess you do you.

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

You purport to disagree with what I said, but then throw out a lot of
word salad that doesn't address it.

I'm going to ignore that and move on.


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

Anyone who does that, I'd fire.


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

Completely irrelevant to what I was saying.

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

A tautologically true but also totally useless observation.


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

Another totally useless observation -- and also completely irrelevant to 
what I said.  _If_ you know anything about distros with competent build
infrastructures (including for example Debian), you will know that it is
for obvious reasons accessible only to the most highly trusted people.
Unless one of those happens to be Moriarty the Napoleon of Crime,
authors of *ix ELF infectors, rootkits, UDP-based backdoors, etc. can
dick around with their creations all day long and not be able to
compromise the package collection via the build infrastructure.


> There is always a first time (or a time of first discovery). 

Send a telegram.

And I believe I'm done.  Run away and play elsewhere, sonny.  I'm busy.

[rest snipped per the Law of Diminishing Returns]

-- 
Cheers,There are really only two hard problems in computer science:
Rick Moen  o  Cache invalidation policy.
r...@linuxmafia.como  Name-space management.
McQ! (4x80)o  Off-by-one errors.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?

[Steve Litt]

marc said on Fri, 7 May 2021 01:05:03 +0200


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

This is what most of us have been warning against since 2014. A big,
complex, entangled program has a lot more dark corners for bugs and
exploits to hide.

SteveT

Steve Litt 
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?

[marc]

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 

Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?

[Rick Moen]

Quoting marc (marc...@welz.org.za):

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

Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?

[Rick Moen]

Quoting Dr. Nikolaus Klepp (off...@klepp.biz):

> And there's alway the possibillity of 3rd party software, e.g. Teams,
> Appimages, ...

Always.  Looking from a distro-management perspective, doing that falls
into the broad category of "User circumvents the distro's management
regime", and naturally any result, good or bad, can follow.

But by definition, that is not a distro problem, and there is basically
no way of absolutely preventing a naive admin from shooting at his or
her foot -- at least, not short of providing Tivoised appliances rather
than general-purpose, open source distros for general purpose computing.

-- 
Cheers, Grammarian's bar joke #20:  The subjunctive 
Rick Moen   would have walked into a bar, had it only known.
r...@linuxmafia.com   
McQ! (4x80)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?

[marc]

> >
> >> 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
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?

[tito via Dng]

On Wed, 05 May 2021 19:04:10 +0900
Olaf Meeuwissen via Dng  wrote:

> Hi Martin, list,
> Martin Steigerwald writes:
> 
> > Hi!
> >
> > goli...@devuan.org - 02.05.21, 22:15:48 CEST:
> >> On 2021-05-02 06:08, terryc wrote:
> >> > Unfortunately there are systemd libraries installed by
> >> > Devuan-beowulf
> >> > desktop installation DVD.
> >>
> >> [snip]
> >>
> >> And they are harmless.
> >>
> >> Why are systemd files present in Devuan?
> >> https://dev1galaxy.org/viewtopic.php?id=1925
> >
> > No systemd library on my Devuan systems:
> >
> > % dpkg -l | grep systemd
> > [no output]
> 
> I forgot about dpkg's -l option, having gotten used to dpkg-query
> -W :-)
> 
> > Also none via locate.
> >
> > Using Plasma as desktop together with elogind.
> 
> No libsystemd0 on my beowulf machine but I did find it on a chimaera
> system I installed just a few days ago (using the alpha installer).
> 
> Curiousity peaked, I hunted it down and it turns out that my console
> only chimaera system installed it to satisfy Depends: for rsyslog,
> lvm2 and liblvm2cmd2.03.  The latter two depend on libsystemd0 (>=
> 222).
> 
> But wait a sec!  I've got lvm2 installed on my beowulf system too and
> there's no libsystemd0 to be found there!  What gives?
> 
> Turns out that libelogind0 is installed there and that happens to
> sport a Provides: libsystemd0 (= 241.4).  On chimaera the versioned
> dependency equals 246.10 (as of writing).
> 
> So people trying to get rid of the libsystemd0 package might try
> 
>   apt install libelogind0 libsystemd0-
> 
> but IIRC (and I'm relying on *very* vague memory here!) not all
> desktop environments will work with that.  FWIW, my beowulf machine
> is running fine with Xfce.
> 
Hi,

as far as I can tell having tested briefly all DEs supported by the
Debian buster installer, while working on my buster to beowulf 
migration script, nowadays all of them work with elogind/libelogind.
The only problematic Display Manager was Gnome's gdm3 which
could be easily substituted with slim or lightdm.

Ciao,
Tito  

> Hope this helps,
> --
> Olaf Meeuwissen, LPIC-2FSF Associate Member since
> 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4
> A88A F84A 2DD9 Support Free Software
> https://my.fsf.org/donate Join the Free Software
> Foundation  https://my.fsf.org/join
> ___ Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?

[Martin Steigerwald]

Olaf Meeuwissen - 05.05.21, 12:04:10 CEST:
> No libsystemd0 on my beowulf machine but I did find it on a chimaera
> system I installed just a few days ago (using the alpha installer).
> 
> Curiousity peaked, I hunted it down and it turns out that my console
> only chimaera system installed it to satisfy Depends: for rsyslog,
> lvm2 and liblvm2cmd2.03.  The latter two depend on libsystemd0 (>=
> 222).
> 
> But wait a sec!  I've got lvm2 installed on my beowulf system too and
> there's no libsystemd0 to be found there!  What gives?
> 
> Turns out that libelogind0 is installed there and that happens to
> sport a Provides: libsystemd0 (= 241.4).  On chimaera the versioned
> dependency equals 246.10 (as of writing).
> 
> So people trying to get rid of the libsystemd0 package might try
> 
>   apt install libelogind0 libsystemd0-
> 
> but IIRC (and I'm relying on *very* vague memory here!) not all
> desktop environments will work with that.  FWIW, my beowulf machine
> is running fine with Xfce.

Exactly that. I am using elogind with KDE's Plasma.

On Devuan Ceres with LVM 2. No libsystemd.

Best,
-- 
Martin


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?

[Olaf Meeuwissen via Dng]

Hi Ludovic, list,

Ludovic Bellière writes:

> Hi terryc,
>
> Those are *not* systemd libraries. They're services files or helpers
> shipped with the various packages you install.

Correct.

> It is not possible to get
> rid of them without forking nearly all debian packages,

This is not quite correct.  You can tell dpkg to --path-exclude files
that match a glob pattern.  See `man dpkg` for details.  Putting this
in your /etc/dpkg.cfg will make sure all dpkg invocations use it, apt
included.

So, adding for example

  path-exclude = /lib/systemd/*

would keep prevent installation of any matching files that a *.deb would
otherwise install.  You still have to clean up existing matching files
yourself of course.

So for those of you hell-bent on keeping files reeking of systemd off of
your systems, you can and you can do this yourselves.  If it happens to
break stuff, you get to keep the pieces but I guess mentioning breakage
here on the list will certainly peek some people's attention.

> which is beyond the scope of the devuan project.

Forking all packages that provide files you can easily prevent from
getting installed yourself is indeed beyond the scope of de Devuan
project if you ask me.  There's plenty of other stuff to be done.

> The service files are text files and benign.

I've found them to waste disk space on the one hand and provide useful
info to fix issues on the other.  Your experience may vary.

> Your system **is without** systemd.

> On dim, 02 mai 2021, terryc wrote:
>
>> Unfortunately there are systemd libraries installed by Devuan-beowulf
>> desktop installation DVD.
>>
>> There are in
>> /ver/lib/

Huh>  /ver/lib, really?  I think you mean /usr/lib.

>> /lib
>> /etc and
>> /run
>>
>> It appears to be something in the base system as both the headless
>> systems I recently set up have/had* them.

As I mentioned in a previous post, I found that rsyslog and the use of
LVM have a dependency on libsystemd0.  That dependency can be satisfied
by installing libelogind0 instead of it.

>> Optins selected were
>> console stuff
>> print server,
>> ssh server
>> and what ever is last.
>>
>> One system did have xfce-xfce4 selected, but the libraries and not
>> dependant on these.
>>
>> *rm -rf systemd on the relevant directories doesn't seem to affect
>> anything. I did this as 'aptitude search systemd' didn't list any
>> packages installed.
>>
>> Memo to self; use minimal installation next time.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?

[Olaf Meeuwissen via Dng]

Hi Martin, list,
Martin Steigerwald writes:

> Hi!
>
> goli...@devuan.org - 02.05.21, 22:15:48 CEST:
>> On 2021-05-02 06:08, terryc wrote:
>> > Unfortunately there are systemd libraries installed by
>> > Devuan-beowulf
>> > desktop installation DVD.
>>
>> [snip]
>>
>> And they are harmless.
>>
>> Why are systemd files present in Devuan?
>> https://dev1galaxy.org/viewtopic.php?id=1925
>
> No systemd library on my Devuan systems:
>
> % dpkg -l | grep systemd
> [no output]

I forgot about dpkg's -l option, having gotten used to dpkg-query -W :-)

> Also none via locate.
>
> Using Plasma as desktop together with elogind.

No libsystemd0 on my beowulf machine but I did find it on a chimaera
system I installed just a few days ago (using the alpha installer).

Curiousity peaked, I hunted it down and it turns out that my console
only chimaera system installed it to satisfy Depends: for rsyslog, lvm2
and liblvm2cmd2.03.  The latter two depend on libsystemd0 (>= 222).

But wait a sec!  I've got lvm2 installed on my beowulf system too and
there's no libsystemd0 to be found there!  What gives?

Turns out that libelogind0 is installed there and that happens to sport
a Provides: libsystemd0 (= 241.4).  On chimaera the versioned dependency
equals 246.10 (as of writing).

So people trying to get rid of the libsystemd0 package might try

  apt install libelogind0 libsystemd0-

but IIRC (and I'm relying on *very* vague memory here!) not all desktop
environments will work with that.  FWIW, my beowulf machine is running
fine with Xfce.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?

[Dimitris via Dng]

Στις 5/5/21 11:49 π.μ., ο/η Dr. Nikolaus Klepp έγραψε:

And there's alway the possibillity of 3rd party software, e.g. Teams, 
Appimages, ...


true...
i misread original question, thought it was asking about devuan 
installation process and not already installed systems..


d.



OpenPGP_signature
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?

[Dr. Nikolaus Klepp]

Anno domini 2021 Wed, 5 May 11:42:09 +0300
 Dimitris via Dng scripsit:

> only thing i can think of, is by installing  unverified firmware files 
> from a removable drive during installation, mainly because i'm not sure 
> how verifiable firmware blobs are...
> every other package (including a DE) is always installed from 
> authenticated sources/mirrors (and mostly reproducible these days), so 
> it should be assumed malware-free.
> 
> 2c.
> d.
> 
> 

And there's alway the possibillity of 3rd party software, e.g. Teams, 
Appimages, ...

Nik


-- 
Please do not email me anything that you are not comfortable also sharing with 
the NSA, CIA ...
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?

[Dimitris via Dng]

Στις 4/5/21 11:05 μ.μ., ο/η Arnt Karlsen έγραψε:

So, there ya go:  Avoid installing and running it.  It's called system
administration


simple and powerful advice :)



..very true.  Are there ways to trick common Devuan installs
into automatically installing these bad things?
(Other than tricking newbie etc users, sysadmins etc into
doing it?)



only thing i can think of, is by installing  unverified firmware files 
from a removable drive during installation, mainly because i'm not sure 
how verifiable firmware blobs are...
every other package (including a DE) is always installed from 
authenticated sources/mirrors (and mostly reproducible these days), so 
it should be assumed malware-free.


2c.
d.



OpenPGP_signature
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?

[Rick Moen]

Quoting Arnt Karlsen (a...@iaksess.no):

> ..very true.  Are there ways to trick common Devuan installs 
> into automatically installing these bad things?  
> (Other than tricking newbie etc users, sysadmins etc into 
> doing it?)

I don't see any particular structural accidents waiting to happen,
above and beyond the norm in Unix.  (OTOH, I don't spend a lot of time
studying Desktop Environments.  Someone else might do a better job
at spotting, e.g., software structures likely to lull unwary desktop 
users into carrying out dangerous actions.)


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?

[Arnt Karlsen]

On Tue, 4 May 2021 10:00:25 -0700, Rick wrote in message 
<20210504170025.gb18...@linuxmafia.com>:

> Quoting Arnt Karlsen (a...@iaksess.no):
> 
> > On Fri, 30 Apr 2021 14:37:20 +0200, Arnt wrote in message 
> > <20210430143720.7311bc82@d44>:
> > 
> >   
> > > https://www.theregister.com/2021/04/29/stealthy_linux_backdoor_malware_spotted/
> > >
> > 
> > ..how it works:
> > https://blog.netlab.360.com/stealth_rotajakiro_backdoor_en/  
> 
> Answer:  Avoid installing and running it.
> 
> This isn't any kind of intrusion tool, just yet another backdoor
> program that can be installed and activated after intrusion through
> other means entirely -- indistinguishable except in fine detail from
> countless others that have existed for decades.  And _TheReg_ was
> very clear about that:
> 
>   The malware is not an exploit; rather it's a payload that opens a
>   backdoor on the targeted machine. It might be installed by an
>   unsuspecting user, an intruder, or through a dropper Trojan. How
>   RotaJakiro has been distributed remains unanswered.
> 
> So, there ya go:  Avoid installing and running it.  It's called system
> administration.

..very true.  Are there ways to trick common Devuan installs 
into automatically installing these bad things?  
(Other than tricking newbie etc users, sysadmins etc into 
doing it?)


-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?

[Rick Moen]

Quoting Arnt Karlsen (a...@iaksess.no):

> On Fri, 30 Apr 2021 14:37:20 +0200, Arnt wrote in message 
> <20210430143720.7311bc82@d44>:
> 
> 
> > https://www.theregister.com/2021/04/29/stealthy_linux_backdoor_malware_spotted/
> >  
> 
> ..how it works:
> https://blog.netlab.360.com/stealth_rotajakiro_backdoor_en/

Answer:  Avoid installing and running it.

This isn't any kind of intrusion tool, just yet another backdoor program
that can be installed and activated after intrusion through other means
entirely -- indistinguishable except in fine detail from countless
others that have existed for decades.  And _TheReg_ was very clear about
that:

  The malware is not an exploit; rather it's a payload that opens a
  backdoor on the targeted machine. It might be installed by an
  unsuspecting user, an intruder, or through a dropper Trojan. How
  RotaJakiro has been distributed remains unanswered.

So, there ya go:  Avoid installing and running it.  It's called system
administration.

-- 
Cheers,  Grammarian's bar joke #26:  A gerund and an 
Rick Moeninfinitive walk into a bar, drinking to forget.
r...@linuxmafia.com   
McQ! (4x80)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?

[Martin Steigerwald]

Hi!

goli...@devuan.org - 02.05.21, 22:15:48 CEST:
> On 2021-05-02 06:08, terryc wrote:
> > Unfortunately there are systemd libraries installed by
> > Devuan-beowulf
> > desktop installation DVD.
> 
> [snip]
> 
> And they are harmless.
> 
> Why are systemd files present in Devuan?
> https://dev1galaxy.org/viewtopic.php?id=1925

No systemd library on my Devuan systems:

% dpkg -l | grep systemd
[no output]

Also none via locate.

Using Plasma as desktop together with elogind.

Best,
-- 
Martin


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?

[golinux]

On 2021-05-02 06:08, terryc wrote:


Unfortunately there are systemd libraries installed by Devuan-beowulf
desktop installation DVD.




[snip]

And they are harmless.

Why are systemd files present in Devuan?
https://dev1galaxy.org/viewtopic.php?id=1925

golinux
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?

[Ludovic Bellière]

Hi terryc,

Those are *not* systemd libraries. They're services files or helpers
shipped with the various packages you install. It is not possible to get
rid of them without forking nearly all debian packages, which is beyond
the scope of the devuan project. The service files are text files and
benign.

Your system **is without** systemd.

Cheers,
Ludovic

On dim, 02 mai 2021, terryc wrote:

> On Sat, 1 May 2021 17:11:48 +0200
> Didier Kryn  wrote:
> 
> Unfortunately there are systemd libraries installed by Devuan-beowulf
> desktop installation DVD.
> 
> There are in
> /ver/lib/
> /lib
> /etc and
> /run
> 
> It appears to be something in the base system as both the headless
> systems I recently set up have/had* them.
> 
> Optins selected were
> console stuff
> print server,
> ssh server
> and what ever is last.
> 
> One system did have xfce-xfce4 selected, but the libraries and not
> dependant on these.
> 
> *rm -rf systemd on the relevant directories doesn't seem to affect
> anything. I did this as 'aptitude search systemd' didn't list any
> packages installed.
> 
> Memo to self; use minimal installation next time.


signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?

[terryc]

On Sat, 1 May 2021 17:11:48 +0200
Didier Kryn  wrote:

> Le 30/04/2021 à 15:05, Arnt Karlsen a écrit :
> > On Fri, 30 Apr 2021 14:37:20 +0200, Arnt wrote in message 
> > <20210430143720.7311bc82@d44>:
> >
> >  
> >> 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.
> 
>     It is not very surprising that systemd is targetted, since it is
> present (by force) in most installed Linux systems.

Unfortunately there are systemd libraries installed by Devuan-beowulf
desktop installation DVD.

There are in
/ver/lib/
/lib
/etc and
/run

It appears to be something in the base system as both the headless
systems I recently set up have/had* them.

Optins selected were
console stuff
print server,
ssh server
and what ever is last.

One system did have xfce-xfce4 selected, but the libraries and not
dependant on these.

*rm -rf systemd on the relevant directories doesn't seem to affect
anything. I did this as 'aptitude search systemd' didn't list any
packages installed.

Memo to self; use minimal installation next time.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?

[Didier Kryn]

Le 01/05/2021 à 17:50, Florian Zieboll via Dng a écrit :
> Hallo Didier,
>
> why do you think it's targeting only systems with systemd or gvfs
> installed? At a first glance, I don't see any hints towards this
> conclusion besides the fact that the installer / dropper of this very
> sample did name the executables accordingly and provides a systemd
> "service" file. It should be easily realizable to automatically choose
> other names, depending on the targeted environment.
>
> The Netlab blog post even states:
>
> ||  Depending on the Linux distribution, create the corresponding
> ||  self-starting script /etc/init/systemd-agent.conf
> ||  or /lib/systemd/system/sys-temd-agent.service.
>
> AFAIK, the directory '/etc/init/' is only created/used by resp. for the
> 'upstart' init system, thus I assume that also (at least) those systems
> are covered as well.

    Apparently I overlooked it a bit, however, if neither systemd nor
gvfs are explicitely targetted, systems running these softwares are. If
the executables are named systemd-daemon and gvfsd, it's for the process
names to be the same and not alarm the admin.

    If I discovered on one of  my Devuan machines a process named
systemd-what-the-f or gvfs-something, I would immediately kill it and
try to find where it comes from. But if I was running Gnome on Debian, I
certainly wouldn't.

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?

[Florian Zieboll via Dng]

On Sat, 1 May 2021 17:11:48 +0200
Didier Kryn  wrote:

> Le 30/04/2021 à 15:05, Arnt Karlsen a écrit :
> > On Fri, 30 Apr 2021 14:37:20 +0200, Arnt wrote in message 
> > <20210430143720.7311bc82@d44>:
> >
> >
> >> 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.
> 
>     It is not very surprising that systemd is targetted, since it is
> present (by force) in most installed Linux systems.
> 
>     Gvfs is not expected to be installed on servers, but is required
> by some desktop goodies - even in Xfce4, for example if you install
> the tool to mount/unmount hotplug disks; it is primarily to avoid it
> that I developped hopman.


Hallo Didier,

why do you think it's targeting only systems with systemd or gvfs
installed? At a first glance, I don't see any hints towards this
conclusion besides the fact that the installer / dropper of this very
sample did name the executables accordingly and provides a systemd
"service" file. It should be easily realizable to automatically choose
other names, depending on the targeted environment.

The Netlab blog post even states:

||  Depending on the Linux distribution, create the corresponding
||  self-starting script /etc/init/systemd-agent.conf
||  or /lib/systemd/system/sys-temd-agent.service.

AFAIK, the directory '/etc/init/' is only created/used by resp. for the
'upstart' init system, thus I assume that also (at least) those systems
are covered as well.


libre Grüße,
Florian

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?

[Didier Kryn]

Le 01/05/2021 à 17:38, Tomasz Torcz a écrit :
> Dnia Sat, May 01, 2021 at 05:11:48PM +0200, Didier Kryn napisał(a):
>> Le 30/04/2021 à 15:05, Arnt Karlsen a écrit :
>>> On Fri, 30 Apr 2021 14:37:20 +0200, Arnt wrote in message 
>>> <20210430143720.7311bc82@d44>:
>>>
>>>
 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.
>   Can you prove that?  The analysis you linked shows nothing like that:
> - gvfsd is only used as a part of name of backdoor binary, there seem to be no
>   interaction with real gvfsd at all
> - first file described in analysis is an _upstart_ configuration file
>
    Then I misread. Or overlooked. Not my mothertongue (~:

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?

[Tomasz Torcz]

Dnia Sat, May 01, 2021 at 05:11:48PM +0200, Didier Kryn napisał(a):
> Le 30/04/2021 à 15:05, Arnt Karlsen a écrit :
> > On Fri, 30 Apr 2021 14:37:20 +0200, Arnt wrote in message 
> > <20210430143720.7311bc82@d44>:
> >
> >
> >> 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.

  Can you prove that?  The analysis you linked shows nothing like that:
- gvfsd is only used as a part of name of backdoor binary, there seem to be no
  interaction with real gvfsd at all
- first file described in analysis is an _upstart_ configuration file

-- 
Tomasz Torcz   “(…) today's high-end is tomorrow's embedded processor.”
to...@pipebreaker.pl  — Mitchell Blank on LKML

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?

[Didier Kryn]

Le 30/04/2021 à 15:05, Arnt Karlsen a écrit :
> On Fri, 30 Apr 2021 14:37:20 +0200, Arnt wrote in message 
> <20210430143720.7311bc82@d44>:
>
>
>> 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.

    It is not very surprising that systemd is targetted, since it is
present (by force) in most installed Linux systems.

    Gvfs is not expected to be installed on servers, but is required by
some desktop goodies - even in Xfce4, for example if you install the
tool to mount/unmount hotplug disks; it is primarily to avoid it that I
developped hopman.

--     Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?

[Arnt Karlsen]

On Fri, 30 Apr 2021 14:37:20 +0200, Arnt wrote in message 
<20210430143720.7311bc82@d44>:


> https://www.theregister.com/2021/04/29/stealthy_linux_backdoor_malware_spotted/
>  

..how it works:
https://blog.netlab.360.com/stealth_rotajakiro_backdoor_en/

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?

[Arnt Karlsen]

Spam detection software, running on the system "tupac3.dyne.org",
has identified this incoming email as possible spam.  The original
message has been attached to this so you can view it or label
similar future email.  If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview:  Hi, ..are we|Devuan safe from this systemd backdoor malware,
   taking a lot of our .debs, kernels etc, from Debian? ..from El Reg: 
https://www.theregister.com/2021/04/29/stealthy_linux_backdoor_malware_spotted/
   

Content analysis details:   (6.1 points, 5.0 required)

 pts rule name  description
 -- --
 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in
bl.spamcop.net
  [Blocked - see ]
 3.6 RCVD_IN_SBL_CSSRBL: Received via a relay in Spamhaus SBL-CSS
[23.129.64.232 listed in zen.spamhaus.org]
 0.0 RCVD_IN_MSPIKE_H3  RBL: Good reputation (+3)
[46.30.212.3 listed in wl.mailspike.net]
-0.0 SPF_HELO_PASS  SPF: HELO matches SPF record
-0.1 DKIM_VALID_EF  Message has a valid DKIM or DK signature from
envelope-from domain
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
 0.1 DKIM_SIGNEDMessage has a DKIM or DK signature, not necessarily
valid
-0.1 DKIM_VALID_AU  Message has a valid DKIM or DK signature from
author's domain
 1.5 RCVD_IN_SORBS_WEB  RBL: SORBS: sender is an abusable web server
[23.129.64.232 listed in dnsbl.sorbs.net]
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust
[46.30.212.3 listed in list.dnswl.org]
 0.0 RCVD_IN_MSPIKE_WL  Mailspike good senders


--- Begin Message ---
Hi,


..are we|Devuan safe from this systemd backdoor malware, taking a lot of
our .debs, kernels etc, from Debian?  

..from El Reg:
https://www.theregister.com/2021/04/29/stealthy_linux_backdoor_malware_spotted/

..it would be about as easy to sneak it in and make it run on our 
init systems, but also quite a bit easier to discover by competent
users and sysadmins.

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.
--- End Message ---
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng