Should the "Reboot! Shut up and reboot!" theory be applied to programs?

Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.

Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.

Already using Google+? Find us on Google+ for the latest security news.

Tech-savvy website Ars Technica recently invited comments on an interesting thought about programming.

"Should programs randomly fall on their swords?"

Actually, they didn't quite put it like that - indeed, they didn't make it clear whether programs ought to exit gracefully but needlessly after a random time, or whether they ought to be asynchronously killed off on a random basis by some monitor process.

?Such a monitor would be the opposite of a traditional watchdog, a process that keeps its eye on other programs and warns you when they break. This would be a process that breaks other programs, then tells you it's done so.

But they did wonder about making programs exit even if they didn't need or want to, for the greater good of the operating system as a whole.

My first reaction was, "Why not?"

There's a school of thought that says a degree of unpredictability in software, especially long-running network software, can be very handy indeed.

Don't wait, say, two seconds after a failed connection attempt so that you coincide precisely but permanently with a similar every-two-second problem in some other process. Wait two seconds plus a random interval that's different every time.

Don't arrange everything so predictably in memory that if there's an exploitable bug, hackers can reliably work out where to poke their knitting needles. Mix things up a bit so an attacker has to guess, and might very well get it wrong.

And, of course, in anything cryptographic, good quality randomness is vital, lest you turn a problem that should be computationally infeasible into one that is merely difficult or time-consuming.

?Debian once removed code from its kernel because it looked unpredictable. It was supposed to be - it was part of the random number generator. After getting "fixed' it became so predictable that cryptographic keys that should have been unguessable could be brute-forced in seconds or minutes.

Forcing programs to have a short outage every now and then is a bit like companies that require senior executives to use at least some of their annual vacation time each year in unbroken chunks.

Not only does it force the individual to take a much-needed rest, it also mitigates against corruption in the company by getting an alternative hand on the tiller every now and then.

By my second opinion was, "No way!"

Naturally, you should subject your code to randomly-generated failures as a regular and important part of testing. (You do test your software against the sort of error you might never have experienced in real life, such as "disk full," don't you?)

This is especially true for online software, which is frequently developed on a fast, reliable, state-of-the-art local area network, but deployed over slow, laggy, flaky links.

But deliberately breaking code just to make it restart, hopefully with any ills of the past behind it, could ironically make things worse.

That's a little bit like pulling your car to the side of the road every few minutes to make sure the tyres don't overheat: a useful precaution in an emergency where you know there's a tyre fault, but a pointless waste of time if there isn't.

In fact, you can argue that getting into the habit of random "corrective process termination" could actually mask the symptoms of a fault, or lead to known problems being mitigated by accident, and thus never getting proper corrective attention.

?Tech support staff don't usually say "shut up and reboot" (with apologies to Dogbert) because it's scientific. They say it because it isn't scientific, but it very often works, and improves their call closure rates in the long run.

So randomly self-breaking programs sound a little bit like those rules that say things like, 'You must change your password every 45 days."

When an online service tells you that, are they implying that they actually get breached fairly frequently? That if they do get breached they probably won't realise?

Actually, you should change your password if you think you need to.

And if you think you need to, you should change it then and there, rather than saying to yourself, "My next 45-day mandatory password update is coming in a while, so I'll wait until then."

Follow @duckblog

View the original article here

Duqu malware spurs new Stuxnet-style conspiracy theory

Over 100,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.

Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.

Filed Under: Featured, Malware

The news wires have been abuzz for the past few days with stories of "a new Stuxnet". This son-of-Stuxnet malware goes by the orthographically curious name of Duqu.

(According to Symantec, Duqu got its name "because it creates files with the file name prefix ~DQ". On those grounds, Duqu is a silly name. It should have been called Twiddle-DQ, which is easier both to pronounce and to understand. As names go, it's also a lot less dull, which has to be worth something.)

Because Stuxnet targeted industrial control systems, and because it was widely reported in Iran (and also, as it happened, in India and Indonesia), conspiracy theories abounded.

At first, the world's media seemed sure that Stuxnet was intended to take out Iran's nuclear reactor facility at Busheshr. Later, the theory changed to say that the target was not the reactor facility but Iran's enrichment plant at Natanz.

The media simply followed the new theory, unashamedly declaring Natanz to be the target with the same apparent certainty with which they'd recently been insisting that Stuxnet was specifically aimed at Busheshr.

Along with speculation about what Stuxnet was designed to do, of course, came guesswork about who was responsible. Did the US write the malware? Was it Israel? Was Iran the intended target?

We might never find out what really happened in the Stuxnet case. But what about Duqu, the son of Stuxnet?

One writer already seems to know with certainty, and despite the absurdity of his claims, his story - first published on a website about industrial safety and security - is getting picked up around the world:

[Website name redacted] has learned leaders of the three major software companies, Sergey Brin at Google, Steve Ballmer at Microsoft and Larry Ellison at Oracle have been working with Israel's top cyber warriors and have now come up with new version of a Stuxnet-like worm that can bring down Iran's entire software networks if the Iranian regime gets too close to a breakout."

But Duqu has as many differences from Stuxnet as it has similarities to it. Most notably, Duqu doesn't target industrial control systems at all, and it seems to have been distributed via targeted malware attacks in Europe, not Iran.

As cyberconspiracy goes, then, this story is pretty far-gone.

Nevertheless, the idea of a US malware-hacking triumvirate made up of Messrs Page, Ballmer and Ellison made me laugh. And I found myself wondering what Apple's Tim Cook makes of the story.

Do you think he's relieved to have been omitted from this cyberconspiracy equation, or miffed to have been relegated outside the Big Three?

Follow @duckblog

Tags: ballmer, Duqu, ellison, Google, Iran, israel, Malware, Microsoft, Oracle, sergey, Stuxnet

View the original article here