Windows XP is not affected
Wow, back to the future (xp) for me then.
Russians hackers have exploited a zero-day vulnerability in Microsoft Windows to hijack and snoop on PCs and servers used by NATO and the European Union, says security biz iSight. The software flaw is present in desktop and server flavors of the Redmond operating system, from Vista and Server 2008 to current versions. No patch …
This post has been deleted by its author
Well this is a little different to those bugs, this requires user interaction to happen (like most of the bugs patched every month), the current incarnation is open a powerpoint document that's infected, but could be others too, just need to exploit the OLE bug. Whereas shell shock and heart bleed required the computer to be connected to the internet to be executed (like code red, blaster etc).
The name is a little miss-leading, that's the groups name, not the exploit, it isn't a worm, so no where near as bad as what they are.
(You can trust the Microsoft crack team to come on here and play it down. You took your time)
Well this is a little different to those bugs, this requires user interaction to happen (like most of the bugs patched every month)
The thing about heartbleed and shellshock, they do require human interaction - ie, setting a fucking server up and opening your firewall. They don't just fall out of your arse.
However, this bug and the others that are, as you said, "like most of the bugs patched every month" just need two things: A windows user, and a standard computer.
OK, so interaction for you means, you have to setup the system, not really sure what systems you run, but i agree, ones without an OS and running any services at all are more secure and do require human interaction to be compromised.
So not really sure how you would run a Apache, or DNS, or VPN server, without an OS, or applications or firewall opened for those services to be exposed.
You need more than 2 things (based on your definition of human interaction), You would have needed someone to have bought a computer, got an internet connection, connected it all up, bought project, installed it, disabled protected view, setup an email account and received a compromised powerpoint, or gone off looking for a powerpoint document that was compromised, and then opened it.
Where as with heartbleed / shellshock you would have had to bought/install the server, install and configure an application that uses OpenSSL/Bash for example apache or openVPN got yourself an internet connection, opened the firewall (which you would as that the point of it), now anybody on the internet could exploit it.
Because this diminish the graviy of those vulnerabilities? And still shouldn't open source code have been reviewed by thousand of eyes to spot those vuilnerabilities earlier? Shouldn't have open source code "more secure" because of that? Of course this is closed source, thereby no one peer reviewed it, right?
Or after all the only real way to have secure code is to design it well, code it better and test it properly - open source or not?
"Because this diminish the graviy of those vulnerabilities? And still shouldn't open source code have been reviewed by thousand of eyes to spot those vuilnerabilities earlier? Shouldn't have open source code "more secure" because of that? Of course this is closed source, thereby no one peer reviewed it, right?"
That's a fair point, after all those thousand eyes helped with OpenSSL / Heartbleed! :-)
That's a fair point, after all those thousand eyes helped with OpenSSL / Heartbleed! :-)
Correct, otherwise a less honest person would have discovered the bug. Instead, the bug was discovered using two of those "thousand eyes".
Take this "sandworm" as an example of how close-source bugs are usually found... which was originally discovered (and exploited) 6 years ago.
Because you know if someone discovered and used heartbleed before? It doesn't leave any trace on your server unlike something that needs to be run locally.
Bash bug has been there for how long? Twenty years? Are you sure it was never exploited? Securoty researchers will tell you, crooks don't.
Because you know if someone discovered and used heartbleed before?
No, no one can say for sure. But if they did, who knows how long they'd continue to abuse it if it wasn't found publicly.
I think the point is, if it wasn't for these so called "thousand eyes" the bugs might never have been exposed. OSS brings no guarantees, just a better possibility and better outcome.
"XP not affected" is probably indicative that the target victims of the attack probably aren't using Windows XP any more. So it does beg the question, "Who are the 23% of Windows XP users?" in this article http://www.theregister.co.uk/2014/10/03/microsofts_nightmare_deepens_windows_8_market_share_falling_fast/
Presumably they don't work for Ukrainian Government, NATO or Energy companies.
""Who are the 23% of Windows XP users?"
Having met one and their laptop recently, I can affirm they are users of old kit who don't know the name of their operating system and delete any annoying messages that appear in the bottom right hand corner of their screens."
Or users who actually still have hardware that runs well, familiar software that runs well and is reliable such that the entire system does the job. Why throw even more cash at MicroSoft for a crap front end ... as well as the hardware to run it on!
Yes this is posted from win 7, yes I do also run 7(64) but yes, I still have three machines that run Xp *and do exactly what I want them to do*, so why upgrade them?
Don't for a minute believe all Xp users are numpties ... they may just be a bit fatter in the wallet.
Yep, ActiveX are legitimate payloads for Office OpenXML files (as are other files…)
Powerpoint is particularly weird as it relies on Excel for charting functionality. Nothing wrong with this per se (delegation avoids code duplication) but the way it does it is far from ideal as rather than using a component it uses OLE…
Do you know that OLE is COM, and COM is "Component" Object Model? In this case Excel is exactly a "component" handled through COM interfaces and hosted in the application - in a language and application agnostic way. What is a "component", after all? Something you can embed and drive from another application? What is better, a standard, common API, or a dedicated private one?
Sure, MS could have made office application interop available only to its own applications through private dedicated APIs callable from VC++ only, and all of you would have cried about the "customer lock-in", "hidden private APIs", "unfair competition", "lack of interoperability", etc. etc.
re: "Sure, MS could have made office application interop available only to its own applications through private dedicated APIs callable from VC++ only, and all of you would have cried about the "customer lock-in", "hidden private APIs", "unfair competition", "lack of interoperability", etc. etc."
Or they could have split the code out into a DLL (I hear they do that in Windows) and call it from wherever.
Do you know that OLE is COM, and COM is "Component" Object Model?
Yes, I know what both the acronyms are and despise them both. I won't dispute that they have utility (in the absence of a proper component model) but this should really be API calls and not executable embedding which is the security risk. OpenOffice for one has a much cleaner implementation of the underlying principles.
Exactly. The issue are some developers who believes they need a shell - and program more - just to execute some command line utilities from an application, when often there's really no need for it - you can run them without a shell and just redirect I/O.
But using system() or its equivalents is a quick and lazy way to perform that, so why not use it? It's their level of abstraction that is weak - they really don't understand what a shell is and a command line program is.
>>But using system() or its equivalents is a quick and lazy way to perform that..
Dirty and lazy -correct. Still not really a problem if you have system() in your CGI.pm script, for example. The problem is though when you accept any input without disarming it while passing it to the system() operator or a certain pipe could have been dangerous with the shell shock vulnerability . However, taking an uncontrolled input is madness already whatever the language it is, using any shell in cgi raises all this stupidity to the second power.
According to this [isightpartners.com] this was being exploited since 2009.
This post has been deleted by its author
Can anyone spell “blow your own trumpet”?
A vulnerability has been discovered, good work chaps. But really? Sysadmins roll out remote code execution patches every month and not just for Microsoft products (*cough* Adobe *cough*) without getting in a tis.
The only reason there is an article about this one is that it was used against a high value target, a private company found it, they gave it a name, slapped a logo on it and cranked the hype machine up to max in a bit to gain sales/notoriety.
So “massive” is this vulnerability that Microsoft decided not to publish an out of cycle patch, but to roll it out in with todays Patch Tuesday. Whys is that do you think?
It’s a lot of work to come away with nothing more than the summit lunch menu.
Quite. I saw the title and started thinking "bugger, have to patch servers", then saw references to OLE and suspected where this was going, and finally got to the PowerPoint bit and realised "oh, fuss over nothing then, patches needed for clients, but funnily enough the servers don't run PowerPoint!".
My one real complaint about this... why link to a wikipedia article explaining Shai-Hulud and not link to the CVE article!
Am I the only one picturing...
"No. No, Ahmed. No more bomb belts or explosives in cars for us. From now on we will be using weaponized powerpoint. It's pie charts and meaningless graphs will bore the yankee, imperialist scum into submission. Ha har!"
Ok. Maybe it was just me.