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 …
Just because something can be connected to the internet doesn't mean you should. Problem solved.
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.
"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.
How very true, we follow the same policy with the industrial control systems we manage. but I can't help asking just who installs known problem patches in systems without very extensive testing on the test systems first.
"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?
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.
Full list of vendor responses here: https://ics-cert.us-cert.gov/alerts/ICS-ALERT-18-011-01A
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.
That's what I learned from the article and the linked articles.
The patch explicitly warned about some (D)COM issues related to authorization and impersonation. AFAIK older industrial systems do rely on DCOM and some kind of DCE/RPC. Maybe related?
DCOM is the evil network child of COM, itself evil offspring of OLE. It's always had security problems.
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....
The security of a model doesn't really impress me. What matters is the implementation.
Add TwinCAT 3.1 on 64Bit machines to that list.
The state of industrial controls software and hardware, and the vendors approach to built in security and ease of use is a fricking disgrace
If "Windows SCADA", or even just "SCADA" doesn't make you want to curl up in a ball, move to the woods and live in a yurt, then be thankful for your ignorance. It's one of the most frightful things about our industrial society.
I keep seeing variants of this, but I have to wonder how we get all the malware writers to use compilers that prevent code that exploits Meltdown (or Rowhammer, or various others over the years) from being developed. "When non-gimmicked compilers are outlawed..."
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.
Most of the Rockwell products impacted by these patches are used to develop and program, not run, control systems.
So the hardware isn't always affected, so much as the ability to design with it.
Time will tell if it impacts me at the day job.
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?
We actually need it to keep working!
Vendors are punting out fixes with minimal testing, this is unacceptable. I need to know it'll a) work and b) what impact it WILL have.
Biting the hand that feeds IT © 1998–2018