That ransomware attack

[Polar Bear]

Fundamentally competition drives cost down and increases innovation.  Imagine if we could only buy a Giant or a Raleigh.

I don't think that we would be so platform limited if there were more competitors, and, it would be a much bigger job for the malicious hackers to perpetrate attacks of the sort that they have managed.   As it stands organisations have to make a choice on one platform and invest spectacularly in that choice.  Also, a whole industry sector of platform integration would grow from wider choice imo.   A bit like getting your shimano bits to work with campag bits and vice versa.   

I am convinced that on the whole monopolies are not in the best interests of the majority.

[TheLurker]

Fundamentally competition drives cost down and increases innovation.  Imagine if we could only buy a Giant or a Raleigh.

Bike bits are by and large interchangeable so finding yourself tied to one particular manufacturer is less likely although even with bikes you can find incompatible systems which get you locked in to one mfr (Campagnolo or Shimano?).  Software is, unfortunately, not so flexible for all sorts of reasons.

I am convinced that on the whole monopolies are not in the best interests of the majority.

I quite agree and at thankfully the moment we don't have a pure monopoly for OSs.  We have 3 dominant companies (Apple, M$ and Google) so people do have some choice and there is a degree of competition which benefits consumers.  The market is never truly fair but the current state of play is bearable and it gives commercial SW companies the reassurance they need that their target platform has a large enough market share to repay the amount of time and money it takes to get a good product to market and that there'll still be a market there in 3 or 4 years or however long it takes the development to go from drawing board to shrink-wrap or, these days, web download.

And for the independently minded there are a raft of Linux distros out there.

[Afasoas]

There are a number of ways of using hardware and software abstractions to write software which shouldn't care what OS it's running on.
I appreciate it's probably not that straight forward, but I think:

When spending a large sum on a piece of hardware which depends on software to be useful, software should be maintained for the expected lifetime of the hardware and that maintenance should ensure it runs on current operating systems. This is the responsibility of both the hardware supplier and purchaser.

[David Martin]

That would make longer term maintenance contracts as part of the purchase exceedingly expensive, and still doesn't negate the 'we are bust, tough' possibility. The issue is market size. Designing boxes to be as portable as possible is also a good plan.

[rr]

It is an issue where the lifespan of the machines is much longer than the lifespan of the controlling tech, and there are no mechanisms in place to deal with that kind of obsolescence. I would expect that some hospital labs have key equipment connected via SCSI and upgradeable only by floppy disk.

It you look at CNC machine tools, there are perfectly useable tools out there that need an rs232 interface, Windows 3.1 and 5inch floppies. There are people out there who will pay good money for such machines.

Sent from my XT1562 using Tapatalk

[mrcharly-YHT]

There are a number of ways of using hardware and software abstractions to write software which shouldn't care what OS it's running on.
I appreciate it's probably not that straight forward, but I think:

When spending a large sum on a piece of hardware which depends on software to be useful, software should be maintained for the expected lifetime of the hardware and that maintenance should ensure it runs on current operating systems. This is the responsibility of both the hardware supplier and purchaser.

That's really, really difficult to do when the software has to interact with peripheral hardware.

[TheLurker]

There are a number of ways of using hardware and software abstractions to write software which shouldn't care what OS it's running on.

Ah yes. Write once run anywhere.  The industry has been pursuing that particular grail for a long, long time.  I don't expect it to see found it in my lifetime. 

All you've done is shift the problem to another layer.  If your abstraction layer is found to be buggy and the people who wrote the code for the abstraction layer (and what's an O.S. but an abstraction layer?) on your particular bit of kit have decided that it is no longer supported and they won't be patching it?  Sound familiar?

...maintenance should ensure it runs on current operating systems.

Yeah, it'd be nice but it's never going to work.  Simple, nay simplistic, example.  Pretend I have an IBM PC built around an 80286 with 16MB of RAM and 200MB HDD running Win 3.1x. A fairly common configuration 20 or so years ago.  It might have coped with Windows 95, I doubt it would have coped with XP and there is no way on God's green earth that machine could be made to run Windows 7 64 bit Pro or any variant of Windows 10.  The hardware just isn't up to it.  You have a similar problem with expensive lab kit.  Such kit can have a service life of 10 years and upwards and in that time the hardware requirements for software can change so much that there is no earthly chance that "maintenance" would be feasible short of rebuilding the machine. And at that point it's probably cheaper to get a new machine.

