Patching old slow systems against Meltdown and Spectre?!

[wiak]

I wonder how many who have older machines (Puppy often being used on such machines) really want to upgrade their OS or kernels (or even webbrowsers) to mitigate against Meltdown and or Spectre? I don't see much discussion about this - perhaps we feel obliged because it has always been advocated that users have a responsibility to patch their systems.

So suddenly some older unpatched machines perform as well or maybe better than some newer patched ones?

Systems that are so old they are only just proving usefully usable pre-patching suddenly become a bit more obsolete - or do some just avoid the patches to keep performance up? Is it fear that makes us universally patch, or do we just patch the machine(s) we use for online banking etc...?

wiak

[musher0]

Hello wiak.

I have read a few articles and some threads here about the problem. My position is:
I stay put; I wait until someone or some company offers a cure "that is not worse than
the sickness."

Please correct me if I am wrong, but as I understand it, of the three bugs,
-- one is "naturally countered" by the Linux kernel (Puppy is a Linux distribution);

-- another is "naturally countered" if your computer has an AMD CPU (it is my case).

So I am 2/3 covered.

-- That leaves one bug (I can't remember which), but I am not too worried. These bugs
are said to have been found through computer lab experiments. It is said also that it
is quite difficult to write a program to exploit these CPU weaknesses in real world
computing activity.

Please forgive my simplistic explanations: I know next to nothing about the technical
aspects of CPUs. A summary of my current hardware is attached for reference.

BFN.

[s243a]

My defense is to run noscript.

I only allow javascript from a few trusted sites like dropbox, facebook, youtube and of course this forum.

I block all scripts on news sites as they tend to be polluted with third party adds.

P.S. I've read that newer versions of firefox reduced the percision of their times to help mitigate against this attack. If one is using firefox they should upgrade to the latest firefox. Of course on most old machines people are running palemoon. I haven't read anything about how well palemoon mitigates against these attacks. Fortunately I can run noscript on palemoon.

[musher0]

My defense is to run noscript.

I only allow javascript from a few trusted sites like dropbox, facebook, youtube and of course this forum.

I block all scripts on news sites as they tend to be polluted with third party adds.

P.S. I've read that newer versions of firefox reduced the percision of their times to help mitigate against this attack. If one is using firefox they should upgrade to the latest firefox. Of course on most old machines people are running palemoon. I haven't read anything about how well palemoon mitigates against these attacks. Fortunately I can run noscript on palemoon.

Hello s243a.

It is good to know that JS can be used as a vector to exploit these vulnerabilities -- and
the antidote you mention. Thanks for this info. But what if the "delinquent" uses another
computer language? Such as in this Turkish case:
http://murga-linux.com/puppy/viewtopic. ... ost#981456

BFN.

[8Geee]

I can't speak to the whole problem, but the browser IS part of the problem. In firefox or clones like seamonkey and palemoon about:config is your friend. In terms of the recent problems of Meltdown and Spectre, these problems are based upon getting information before using it. To that end there are some general things the user can do to the browser.

1.) Turn off ALL autocomplete and ALL autofill
2.) ZERO ALL caches, and FALSE their use
3.) Turn off ALL pre-fetch
4.) Do not use (make false) indexed databases
5.) Do not use so-called workers or seers
6.) Do not use anything like a wallet if provided, and FALSE its use

Keep in mind that though these things above are aimed at FF/SM/PM, that the concept applies to ALL browsers if it's configuration can be changed/modified by the end-user.

Regards
8Geee

[musher0]

I can't speak to the whole problem, but the browser IS part of the problem. In firefox or clones like seamonkey and palemoon about:config is your friend. In terms of the recent problems of Meltdown and Spectre, these problems are based upon getting information before using it. To that end there are some general things the user can do to the browser.

1.) Turn off ALL autocomplete and ALL autofill
2.) ZERO ALL caches, and FALSE their use
3.) Turn off ALL pre-fetch
4.) Do not use (make false) indexed databases
5.) Do not use so-called workers or seers
6.) Do not use anything like a wallet if provided, and FALSE its use

Keep in mind that though these things above are aimed at FF/SM/PM, that the concept applies to ALL browsers if it's configuration can be changed/modified by the end-user.

Regards
8Geee

Hi 8Geee.

I don't believe this.

We might as well use IPoAC. Sometimes referred to as RFC1149.

Seriously: What happened to "running in sandbox" or "anti-virus scanning"? I motion
that we run the browser in a sandbox and use an anti-virus scanner on its data files.
Who seconds?

BFN.

[s243a]

How do we know that a give sandbox protects us though? Besides javascript is over used. I strongly recommend cutting back on the amout of scripting that we allow in our browsers, especially on older systems.

