Re: Malware find in the news: xz related.

The Natural Philosopher <tnp@invalid.invalid> wrote:

On 06/04/2024 15:40, Rich wrote:

MarioCCCP <NoliMihiFrangereMentulam@libero.it> wrote:

apart from all tech details, had the chap that put this
backdoor in the systems been detained yet ?

 
Last reports have been that no one knows who is behind the Jia Tan name
in real life.
 

Oh I think someone does..

Well, obviously, the individual(s) behind the Jia Tan name know their
own name(s).

If they were, as has been surmised, for pay state actors, then their
bosses also know their names (and also may know what they were up to).

But so far we've not been made privy to those details, so if anyone
outside the ones behind the nick and/or their bosses (if they are
employed by one of the world's governments) know the names, such
details having been revealed to the greater world.

So if that info is not "being withheld" then it is reasonable to
presume that no one has been detained yet.
 
And, if the attack, given its patience and sophistication, is as some
surmise, the work of state actors in the employ of their government
(i.e. NSA, CIA, Russia, China, North Korea, etc.) then it is unlikely
that anyone will ever be detained nor will anyone be named.

 
It is at least comforting that if it were, they must not already have
such access, or they would not have bothered.

There is that.  Other than a govt. sponsored entity wanting to insert
plural back doors so that should one be found, they still have another
to utilize.  And in this case the backdoor was caught before it was
deployed.

On the other hand, a compression library did also give a good cover for
hiding the actual package.  The actual backdoor was hiding inside
purported "broken test archives" for testing the error handling paths
of the compression library.  The test data had been "broken" in a
reversible way so that the autoconf changes could "unbreak" the xz
archives and actually extract the payloads.

Other libraries that are not parsers for binary data formats will not
normally have binary test data blobs for their unit tests in their
tests section, so any back door code has fewer hidden 'caves' into
which to hide itself.  Note, I'm not saying this means non-crompression
libraries are /safe/ from an attack like this.  All I'm saying is there
are fewer hidden corners to stuff things when there are no binary blobs
as part of the build/test process.  So the process of hiding the
payload from view becomes much more difficult.