A third?!
Fucking hell.
Patches for the Meltdown vulnerability are causing stability issues in industrial control systems. SCADA vendor Wonderware admitted that Redmond's Meltdown patch made its Historian product wobble. "Microsoft update KB4056896 (or parallel patches for other Operating System) causes instability for Wonderware Historian and the …
I believe StuxNet proved that approach insufficient.
In any case, the number of wobbles shows just how shoddy a lot of the software in this area is. It was either going around OS protection mechanics or had some ultra-optimistic (not to say delusional) ideas on how long would a particular syscall take.
I'll upvote your post because you are correct however I stand by my assumption that you should not connect things to the internet because you can. Using the internet as a mode of transferring information should only be used securely and as most systems lack security it should not be done.
"Using the internet as a mode of transferring information should only be used securely and as most systems lack security it should not be done".
Er, isn't this where we came in?
Using speculative execution as a way of increasing performance should only be used securely and as it apparently cannot be done securely it should not be done.
Didn't stop Intel though, did it?
"I believe StuxNet proved that approach insufficient."
You may believe whatever you like (nice to have faith in something!). However, I know that Stuxnet couldn't have affected the industrial controls that I have put into place over the last thirty years.
SCADA should always be properly airgapped. This includes sneakernet.
The problem often is there isn't a parallel test system on which you can deploy patches.
If your kit costs tens of thousands (if not much much more) and is in use 24/7 asking "can you buy us a complete parallel system to test" is something you are going to have trouble getting past finance.
I'd say that it arguably depends on the sensitivity of the SCADA system - how safety critical it is etc.
...but when I was working with those kinds of systems (pre-2000), industry's approach to security wa less than ideal. I do wonder how much security awareness has improved since then.
A browser/Node.js with a Javascript interpreter instead of a JIT compiler would be hell a lot of more secure nowadays. And get rid of WebASM/ASM.js, it's immature and no one uses it anyway - running unsigned untrustworthy bytecode in the CPU seems a big security risk on Intel CPUs.
That's what I learned from the article and the linked articles.
Still, the (D)COM security model is far ahead any HTTP/XML/JSON/REST/Javascript primitive one - which is far less secure . IT went backward since it became marketing-designed because a browser could reach lots of people to sell them stiff and also steal their data.
In (D)COM you can have ACL at the function level, and authentication/encryption/signing at the packet level. Sure, it is too complex for the average web developer....
Well, if you look at how Spectre works, then you'll see that they are talking about using tailored compilers to compile the run-time environment (js engine, OS, sandbox, whatever is to be protected). See the latest Google paper on "retpoline".
So it's not about outlawing compilers, malware authors are still free to use whatever they want.
If you use RSView, FactoryTalk, RSLinx (Which is not only design time!) or Studio5k you are in for hurt from what I'm seeing.
I can't see Rockwell re-writing the 20+ versions of Studio5000 and its earlier incarnations. Which for the uninitiated is way worse than it sounds.
Each major release of the software conicides with a hardware version, so if you have a CLX5555 processor for example its compatible with version 11 to 14 firmware, which in turn means version 11 to 14 of the programming software, if you have a v15 hardware you need a totally new version of the programming software!
Which means there are dozens of versions of this crapware out there that are 10s of years old and one can bet that despite the horrifying cost of buying a license for 10 year old software they won't be updating to fix this issue
Don't know about the Rockwell software, but for the SCADA package I'm using (Zenon) the fixes are only causing problems with comms drivers. So it's possible RSLogix (all however many versions there are now!) is fine; the article suggests it's RSLinx (comms) that has problems - so fix that and Logix may be OK... wild speculation but hey.
very last post here https://forums.theregister.co.uk/forum/3/2018/01/09/meltdown_spectre_slowdown/
I was hoping someone else would raise the issue but it is good that the reg brought it to the fore with a seperate article
well done and keep up the good work
"Rockwell Automation revealed that the same patch had caused issues with Studio 5000, FactoryTalk View SE, and RSLinx Classic (a widely used product in the manufacturing sector)."
But does it affect the retro encabulator?