Means the only real fix is to use systems with non-Intel processor.
My computer continues to be attacked... and I continue to learn more about the problem/problems.
First, the latest attempt was trying to insert a virus which my system caught: “An incoming request to permit remote debugging connection was detected. A remote client can take complete control over your browser.”
The client endpoint: 127.0.0.1:53792
Then server endpoint: 127.0.0.1:53788
Coincident event tried to create a changed file: OnDemandConnectionRouteHelper.dll
Related problems include:
Second, Linux based systems have implemented recent updates that include Snap packages. The change is inherently insecure, as it outsources a decentralized control over packages with the control delegated to the originating sources giving them full control over the package content without independent verification. One bad actor in one software supplier can thus defeat the entire security structure in the entire linux distribution as that structure includes that corrupted source as a trusted distributor.
Third, Intel (and AMD) has a massive problem with the microcodes that, in theory, exist as firmware insertions on the chip which are intended to enable Intel in correcting discovered vulnerabilities that are inherent in the chip as “design flaws”... correcting for them by a firmware fix.
In practice, that means Intel (and AMD)products are “pre-hacked chips” with “flaws” that preexist. That requires only that a hacker know what the chip weaknesses are to exploit them, before a microcode fix is enabled. Or, otherwise, it requires only that a hacker gain control of the dynamic code that controls the microcode. Getting that control allows them them to open and control access to the design “flaws” in the chip. Whether there is a microcode “fix” available for the flaws that are discovered and made public or not, if a hacker can gain control over the files that control “the fix”... they can still control the chip.
See for instance:
How to actually disable Intel (and AMD) microcode updates...
http://www.reddit.com/r/overclocking/comments/enm8yj/how_to_actually_disable_intel_and_amd_microcode/
Changing microcodes screws with the users ability to control the overclocking of a processor... so the hackers found a workaround.
The linked article is focused on Windows systems, and names the relevant files that control the microcode... but similar files exist for all other operating systems.
To maintain control over your computer, you need to be able to maintain control over those files that control the microcode... so, you have to lock those files down to prevent them being changed...
But, the “flaws” in the chips obviously aren’t accidental flaws... they are designed backdoors... created to ensure those who do know what they are can circumvent your systems ability to exert real control over access. Hackers who can figure out what those backdoors are... can exploit them just as well as those who designed them...
And that, of course, is a reason to not design hacks into the chips in the first place...
Fourth, operating systems that automatically download “updates” are inherently insecure... because the “trusted providers” of the updates... truly CANNOT BE TRUSTED.
That includes, particularly, Microsoft... and at least Canonical (Ubuntu) among the linux OS providers, or at least its failed control over Snap installations of insecure software.
The best you can do... is exercise manual control over your essential systems... and “lock down” access to your basic files as much as possible, including, obviously, shutting down all remote access, open ports that provide backdoor comms, etc.