Microsoft issues stopgap fix for critical Windows flaw Microsoft has published an automated workaround for the newly discovered Windows vulnerability that criminals are exploiting to seize control of computers, including some used to manage sensitive equipment at power plants and other industrial facilities. The software giant began distributing the Fix It on Tuesday evening, five …
"Previously, users had to make the changes manually, a process that risked bricking a PC in the event it wasn't carried out correctly."
I hate to be a pedant and all, but that's not bricking. Bricking is a specific word meaning "to break beyond any hope of repair".Please don't misuse it, as it's a useful word.
When does breaking become beyond repair?
Charter Cable has been "bricking" Motorola DOCSIS 3.0 modems right and left. You are left with a totally functional device from your side, you can watch its cute little lights flash, view its web pages, reset it but the firmware totally disables the cable side from being able to handle ip traffic and renders it impossible to do a firmware upgrade to replace the garbage firmware that was installed in the cable modem.
Do you call this an "effective brick", a "lobotomy brick", "semi-functional" brick, "esthetic brick with decorative lights"?
As no firmware is available to you to reflash the cable modem if you had the JTAG equipment to do it, it is rendered inoperable with no way for the cable company to push an update into it to bring it back to life.
The icon ** ISN'T ** designed to contain executable code, per se.
What's happening is that griefers and other miscreants have identified a flaw in the shortcut parsing mechanism that can be exploited by filling parameter fields within the shortcut with unexpected data.
These parameter fields are descriptors that are used to tell Windows what folder/file the shortcut points to, what application the target's MIME type is registered to, what image/bitmap to use to draw the shortcut's icon, things like that.
When the shortcut parser encounters this malformed data, instead of failing gracefully, the parser fails in such a way that causes the malformed data to be executed as machine code. This parameter-data-turned-machine-code can be used to do all sorts of nasty and/or unexpected things, depending on the privileges the code inherits from the parser, and/or the code's ability to break through the other layers of Windows' security subsystem.
This kind of attack can theoretically work on any OS with a modern, shortcut-and-icon-based GUI (including Linux and Mac OS X), ** IF ** the shortcut parser isn't up to snuff (in other words, is suffering from the same style of bug).
All you need to do is fill a *.desktop file (for a Linux desktop environment like GNOME or KDE) or resource fork (Mac OS X) with lots of specially-crafted extraneous data, and ** IF ** the GUI's shortcut / icon / *.desktop file / resource fork parser breaks in the right way, you ** MAY ** be able to exploit the situation to run arbitrary code.
Note that I am NOT saying that Linux or Mac OS X suffers from the same kind of hole. A lot of things need to fall into place in order to successfully exploit a weakness in any operating system component. I am speaking hypothetically, hence the prodigious use of the word ** IF **. No operating system is bullet-proof.
http://www.kb.cert.org/vuls/id/940193
"Microsoft Windows fails to safely obtain icons for shortcut files. When Windows displays Control Panel items, it will initialize each object for the purpose of providing *dynamic icon functionality*. This means that a Control Panel applet will execute code when the icon is displayed in Windows. Through use of a shortcut file, an attacker can specify a malicious DLL that is to be *processed within the context of the Windows Control Panel*, which will result in arbitrary code execution."
Well that goes without saying surely. I for one don't expect to live forever.
But I did think that the initial comment about WinCC being used to manage Nuclear Power stations was verging on scaremongering. It all hinges on what you mean by "manage".
Undoubtedly Windows is used within such places, it may even be used to monitor some aspects of the plant, but I would be amazed if it were used to CONTROL any part of the process.
"Nuclear facilities running Windows???" ..... Ned Ludd Posted Wednesday 21st July 2010 23:25 GMT
Hmmm? Is that Microsoft outed as a Defence Operating System and a Phorming Grooming Phish with a Needy Nerdy Feeding Octopus Tentacle, which would be as Windows and Open PerlyGatesPython Doors into your Programmed Computer Side/Virtual Machine Being?
Which would all raise a Novel Enigma and Moral Dilemma today, for if IT were not so, is IT so now?
Microsoft ..... for All of your NEUKlearer Cloud Engine Needs with Sublimely Stealthy Azured Feeds Guaranteed?
And if that be not so ........ then is Microsoft a ZerodDay Vulnerability Lodes Source and Target for Acquisitions and Mergers XPLoitering or just Lacking a Beta Program to Clean up its Goliath Act and Samson SPills .... http://www.healingstory.org/crisis/mice/mice_and_elephant.html
I remember reading about when the US military first put Win NT onto one of their Nuclear subs.
It promptly decided the dock was 30 meters shorter than it actually was and ran aground almost immediately. Turned out it was due to a hitherto undiscovered bug in the OS...
You may be a bit sceptical when you see this, I know I was at first. I thought it highly unlikely that the European nuclear regulatory authorities would let a nuclear facility run simple commercial SCADA in a critical role. I know in Olkiluoto in Finland, the much-delayed vastly-overbudget nuclear station is disastrously late for many reasons, one of which is that the European nuclear regulatory authorities policy requires entirely independent systems for safety shutdown and for routine control, whereas the supplier has proposed a single integrated system.
I was assuming Dan had put two and two together to make seven. Then I remembered one of Dan's articles last year [1], about a security issue with a SCADA package in use in the electricity industry. The systems integrator was Areva Transmission and Distribution, the SCADA package was Cimplicity on Windows (a package conceptually not too different to Siemens WinCC). Areva are also the main contractor at Olkiluoto, and Siemens are a major shareholder in Areva.
More substantial detail would be most welcome, in order to avoid two and two making seven.
[1] http://www.theregister.co.uk/2009/02/05/areva_scada_security_bugs/
Add two different things and the total is always wrong.
I can't see any reference to Cimplicity in the articles about eTerra.
When I had a training course on it (under an older name) it was Unix based (but supposedly capable of running on Windows & VMS). I know it's moved on but I doubt that it's switched to a different supplier's platform.
Areva has long been in the Nuclear industry. a few years ago it bought the T&D division from Alstom to bolster the latter's balance sheet. (French Gov had major share in Areva and couldn't allow one of its major companies to fold). I do not believe that there has been any technical corruption between the T&D arm and the nuclear bits. So I think that that link fails.
But I'm not surprised that the suppliers are trying to remove some of the complexity in order to reduce costs. Hopefully the regulators will stand their ground.
I would too. But from time to time I am amazed. By Windows for Warships, for example (as an example which should be familar to many readers here). And less familiar to the public, I am continually amazed by some of the routine software and system engineering (mal)practices at UK high-tech safety-critical systems companies I am familiar with that I can't talk about here because all that would result is honest decent concerned engineers losing their jobs while (ir)responsible managers get promoted up yet another level or retired early. AC obviously.
Care to back up that ridiculous assertion with actual sources?
There may well be Windows on an A380 somewhere, but on any aircraft of that nature, critical systems such as flight control and engine control are subject to a regulatory regime called DO178(B), which results in them not being able to use Windows, or indeed pretty much any run of the mill commercial software - potential exceptions include specific flavours of Intel/WindRiver's VxWorks, and an OS from Green Hills Software, and maybe others. But Windows and Linux and the like do not and will not qualify for critical systems on aircraft, and I would be very very surprised if they qualified in a nuclear environment either.
Ignorant little boy.
I believe the inflight entertainment system is windows based but you're right, that's a very different kettle of fish.
After all, it's not like anyone would ever directly connect the inflight entertainment and flight control systems* now, would they?
*any resemblence to any recent Boeing design cockups is entirely intentional.
I was on a Continental flight a few years ago and all the way across the Atlantic, the in-flight entertainment system kept falling over and rebooting. At the time I got some blurry photos (god bless my original BlackBerry Pearl) of a curious penguin logo as the system attempted to come back to life. Thankfully only Linux crashed on that flight.
"it's not like anyone would ever directly connect the inflight entertainment and flight control systems"
I thought the plan was exactly that; they may not officially talk to each other, but they share network cables and network bandwidth (in a redundant setup), so the supplier can squeeze in a few more passengers by installing less cabling.
Reliable info is hard to find though so correction and clarification is welcome.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