Put it another way.  If what you suggest was technically possible and economically practical it would already be happening.

[Afasoas]

That would make longer term maintenance contracts as part of the purchase exceedingly expensive, and still doesn't negate the 'we are bust, tough' possibility. The issue is market size. Designing boxes to be as portable as possible is also a good plan.

The code base should be maintained in ESCROW so that in the event the manufacturer goes bust, major clients can obtain a copy of it ...

[Afasoas]

There are a number of ways of using hardware and software abstractions to write software which shouldn't care what OS it's running on.

Ah yes. Write once run anywhere.  The industry has been pursuing that particular grail for a long, long time.  I don't expect it to see found it in my lifetime. 

All you've done is shift the problem to another layer.  If your abstraction layer is found to be buggy and the people who wrote the code for the abstraction layer (and what's an O.S. but an abstraction layer?) on your particular bit of kit have decided that it is no longer supported and they won't be patching it?  Sound familiar?

...maintenance should ensure it runs on current operating systems.

Yeah, it'd be nice but it's never going to work.  Simple, nay simplistic, example.  Pretend I have an IBM PC built around an 80286 with 16MB of RAM and 200MB HDD running Win 3.1x. A fairly common configuration 20 or so years ago.  It might have coped with Windows 95, I doubt it would have coped with XP and there is no way on God's green earth that machine could be made to run Windows 7 64 bit Pro or any variant of Windows 10.  The hardware just isn't up to it.  You have a similar problem with expensive lab kit.  Such kit can have a service life of 10 years and upwards and in that time the hardware requirements for software can change so much that there is no earthly chance that "maintenance" would be feasible short of rebuilding the machine. And at that point it's probably cheaper to get a new machine.

Put it another way.  If what you suggest was technically possible and economically practical it would already be happening.

There are countless examples in the industry where this already *is* the case. Will the tooling available today it should be possible to compile and regression test code targeted at multiple platforms as part of an automated pipeline. Yes it takes some investment up front, but it's what software vendors should be doing.

Another way to solve the problem is to network enable these devices so they are running their own kernel/OS and software on client workstations uses web protocols to interact with them. Of course that doesn't eliminate all the complexity, but it would make the system more maintainable.

Win 3.1x was barely usable on a 286.

[TheLurker]

That would make longer term maintenance contracts as part of the purchase exceedingly expensive, and still doesn't negate the 'we are bust, tough' possibility. The issue is market size. Designing boxes to be as portable as possible is also a good plan.

The code base should be maintained in ESCROW so that in the event the manufacturer goes bust, major clients can obtain a copy of it ...

And they then have to spend lots of money finding the expertise to understand, debug and re-implement out of date code written for a niche embedded systems compiler (yes I am painting a worst case scenario) in an obscure assembler dialect for a processor/chipset that is no longer manufactured?  Were I a bean-counter my reaction would be, "Here, take the lab cheque book and go buy a new one."*

*The idea of a bean-counter handing over a cheque book to anyone may contain elements of fantasy.

[TheLurker]

... it should be possible to compile and regression test code targeted at multiple platforms as part of an automated pipeline. Yes it takes some investment up front,  but it's what software vendors should be doing.

Put it another way.  If what you suggest was technically possible and economically practical it would already be happening.

See highlighted text.

All you've done is shift the problem to another layer.  If your abstraction layer is found to be buggy and the people who wrote the code for the abstraction layer (and what's an O.S. but an abstraction layer?) on your particular bit of kit have decided that it is no longer supported and they won't be patching it?  Sound familiar?

All the automated toolsets in the world will not address this problem.

Another way to solve the problem is to network enable these devices so they are running their own kernel/OS and software on client workstations uses web protocols to interact with them

You may have found the only real justification for the internet of things.  It'd be the security headache from hell, but still...
And if the kernel/OS chosen was XP?  *evil grin*

