Stuxnet worm slithers into China, heralds alien invasion

ZX81

I recall Sir Clive Sinclair's comment that you could run a nuclear power station on a ZX81 (Timex for our colonial friends).

If only the industrial giants of the world had stuck with that instead of bloody Windows.

Boom & Bust

Pricking a balloon pops the bubble.

Best. FAQ. Ever

The F-Secure FAQ really is a good read. Some choice excerpts:

"Q: Which factory is it looking for?

A: We don't know.

Q: Has it found the factory it's looking for?

A: We don't know."

...

"Q: Has the stolen certificate been revoked?

A: Yes. Verisign revoked it on 16th of July. A modified variant signed with a certificate stolen from JMicron Technology Corporation was found on 17th of July."

...

But my favorites have to be:

"Q: How is that possible?

A: Good question."

...

"Q: Was Stuxnet written by a government?

A: That's what it would look like, yes.

Q: How could governments get something so complex right?

A: Trick question. Nice. Next question."

and, the clear winner:

"Q: Oh.

A: Yeah."

"A centrifuge in a uranium processing plant"

But what would happen? That centrifuge is just throwing UF6 around (UF6? UFOs? Hmmm.. a possible link here?). Could the system make it rev up? Slow down? More action could be had by connecting the Siemens Control Machine to a mixer filled with frogs.

"Centerum Censeo" that Iran is fully within the rights granted to it by the NPT to build and run an Uranium enrichment plant for civilian purposes. Said purposes being verified by the IAEA which continually fails to find any diversion of nuclear material for military purposes etc. etc. etc.

The one who decided to control

nuclear facility with any Windows based system, deserve to be shot.

Hmmm

It seems that the general consensus is "we dont know"

SO a hypothosise (sp)

Q: Will Stuxnet spread forever?

A: The current versions have a "kill date" of June 24, 2012. It will stop spreading on this date.

Now as the doomsday sayers nostradamus fans and the fact that the Mayan calender sops sometime in 2012 as well so maybe thats the date it yes stops Spreading right after sending all systems critical <<BOOM>>

A Z80 is good enough for a civilian jet engine FADEC

As I was interviewed by one of the companies that tests them.

Their hiring test seemed to spend a lot of time asking forth type questions as well.

Deep embedded people into real time control have different priorities. The want *stability* and *known* bugs (with workarounds)

BTW the update cycle on the engines for the Saturn rockets was roughly 50 updates a second. Engine control on a civilian engine is perfectly doable on a Z80. Its the throttle response on military engines that needs multiprocessors.

As for nuclear reactors their response time to load changes is measured in *days*. Anyone thinking that pulling a few control rods out is enough to goose the output is *very* mistaken.

*Most* of the f-secure FAQ is a good read

(c) 2010. Submitted 3:30 pm ish, Saturday.

*Most* of the f-secure FAQ is a good read.

Their ignorance of the field of process automation shows, however, when they fail to spot the real significance of myrtus.

Any insider with a clue would know that this almost certainly originated as a reference to "my RTUs", where an RTU is a "Remote Terminal Unit", which in this context is a remote device which the PLC program uses for IO which isn't directly attached to the PLC itself.

Now it may of course be that there is a play on words going on here, and that the significance is *both* the biblical one and the industrial automation one. But for a self-proclaimed expert (and a recently arrived one at that) on the subject to not spot the industrial automation connection just makes them look ever so slightly silly. In their defence, obviously f-secure are not the only ones that have failed to spot this, and the rest of their FAQ gets a good mark for effort.

Symantec's writeups on the subject are quite good too (that's not a sentence I *ever* expected to be saying).

But the best I've seen to date comes from Herr Langner, in particular the level of detail in the entry at Oct 1st, 11:00, shows Herr Langner's team (unlike f-secure and many others) has some credibility wrt process control.

http://www.langner.com/en/

F-secure, if you choose to update your FAQ after reading this, please do it nicely.

@Z80 for FADEC (and what OS is in an S7 PLC)

TLDR fans, stop reading now.

Thank you once again for your input Mr Smith 19. However, on this occasion one particular bit of your reply deserves further comment. The comment about nuclear reactor timescales is afaik valid, and the comment about deep embedded people *should* be valid but, remarkably, some PHBs in positions of authority see different. However...

There is a *lot* more in a modern full authority digital engine control (FADEC) for an aircraft than a Z80 (or even a credible number of co-operating Z80s) could cope with, especially if you try to develop using the trendier languages for these applications (Ada or to lesser extent C++).

For a start, the chances of fitting a worthwhile amount of the currently required code and data in a 16bit/64kbyte address space are vanishingly small, and bank switching and similar techniques necessary to bodge extensions to the address space bring their own challenges.

