It's nearly 2015 – and your Windows PC can still be owned by a Visual Basic script Microsoft has patched 25 software vulnerabilities – including bugs that allow hackers to hijack PCs via Internet Explorer, Word and Excel files, and Visual Basic scripts. Everyone is urged to install the fixes, as well as a batch of updates from Adobe: a flaw in the Flash plugin is already being exploited by hackers to take …
I have overheard on the loo that cow-orkers are still wont to use these as it gives them "superior productivity", like a good laxative.
vulnerability in the Windows graphics system that could allow a malformed JPEG image to let an attacker read off sensitive system information
I am old enough to remember when claims of getting the clap via JPEGs was considered a joke on Usenet.
This post has been deleted by its author
Eh, may be too late. I've got Denyhosts running on a LAMP server and have noticed an uptick of lockouts from 10-25 per day to 10+ per hour. I'm guessing that somebody has infected a bunch of PCs and swelled the ranks of his Zombie PC army.
Dunno if this is the vector but SOMETHING has stirred up the anthill.
The open source has some bugs that can cause you grief very quickly in the wrong hands that have been around as long or longer.
(e.g. One still being discussed is in X.org and has been around since 1987. Then there's shellshock.)
A big complex codebase can have many lurking holes that will take many years to uncover. What works against Microsoft here is that no one can do it for them.
People like stuff that looks new. That's why most people trade in perfectly good cars or rush out to get the latest iPhone. So the emphases are on making the UI look different or adding some marginally useful 'feature.'
Besides, if they fixed all the bugs, the bug fixers would be out of work, and that wouldn't do.
A quick web search for "microsoft sued for security flaws" shows several people/organisations have tried. I would like to draw your attention to the instructions for using the GNU GPL, which includes the following:
This program is distributed in the hope that it will be useful,but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
That is in just about every piece of software I write. I can hardly blame Microsoft for including something similar in their EULAs. Every time Microsoft avoids massive fines for security flaws I get some more confidence that it is not my turn next. IFAIK, there is no legal requirement that Microsoft has to find flaws, create patches and distribute them for free. For really old pieces of software like DOS and Windows 95, Microsoft do not provide patches just like there are no security patches for ancient Linux Kernels.
There are plenty of things I blame Microsoft for, and would be happy for the courts to do something about if they could. Bashing them for providing security patches for free is not one of them.
Microsoft sells (or licences) their products for money, so they are held to a higher standard of accountability. It must be fit for its purpose, so they must either support/patch it or give refunds for a reasonable period of time.
Kudos to you for sharing your software. If you make the source code available, others can check and build on it, so responsibility is devolved. But if you deliberately put malware in there you could be sued.
Hmmm - Did I really just give Adobe Reader an excuse for being crap just because it's free?
<i>Microsoft sells (or licences) their products for money, so they are held to a higher standard of accountability. It must be fit for its purpose, so they must either support/patch it or give refunds for a reasonable period of time.</i>
There is a difference between fit-for-purpose and perfect. Perfection is an unattainable goal. There may be areas where they've been lax, but given the quantity of code in Windows (et al) most of these vulnerabilities are to be expected by a reasonable user.
<balance>Mind you, for the fairground barkers on our desktops going on and fucking on about Windows Store, Microsoft can take the proverbial up their arses</balance>
>For really old pieces of software like DOS and Windows 95, Microsoft do not provide patches just like there are no security patches for ancient Linux Kernels.
True, but, if you really need that 2.2 Linux kernel, you (or a hired dev) can always adapt the patch that was made for the 2.4/2.6/3.0 kernel. This is not like MS, where you are completely left out in the cold.
Besides, MS charge serious dosh for the software ... then again, you know the saying, a fool and his money ...
This program is distributed in the hope that it will be useful,but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
That, I'm afraid, is just a fig-leaf: courts not vendors decide liability. The software industry has been allowed by the courts to resolve flaws through new releases of their software.
There is no accountability because unscrupulous legislators can be bought by the likes of Microsucks. Once a foolish, false precedence is established, i.e. "all software has Bugs", then the clueless continue down the path of ignorance using the false original premise as fact when it never was. The reality that Microsucks and other's have not been held accountable for their massive crimes against society illustrates just how gullible those in the legislative and judicial branches of government are. If you can't understand a logic based PC then you have no business making or enforcing laws regarding the operating systems or software that run on them. Those responsibilities should be handled by educated people.
BTW, so called "free" security patches to bandaid a sieve are laughable because they are not free at all. You pay for them in the absurd price charged for each application of the software and for each $250 customer charge to report a product defect that Microsucks support can not fix.
If software vendors were accountable for flaws in their software, then the main point is no longer how secure the software is, but who gets the liability.
What would happen if an important flaw was found and exploited in Android? Google makes it (based on Linux) but charges no license fee for it. If it turns out that the phone maker gets the liability, that would make a very compelling case for using Windows instead.
Heck, it would make creating a brand-new mass-marketed piece of software pretty much impossible for any startup. You cannot be absolutely certain that a piece of software doesn't have bugs, and if you're not a big corp, the first lawsuit will simply kill you. It doesn't even have to actually be your fault; people who misused the software will still sue you and before it's settled you'll be dead anyway.
Knowing that you're at risk of sudden death from circumstances beyond anyone's control, commercial customers will stay away from you. And if you make a mass-marketed device that runs OSS, and a single flaw is found and exploited in that OSS, you're similarly screwed; you can't get back at the OSS maker because they don't sell it. Better use Windows instead; lots more flaws, but I'm not paying for them.
Is that what you had in mind?
"You cannot be absolutely certain that a piece of software doesn't have bugs"
You can be almost absolutely certain that any non-trivial piece of software does have bugs.
What might be more relevant, to users and even to the courts, is whether they are the kind of bugs that a reasonable person might reasonably expect, or the kind of bugs that might be expected from a reasonable vendor who had taken adequate measures to reduce the risks to a level that was "as low as reasonably practical".
MS, despite their public statements in recent years about security in Windows, appear not to have understood "as low as reasonably practical". MS's own published bug details indicate that they appear to be shipping, in 2014, code with the same vulnerabilities that they had ten or more years ago. But they have told and will tell you that Windows has been reviewed/rewritten from the ground up to make it "secure". Some gullible people even believe it, apparently.
Sell.
Good points, which is why I am very curious about how the laws, and lawsuits, are going to evolve with regards to self-driving cars and trucks.
Right now we have a regulatory situation where most software is more-or-less exempt from getting sued, most of the time, for defects. On the subject of road traffic and driver error, we also have copious case history of damages and indemnification procedures, funded through insurance, for driver-caused accidents.
And we have a history of rather more extensive damages where the fault can be attributed to shoddy work by the car manufacturer. But most accidents are caused by drivers and/or road conditions or maintenance-caused mechanical failures. Not by manufacturing defects as such.
Let's take as a hypothesis that a correctly implemented self-driving car can be made to drive 10x as far a human driver without causing an accident.
If there is an accident attributed to say the Civic 2025's self-driver software, I don't think it will fly to say "oh, well, let's grant damages as if a human driver caused it by gross negligence. and keep it in mind that it is much safer in aggregate". Or "geez, you signed the EULA, didn't you?"
I am guessing that car manufacturers will be hit up for much larger damages, at least until case law stabilizes.
So, even much safer self-driving cars (no, didn't say we were there yet) may take some time to take off, precisely because I think that the software will in this case be held to a much higher standard. Is this an entirely rational or desirable approach, if software could be made safer than human control?
p.s.
Wonder if the same principles guiding the airline industry could apply instead. The Brazil-Paris flight crash was due to problems http://en.wikipedia.org/wiki/Air_France_Flight_447 with the instrumentation and software, but Airbus didn't get sued to oblivion either, they were just expected to fix it thoroughly (yes, there are lawsuits pending apparently but aircraft manufacturers generally don't get dinged too much).
p.p.s. what kind of idiotic website is going to use vbscript in 2014 anyway?
Not quite 100% true, Vic. Yes the pilots didn't excel themselves, but there were engineering factors too, the main one of which would be two of three airspeed indicators failing identically at the same time (an event allegedly so improbable as to be ignorable), leaving the flight systems trusting the *failed* sensors.
Major failures are frequently like that - a string of "shouldn't happen" things line up, On a good day any individual one might happen and not cause a real problem because some other mechanism prevents catastrophic effects, But statistically speaking there will be times when enough of the "shouldn't happen" things happen together and the protection mechanisms are overwhelmed and bad things happen. "Swiss cheese syndrome" is what it's apparently called in the industry.
We don't need another GUI, we just just need a decent sandbox, Windows8 is like the others...
Oh sorry Tina.
Download in the browser (has lots of internet access) and save the data to disk.
Open in Excel (it, and child processes, cannot spawn network-capable processes or open network sockets - can only use file->save).
This hits the malware authors in the pocket. Even if you find a hole in Excel, they can't exfiltrate the data.
What kind of OS development have MS been doing since NT3.51? The OS is supposed to mediate access by programs to resources. That is what it is for. Why haven't we progressed beyond the file-system? It doesn't even have to be mandatory - a run-time manifest wrapper of what an app is allowed to do would be sufficient, preferred even.
It doesn't solve the problem of a hole in the browser, but it would still be a good thing!
Most (almost all?) browser exploits depend on javascript for their operation. The current POODLE for TLS requires javascript. Plenty of sites - like this one - do not require javascript. I do almost all of my web browsing with javascript disabled.
Imagine how bad it would be if banking and commerce sites required javascript ...
Every bank in the country of denmark, and most of Scandinavia I think requires. Further, the national secure identity system (nem-id) used for access to government sites requiring secure identification is Java based.
Java is alive and well, and required if you wish to interact with the government.
That is the question you have to ask.
Most of the vulnerabilities come from having flexible operating systems. They let you automate common tasks and they let you install whatever software you want.
The problem is, malware can use these automation tools for its own ends and, because users don't like it when the PC is locked down and they can't run macros or install their favourite tools, the OS has to accomodate the installation of 3rd party software, which includes letting malware install, if the user is not careful.
The same goes for nearly all operating systems, even side-loading on Android and iOS, for example.
If you disable macros, VBScript, command line and Powershell, then the PC will be harder to use and simple, repetitive tasks will have to be done manually - and the same goes for Open Office and Linux, OS X etc. You would need to remove all of their scripting capabilities in order to better lock them down.
For the user who only uses a web browser, it might be no loss, but for business users, developers etc. it would be a real pain.
From the first paragraph of the article:
"Microsoft has patched 25 software vulnerabilities – including bugs that allow hackers to hijack PCs via Internet Explorer, Word and Excel files, and Visual Basic scripts."
Also PowerShell can be exploited by using Base64 coding and passed as a command line parameter. Metasploit and SET both have PowerShell exploitation tools.
https://github.com/rapid7/metasploit-framework/wiki/How-to-use-Powershell-in-an-exploit
"Also PowerShell can be exploited by using Base64 coding and passed as a command line parameter. Metasploit and SET both have PowerShell exploitation tools."
If you read what you linked to, it clearly says that Powershell is useful POST EXPLOITATION. However, PowerShell being far more secure than say a UNIX shell - by default it will only run signed scripts. Therefore an exploit using Powershell would have a tiny target market - and hence isn't widely used. The base64 method mentioned is only possible if you already have full access to a PC (post exploit).
In more detail as a C&P - default Powershell restrictions are quite strong:
•Powershell does not execute scripts by double clicking on them by default.
•All scripts must be digitally signed with a trusted digital certificate by the host system so as to be able to execute.
•All script when executed in a PowerShell session must be executed by providing the path of the script - relative or full they cannot be executed just by name.
•Code is executed under the context of the user.
•Code that is downloaded via a web browser or thru emails clients that mark the file as downloaded from the Internet in the file meta-data the file will blocked from execution unless specifically allowed.
These defaults settings provide the following protections:
•Control of Execution - Control the level of trust for executing scripts.
•Command Highjack - Prevent injection of commands in my path.
•Identity - Is the script created and signed by a developer I trust and/or a signed with a certificate from a Certificate Authority I trust.
•Integrity - Scripts cannot be modified by malware or malicious user.
Having full access to the PC is the general requirement for the other forms of automation as well (Office macros, VBScript etc.).
Which was the point I was responding to.
I agree, you have to get the malware onto the machine, before you can execute it in this manner - and newer versions of Office also baulk at unsigned macros - users have to tamper with the security setting and they need to accept the script.
And I agree that PowerShell is relatively strong in its protection, but it isn't invulnerable - and the Base64 encoding method doesn't require PowerShell to execute a script file, just a script string passed as a parameter, if I am reading correctly.
And I wasn't just talking about Windows, I did mention that this applies to all operating systems that allow the installation of software and automation of processes.
What you say may have an element of truth (though it could have done with saying more about trust).
However it's somewhat irrelevant while Windows still has holes which allow "unauthenticated remote code execution" ie you send a Window box a specially formed network packet, and you're in.
It's also somewhat irrelevant while Windows still has holes which allow a simple operation which ought to be inherently safe (e.g. opening a JPG) to be an exploit vector.
"If you could not have code execute in a .JPEG, then how could the "Spooks" have their Steganography?"
?
Every definition of steganography I've previously seen says that *data*, not code, is hidden within the picture. The specially-encoded picture is read by a matching special purpose application which extracts the hidden *data*.
ICBW.
Steganography would normally use features of the actual photo itself to transmit the message. It might be as simple as "a picture of a cat means 'yes'", "a picture of a dog means 'no'", or you could or you could change a few pixels in an inconspicuous part of the photo to send a coded message.
You can understand an operating system requiring a steady stream of security updates over time - it's big and clunky with large chunks of code not revised for many years and written before the idea of exploits really took force.
But Flash? Every bloody month there's some new and exciting vulnerability discovered. It's 0.001% the size of an OS yet it seems to have more vulnerabilities than Windows and OSX put together. Not only that but it's got a crap updater that doesn't follow any style or usability guidelines laid down by Microsoft - hardly surprising it's ignored.
Come on Adobe - (a) consider rewriting it from scratch or open sourcing it and (b) integrate it into Windows updates so that fixes are delivered seamlessly.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