Win 3.1x was barely usable on a 286.

I dunno, mine used to get by OK running Turbo C++ for Windows or was it a 386?  Can't remember now. 

[Feanor]

Another way to solve the problem is to network enable these devices so they are running their own kernel/OS and software on client workstations uses web protocols to interact with them. Of course that doesn't eliminate all the complexity, but it would make the system more maintainable.

But that's already what they do.

But they will network-enable them using a commercial embedded system, that will be based on a commercial OS of-the-day, like XP!

There's no good reason to re-invent your own OS when that's not your actual business.
That's likely to be far worse security-wise that a commercial embedded package, and more expensive and time consuming to develop.

And so we are back to embedded systems using out-of-date OSes.

[Afasoas]

... it should be possible to compile and regression test code targeted at multiple platforms as part of an automated pipeline. Yes it takes some investment up front,  but it's what software vendors should be doing.

Put it another way.  If what you suggest was technically possible and economically practical it would already be happening.

See highlighted text.

The upfront investment is more than recouped by shorter feedback cycles and does not necessarily add up to being economically impractical.

All you've done is shift the problem to another layer.  If your abstraction layer is found to be buggy and the people who wrote the code for the abstraction layer (and what's an O.S. but an abstraction layer?) on your particular bit of kit have decided that it is no longer supported and they won't be patching it?  Sound familiar?

All the automated toolsets in the world will not address this problem.

Java has been solving this problem for 23 years, and is not likely to go away any time soon. I'll grant you that it's not perfect but I interact with it on a regular basis supporting software that in two instances does very low level interaction with the hardware.

Another way to solve the problem is to network enable these devices so they are running their own kernel/OS and software on client workstations uses web protocols to interact with them

You may have found the only real justification for the internet of things.  It'd be the security headache from hell, but still...
And if the kernel/OS chosen was XP?  *evil grin*

Win 3.1x was barely usable on a 286.

I dunno, mine used to get by OK running Turbo C++ for Windows or was it a 386?  Can't remember now. 

I'd wager it was a 386, which although first produced in 1985, remained in production for embedded systems until 2007. And although it was 32-bit, was still able to run 16-bit code from the 8086-80286 era.
It's still allegedly possible to run 16-bit code written for the 8086 on Intel's Kaby Lake platform.
And as for supporting legacy, Microsoft does that pretty well. Hence SMBv1 is still with us.

[pcolbeck]

But that's already what they do.

But they will network-enable them using a commercial embedded system, that will be based on a commercial OS of-the-day, like XP!

There's no good reason to re-invent your own OS when that's not your actual business.
That's likely to be far worse security-wise that a commercial embedded package, and more expensive and time consuming to develop.

And so we are back to embedded systems using out-of-date OSes.

Nearly all embedded OSs with a webby from end are Linux based these days. Why would a manufacturer pay a licence fee to MS for an embedded OS? Even Cisco data centre switches run Linux as their management/control plane and all their appliances do these days, the same for nearly everyone else.

[Afasoas]

Another way to solve the problem is to network enable these devices so they are running their own kernel/OS and software on client workstations uses web protocols to interact with them. Of course that doesn't eliminate all the complexity, but it would make the system more maintainable.

But that's already what they do.

But they will network-enable them using a commercial embedded system, that will be based on a commercial OS of-the-day, like XP!

There's no good reason to re-invent your own OS when that's not your actual business.
That's likely to be far worse security-wise that a commercial embedded package, and more expensive and time consuming to develop.

And so we are back to embedded systems using out-of-date OSes.

Which would probably be okay (not ideal) if the only services exposed to the network was the API for running the hardware. Possibly better if the embedded OS was a Linux kernel with the bare minimum of software/utilities.
I realise there's no panacea but I suspect in many instances that large monolithic applications, hard-wired to the OS couple and to traditional waterfall development serve to hamper the situation.

[TheLurker]

All you've done is shift the problem to another layer.  If your abstraction layer is found to be buggy and the people who wrote the code for the abstraction layer (and what's an O.S. but an abstraction layer?) on your particular bit of kit have decided that it is no longer supported and they won't be patching it?  Sound familiar?