BTW, pidgens certainly wont help you keep your packets clean!!! But if we must use pidgens I recommend that we pack as much info as we can into the packes given the high packet loss rate and limitation on the number of packets at once. Also we must use UDP because TCP will time out before we connect.

[musher0]

How do we know that a give sandbox protects us though? Besides javascript is over used. I strongly recommend cutting back on the amout of scripting that we allow in our browsers, especially on older systems.

BTW, pidgens certainly wont help you keep your packets clean!!!

Good point, s243a!!!

On 2nd thought, could cUrl be put to good use here?
Roughly, this is the idea:

we use cUrl for retrieving the Internet material
we turn off the connection
we view the material offline.

Thinking out loud:
cUrl (on every Puppy), OR
httrack https://www.httrack.com/, OR even
an adaptation of psyphon
https://psiphon.en.softonic.com/?ex=DSK ... nic-review ?

I'm sure there is a better solution than turning your speedy browser into a turtle...

BFN.

[Sailor Enceladus]

Seriously: What happened to "running in sandbox" or "anti-virus scanning"? I motion
that we run the browser in a sandbox and use an anti-virus scanner on its data files.
Who seconds?

I generally don't want exactly the things 8Geee mentioned too, and would rather they be off. On my puppy full install I left cache on in Palemoon because my wifi and laptop is pretty slow so maybe it will help speed a bit on sites I visit often though. I used to use run-as-spot but haven't for a while now, having to save in /root/spot then dragging things somewhere else wasn't too difficult but is an added step, never really found any use for antivirus in Puppy... even in Windows I might try an AV like once a year then remove it, but did find having a browser sandbox in Windows XP kinda interesting (maybe not useful... but interesting, and didn't make performance worse).

[s243a]

I'm sure there is a better solution than turning your speedy browser into a turtle...

BFN.

I haven't actually tried turning off the cache but blocking javascript may make up for some of the speed loss. How about a compromize. One could have two browsers. The first allows cach but will only allow javascript on trusted sites. The second doesn't allow cache but can allows javascript on more sites and runs in a sandbox.

[Marv]

I wonder how many who have older machines (Puppy often being used on such machines) really want to upgrade their OS or kernels (or even webbrowsers) to mitigate against Meltdown and or Spectre? I don't see much discussion about this - perhaps we feel obliged because it has always been advocated that users have a responsibility to patch their systems.

So suddenly some older unpatched machines perform as well or maybe better than some newer patched ones?

Systems that are so old they are only just proving usefully usable pre-patching suddenly become a bit more obsolete - or do some just avoid the patches to keep performance up? Is it fear that makes us universally patch, or do we just patch the machine(s) we use for online banking etc...?

wiak

I've retired my fleet of Pentium M laptops so I don't have any machines I would call older/challenged at this point. I do have three core 2 duo laptops in addition to my i5 based machines and am using one of the core 2 duos as an 'offline' tax and accounting machine so I did a quick performance test on a non-patched kernel versus a meltdown & spectre 2 patched kernel (full retpoline enabled). I used the same pup (Lx-ArtfulPup), governor etc. and as nearly comparable kernels as I could get. I did 3 runs on each of the benchmarks. On the i5 laptop running LxPupSc I had seen the following hits going to the retpoline kernel from a kpti only patched kernel:
glxgears FPS: -7%
CPU Cryptohash: -19%
FPU Raytracing: -18%

To my surprise, on the core 2 duo laptop glxgears FPS was actually 5% better on the 4.15.0 retpoline kernel and CPU Cryptohash and FPU RayTracing were both 1% slower. Seems that the bottlenecks are elsewhere on the core 2 duo.

So, again to my surprise, I haven't much reason not to patch the middle aged core 2 duos and from this quick look It seems that different hardware reacts quite differently to the retpoline patch. As for intels flawed ucode attempts, to the dustbin!

[s243a]

Seriously: What happened to "running in sandbox" or "anti-virus scanning"? I motion
that we run the browser in a sandbox and use an anti-virus scanner on its data files.
Who seconds?

I generally don't want exactly the things 8Geee mentioned too, and would rather they be off. On my puppy full install I left cache on in Palemoon because my wifi and laptop is pretty slow so maybe it will help speed a bit on sites I visit often though.

Here is some info about how browsers mitigated the spectra attack by reducing the precision of their timers:

"Both Spectre and Meltdown use cache in a timing based attack. Since cached memory is much faster to access, an attacker can measure access time to determine if memory is coming from RAM or the cache. That timing information can then be used to actually read out the data in the memory. This why a Javascript patch was pushed to browsers two weeks ago. That patch makes the built-in Javascript timing features a tiny bit less accurate, just enough to make them worthless in measuring memory access time which safeguards against browser-based exploits for these vulnerabilities."

https://hackaday.com/2018/01/15/spectre ... che-works/