Multi-precision integer and single precision floating point are required from time to time these days, and in the typical ~20ms cycle time the combination of essential input validation and actual control calculations required for the control loops would not be practical. The size of the data tables required is also surprising; high resolution lookup tables are required for all kinds of things (pressure, temperature, you name it) and these tables consequently are not small.

Part of the reason for this is that, driven by the need for best "mpg", modern jet engines have very little tolerance between the normal safe operating zone and the "whoops" zone (hence best to ignore the idiots Branson and O'Leary and their comments a little while ago re the safety of flying through volcanic ash clouds). This very limited margin for error makes accurate and timely calculations even more important.

It's only a couple of decades since analogue systems based on operational amplifiers and the like were considered adequate for engine control (usually in conjunction with a beatifully engineered hydromechanical system fundamentally based on springs and clockwork), and doubtless a Z80 could have replaced one of those controllers, but the economics of affordable flight mean those days are long gone.

Add the need for a language such as Ada (or, believe it or not, C++), and the whole thing just doesn't fit into a 16bit address space, although the full 32bits is far more than is necessary.

"Forth type questions"? Are you sure these are not related to Lucas Aerospace's legacy [= "stuff that works"] 1980s translated (not interpreted, not compiled) threaded-code language, which iirc was called LUCOL, and was eventually used on various chips from Texas 9900 (16bit) to M68K, including the first UK civil FADEC systems? It enabled extremely simple extremely compact control programs which were trivially simple (that word again) to design, document, code, verify, and test (in this business, simplicity should usually be an advantage). It's so old (and, sadly, obscure) that there's little evidence of its existence, though if you have access to SpringerLink (I don't) there is a paper whose abstract looks promising. It's flying lots of Rolls Royce civil engines from RB211 onwards, and a few others, but currently out of fashion in comparison with Ada, even though flying Ada requires either full trust in the compiler (yeah right) or far more testing using the compiler and chip in question than the PHBs like to pay for.

If FADEC really was doable on a Z80 it would be being done, as Z80s are well known, well understood, and well supported, not to mention its biggest attraction to the PHBs, cheap to implement. Other readers may not be aware that Z80s didn't die in the same era when the S100 bus died, Z80s simply moved elsewhere e.g. into ASICs into cellphone handsets, which meant that at one time not too long ago, Z80s were the world's most widely used microprocessor. Obviously handsets are a market now rightly dominated by ARM.

The same basic SoC ASIC techniques as are used in a handset are also used in an engine controller although obviously the engine-mount environment calls for rather different silicon fabrication techniques; you can't buy these chips at Maplin.

When the 16bit address space became a limitation (back in the 1980s) the replacement processors of choice were typically from the 68000 family. Some unlucky folks (others would say foolish folks) chose the short-lived Z8002.

Since then, PowerPCs have generally been a preferred target for quite a while, in large part because of performance per watt factors. Obviously other options are available.

Anyone starting from a clean sheet today (unlikely, cost of entry is too high) would do well to look at licensing an ARM design; one of the many reasons ARM do well in addition to performance per watt is that courtesy of predication (and the Thumb subset) they get excellent code density (less memory for a given application, or a more complex application for a given amount of memory).

http://www.springerlink.com/content/t5u58euk56dh89kx/

See also: Dolman, W.C., Parkes, J.P. "An Approach to Software for High Integrity Applications." The American Society of Mechanical Engineers. 82-GT-251 (1982)

(credit to heater @ http://forums.parallax.com/archive/index.php/t-109610.html for the ASME reference)

Now returning you to routine Stuxnet coverage...

If anybody knows what processor and OS are inside a Siemens S7 PLC I'd be interested to hear it. I have a vague recollection that the usual S5 models used iRMX as the core OS, which means they were using a mainstream Intel processor. But the iRMX may only have been the comms cards. Either way, contrary to what some folk seem to have been thinking, the PLCs themselves don't run Windows, but the PCs to which they are connected generally do run Windows, and that is the heart of the problem.

My coat is the anti-static one, smelling gently of aviation fuel.

[submitted Sun 19:05 BST]

Cyber Super-weapons

Is that it? A weapon of mass mild inconvenience? The authors used up a top quality Windows zero-day for this?

They would have done better to bribe a cleaner in the target plants.

Hang on a minute...

They're running nuclear power plants and oil refineries on Windows?

Oh s41t oh s41t oh s41t !

Mine is the lead coat hanging from the entrance to a nuclear bunker.

Run Windows, get infected

Its still and ActiveX exploit and, I might add, regular users having the ability to install software. That really good windows security.