All the automated toolsets in the world will not address this problem.

Java has been solving this problem for 23 years, and is not likely to go away any time soon. I'll grant you that it's not perfect but I interact with it on a regular basis supporting software that in two instances does very low level interaction with the hardware.

I think you missed the point about the abstraction layer not being patched and no longer being maintained. Which is where we came in with XP. If any layer in the software stack has a show stopper bug and that layer is not under your control and that layer is no longer being supported and patched then you're stuffed. 

Last time I looked (some while ago I grant you) Java required JVMs written for the target platform. 

Given that I'm out of touch with Java and assuming JVMs are still required how, using your proposal, do you get around the problem of a no longer maintained and unpatched custom JVM for a specialist bit of kit that you don't have the rights to modify/fix?

You're right about better automation and up front investment recouping initial investment costs and generally being a good thing, but I've been having that argument for 30 years with various levels of project manager and bean-counter and short-termism has won every single time.  The bean-counters simply do not recognise or accept that argument.  As far as they are concerned such things are economically impractical and unfortunately they have more clout than us.  The summary is, "Has the customer asked for this? Has the customer paid for this? No? Well then, take a hike programmer."  So the de-facto state of things is, "economically impractical" and us saying "should" until we're blue in the face isn't going to change a thing.

[TimO]

We seem to have drifted a bit from the original Ransomware discussion, but ultimately all software is going to ultimately become impractically unmaintainable, at a realistic cost.  If nothing else, the hardware it runs on, will also probably suffer from that too.

I maintain systems that run DOS 3, and I'd never expect to have to place any of that in a position where it was exposed to any sort of hacking vector.

At some point, software is no longer maintained, and Microsoft was not subtle about no longer supporting XP, they gave plenty of warning.

If you want to run software, beyond it's lifetime, you have to choose to pay for it, or replace it.  I don't expect an old car to be easy and cheap to support.  If I wanted to run a Model T Ford, or VW split-screen Camper, I have to be prepared to deal with the complexities and costs.  Much the same is true of PC hardware and software, except that the relatively immature technology means that the rate of change is much faster, so we find that we need to move on, more often.

Eventually we'll probably get to a position where the engineering makes it easier to not move on as often, easier to produce layers of abstraction, hardware emulation of other hardware, and more generic methods of blocking vulnerabilities.  At the moment we don't have a lot of that,so we have to simply move onto the next step, which can often seem like a big and unnecessary change.

[Afasoas]

All you've done is shift the problem to another layer.  If your abstraction layer is found to be buggy and the people who wrote the code for the abstraction layer (and what's an O.S. but an abstraction layer?) on your particular bit of kit have decided that it is no longer supported and they won't be patching it?  Sound familiar?

All the automated toolsets in the world will not address this problem.

Java has been solving this problem for 23 years, and is not likely to go away any time soon. I'll grant you that it's not perfect but I interact with it on a regular basis supporting software that in two instances does very low level interaction with the hardware.

I think you missed the point about the abstraction layer not being patched and no longer being maintained. Which is where we came in with XP. If any layer in the software stack has a show stopper bug and that layer is not under your control and that layer is no longer being supported and patched then you're stuffed. 