I will give no opinion if this is sufficient protection enough or not to protect against java-script type spectra attacks.

[tommy]

Maybe I miss the point, so correct me if I'm wrong...


I read here that :

But, since it's merely a memory read issue, attackers don't get a straight shot at privilege escalation with this, and there's going to be some luck involved to have useful-to-attackers data in active memory when these techniques are used.

I can think of these three situations:

Safe scenario 1:

I cold boot my PC, with NO savefile (puppy boot option pfix=ram), I just do my web banking payments, I buy on online sites paying with credit card etc, then I reboot my PC (or I shutdown and cold boot it).
After rebooting with NO savefile, I surf the web and I go to a malicious site, I run a malicious javascript and I have no Spectre/Meltdown patches. Now the evil attacker can read my RAM. So what??? What can he read? I rebooted my Puppy and I know that RAM is volatile, so no previous data (passwords, credit card number etc) is in RAM, because on reboots RAM is flushed and is therefore empty (well, not really empty, but filled with puppy initrd , .zdrv and .sfs files).
On this case I wouldn't slow down my old system with patches.

Safe scenario 2:

I boot my pc to do offline tasks such as:
watch a movie/ listen music/ play games / work with office;
or to do online tasks such as:
dowload files with Transmission/aMule / connect to a rdesktop - vnc - ssh - ftp - VPN server etc. (i.e: I don't open a browser at all). In this case I wouldn't boot a patched OS and I'd run at full speed.

Risky scenario:
I boot puppy WITH a savefile, I do online banking, I use my credit card on online shops etc., then I clear personal data (on firefox: ctrl-shift-del) and I reboot. Puppy will save this session in the savefile. At reboot with savefile, I surf the web, I run a malicious javascript, and have no Spectre/Meltdown patches.
If I remember correctly, at bootup puppy stores in RAM the personal savefile as a layered filesystem (something similar to ramdisk), where it records the changes, the new files, the deleted ones etc, and at shutdown it saves those new/modified files in the 'pupsave.2fs' savefile. Puppy doesn't save the data in the volatile RAM anywhere, as long as it is not a file (maybe a swap partition is a risk and should be zeroed out on shutdown?).
For example, firefox can eat 500MB to 1GB of RAM when open, but after closing it that amount of RAM isn't saved in savefiles at shutdown (puppy just saves Firefox personal profile folder, it actually weighs 23 MB on my system.). If I don't have my passwords stored in browsers, nor sensitive /credit card data on browser auto-fill fields, what can the evil attacker read on cold reboots and the puppy savefile loaded?
Maybe on this scenario I can consider running a patched OS and suffer speed loss, just to be 100% sure.

Am I underestimating the Spectre/Meltdown security issues?

[8Geee]

Qualys, the people that bring us a server and client test for things like SSL/TLS, and vunerabilities against Poodle, Logjam, Freak, etc has published this article to explain what is behind Meltdown/Spectre. The article does call for the rebuild of chips, and is therefore rather extreme. Nonetheless, it states that basically any app can access the Out-of-order-execution (OOOE) cache inherent in a great majority of CPU's. Thus the patchwork is complex, due to numerous apps, and all-consuming.

MHO... in regards to JS concerns, even base-coding as in C, C+, C#, Py, etc needs to be at least patched in any app, as such code may indeed call for the OOOE cache. While thats a back-burner issue, I am aware that kernel-level patching is underway for Linux kernels. The caveat is that only the supported kernels are being patched. Therefore 3.2.x, 3.16.x, 3.18.x, 4.1.x, 4.4.x, 4.9.x, 4.14.x, and 4.15.x kernels are being updated. /MHO

regards
8Geee

[musher0]

Good info.

Thanks, 8Geee.

[Flash]

For what it's worth, security expert Bruce Schneier wrote this in the last Crypto-Gram:
The Effects of the Spectre and Meltdown Vulnerabilities

...these vulnerabilities will affect computers' functionality. In some cases, the patches for Spectre and Meltdown result in significant reductions in speed. The press initially reported 30%, but that only seems true for certain servers running in the cloud. For your personal computer or phone, the performance hit from the patch is minimal. But as more vulnerabilities are discovered in hardware, patches will affect performance in noticeable ways.

And then there are the unpatchable vulnerabilities. For decades, the computer industry has kept things secure by finding vulnerabilities in fielded products and quickly patching them. Now there are cases where that doesn't work. Sometimes it's because computers are in cheap products that don't have a patch mechanism, like many of the DVRs and webcams that are vulnerable to the Mirai (and other) botnets -- groups of Internet-connected devices sabotaged for coordinated digital attacks. Sometimes it's because a computer chip's functionality is so core to a computer's design that patching it effectively means turning the computer off. This, too, is becoming more common....