But that's kind of the point. This is how we are able to access the out-of-band management on some really old hardware - it still works with current versions of JVM even though the hardware was new well over 10 years ago.
Yes we will one day we will be stuffed (we've decommissioned almost all of this old hardware now) as we keep pace with the times.

Last time I looked (some while ago I grant you) Java required JVMs written for the target platform. 

Given that I'm out of touch with Java and assuming JVMs are still required how, using your proposal, do you get around the problem of a no longer maintained and unpatched custom JVM for a specialist bit of kit that you don't have the rights to modify/fix?

You're right about better automation and up front investment recouping initial investment costs and generally being a good thing, but I've been having that argument for 30 years with various levels of project manager and bean-counter and short-termism has won every single time.  The bean-counters simply do not recognise or accept that argument.  As far as they are concerned such things are economically impractical and unfortunately they have more clout than us.  The summary is, "Has the customer asked for this? Has the customer paid for this? No? Well then, take a hike programmer."  So the de-facto state of things is, "economically impractical" and us saying "should" until we're blue in the face isn't going to change a thing.

Times and attitudes are changing. I've not lived under a rock for the last 18 years of my IT career and I know exactly what you are talking about it - I've spent half my life working with legacy hardware and legacy systems. We work with some of the biggest lenders (banks) who are the slowest to move and the reason they want to work with us is because of our approach to software development - we can do things reliably within time/cost/budget that their internal IT departments can't and they want to understand why.

[Feanor]

But that's already what they do.

But they will network-enable them using a commercial embedded system, that will be based on a commercial OS of-the-day, like XP!

There's no good reason to re-invent your own OS when that's not your actual business.
That's likely to be far worse security-wise that a commercial embedded package, and more expensive and time consuming to develop.

And so we are back to embedded systems using out-of-date OSes.

Nearly all embedded OSs with a webby from end are Linux based these days. Why would a manufacturer pay a licence fee to MS for an embedded OS? Even Cisco data centre switches run Linux as their management/control plane and all their appliances do these days, the same for nearly everyone else.

Every embedded device I've seen in a crashed state has been Windows!
( Perhaps that's a self-selecting sample! )

Off the top of my head, I've seen Windows BSODs or Windows desktops with error dialogs on:
ATM machines, Self-service checkout machines, Airport arrivals/departures display screens, huge billboard display screens.
So Windows Embedded is certainly well represented in the wild.

[Kim]

I've certainly come across a few of that sort of thing (mostly advertising / video playing devices) with Linux error messages.  Usually pertaining to a storage device or network problem, rather than a kernel panic.  That may simply represent Linux OSes' higher level of robustness in the face of certain hardware problems.  If a system disk vanishes Linux tends to politely complain while everything wanting disk IO grinds to a halt^[1], while Windows is more inclined to simply BSOD.

Windows suffers from more comedy unrelated popups, which is what you get for using a desktop operating system for an embedded media display.  It's much more straightforward to give your media application exclusive use of the display in Linux.


_{[1] DAHIKT}

[Jaded]

Hmmm, not sure if this has been posted before but it looks like XP wasn't the big villain here, it was Win 7

https://www.theverge.com/2017/5/19/15665488/wannacry-windows-7-version-xp-patched-victim-statistics

[Greenbank]

The W7 patch was released in March. It just goes to show how many people don't bother updating their Windows systems or, if they haven't disabled auto updating, how many don't bother rebooting them for the updates to complete and take effect.

[T42]

Yes.  I run W7 with auto updates but Mrs T had the "not genuine windows" bug and her W7 wasn't updating.  Of course, being the goto geek in the family I should have been onto that, but I did my stint in systems support in the 80s, and mucking about in the grubby guts of Windows has always been something I equated with cleaning dog vomit out of the car, so I didn't.

Anyway, Wannacry does not seem to have struck us, but summat phunny has happened since it appeared. We both run the best email client on the planet, Eudora 7, quite simply because it doesn't do stuff like ActiveX components and other quasi-intelligent shit: it's so dumb it doesn't even do UTF8->ISO unless you select the text and dispatch it via a menu.  Anyway, for the last couple of weeks, almost every time it checks mail it's been throwing up an SSL negotiation failure: destination host name does not match that in certificate.  Nonetheless waiting mail gets downloaded and anything queued gets sent.

Using the same settings as for Eudora, Thunderbird under Ubuntu works quickly and cleanly.  I'm moving Mrs. T permanently to Ubuntu now, but for various reasons I need to stay with W7.  Don't like it much, though.

[T42]

^^^Sussed, fixed. Orange added a new certificate. Thunderbox picked it up automatically, Eudora ran into the idiot wall.

Or maybe Thunderbox doesn't bother with certificates...

Back to Wannacry, if anyone still does.

[Greenbank]

And here comes the next ransomwhere attack based on the same vulnerability for all those people that didn't apply the appropriate fixes.

No simple kill switch this time either.

http://www.bbc.co.uk/news/technology-40416611