And why is this?
Because it is so much butt-pain trying to keep Windows apps up to date. Each on uses it's own (crappy) update system because the OS layer provides nothing. Just one reason why I am cutting the Windows out of my life.
Failure to apply third-party patches rather than updates from Microsoft is "almost exclusively" responsible for the growing exposure of Windows machines to security threats, according to Secunia. Stats from users of Secunia's patch management scanning tool report that, on average, less than 2 per cent of Microsoft programs are …
I expect that all those who have downvoted you haven't experienced the simple life of Linux software repositories: "Update All"
Granted, it did used to be all horrid and command line based: "yum update" etc.
I would love for MS to implement something similar, and also remove the need to press 'Next' a million times during software installs.
The problem is, while some point-releases do offer patch-updates, I can think of several programs that when they're "updated" they require you to buy the new version. Ever "update" from PowerDVD 8 to 9? Linux OSes manage this easily because the upgrades are free. The best you'll find in Windows pay-for software is a "lifetime license." That aside, freebie addons, such as Flash Player, iTunes, Quicktime, Firefox, etc should have a package-manager system they "register" with for free updates, rather than the whole "check for updates every time you start" crap or even worse, the adobe/apple update notifiers.
As a side thought, I wonder if this "research" classified Internet Explorer as a "third party" program, as opposed to an Operating System component, or if IE8 was considered an OS "update." If it was classified as a "third-party" app, like it should be, then I can more than believe the numbers toward programs being the bane of existance rather than the OS. It's been a while since we've seen a Code Red-type virus that propogates on its own rather than require the (stupid) user to hit "yes" 3 times.
> Linux OSes manage this easily because the upgrades are free.
No - Linux OSes manage it easily, *and* the upgrades are (generally) free.
Repository access can be controlled - just look at Red Hat's RHEL repos. If you haven't paid the bill, you don't get the binaries. This is *exactly* the same model that you would use for proprietary software - it's already working.
Because of the licence, RH *also* supplies source to its code - but that doesn't affect the situation wrt installable binaries ;those are controlled by subscription, and source availability is only related because of the licence, not because of any innate need to couple the two forms.
Windows patching is reasonably unobtrusive and doesn't prevent you from working while it's going on. Lots of third-party patchers are run needlessly and/or demand that you don't use the software while the patch is downloading (not installing, that would be reasonable - downloading!).
Add to that the fact that some vendors (*cough*adobe*cough*apple*cough*) don't distinguish between security patches and bloated new versions that somehow manage to increase requirements by 50% while adding no new useful functionality at all and moving all the GUI elements around so that you no longer know how to use the software, and it's no wonder people don't bother patching.
How many people think that Windows Update does ALL the patching required and don't realise more effort is needed for non-MS stuff?
Whilst a certain amount of education would help in that respect, it's amazing that there still isn't a centralised place or mechanism for updating Windows.
> it's amazing that there still isn't a centralised place or mechanism for updating Windows.
A central *place* would be a very bad thing - control over everyone's update status would pass through the hands of one small group of people. Ick.
But a standardised updating mechanism would be comparatively easy - you could pick something like apt or yum which, being Free Software, could be ported to Windows without even needing to ask the copyright owners. You could sit that atop a package management database - like rpm or dpkg, which are also available to all comers (including Microsoft) without charge.
The advantage of this is that you can add and remove repositories at will - so if you've had enough of Adobe's updates, you can disable those without affecting the Microsoft ones. You have a standardised mechanism with decentralised data, and control in the hands of the user.
It would take a little while for every software distributor to get round to packaging his code in this way, but package management is *such* a boon, it would become popular in short order.
Will this ever happen? Of course not. But that's not for technological reasons :-(
 The authors have already granted you all a licence to redistribute rpm, dpkg, apt and yum, because they are all released under the GPL. You *can* take that code. You *can* bundle it with your proprietary code. You can modify it if it doesn't meet your requirements. All you need do is release any derivative work *** of that component *** under the same licence.
Are you saying that if I am running 100 apps on windows I should keep up to date with updates for 100 apps separately. Better yet, that 100 plus third party developers must install a memory resident update program to check or do the update automatically.
Bull bull bull.
The only reasonable solution is for the central update mechanism. For example, expanding Windows Update to all applications installed on windows, including a mechanism to block applications with known severe vulnerabilities that have not been updated by the developer.
> Are you saying that if I am running 100 apps on windows I should
> keep up to date with updates for 100 apps separately.
It's much easier to let a computer take care of that.
> Better yet, that 100 plus third party developers must install a memory
> resident update program to check or do the update automatically.
It's much easier for an application to run - either on demand, or periodically - to take care of that.
> Bull bull bull.
Well, it would be if it were to be implemented as you suggested.
Alternatively, if it's implemented as many of us use it, it's really quite painless.
> The only reasonable solution is for the central update mechanism.
No, that's not reasonable.
Who's going to control that central update? You're putting a lot of power into the hands of one organisation. Better make sure it's not one that has a history of anti-competitive action. Who's going to handle the responsibility of making sure that the right updates get posted at the right place for the right users? That's a lot of contract work.
Alternatively, you can have each distributor control his own repository - just like many of already do. The aggregation of that repository data into a runtime environment is what the user application is there for...
This isn't difficult. It isn't new. It's what many of us already do.
"Who's going to control that central update?"
The user (or admin). Quite easily too. They can add a thing (lets call it ""a repository") that contains signed-code from a trusted source. Once this "thing" is added (either to the PC itself or to some network-central doofer by an admin) the PC's OS just checks periodically to see if there is anything new.
Repository 1? Nup
Repository 2? Nup
Repository 3? Oh look, updates for this that and the other.
It can the auto-install, inform user or whatever.
No "one ring to bind them all", the power remains with the end-user to use (or not) the third-party repositories. All the OS provides is the mechanism for this to happen. It's a shame no one in computing has thought of such a thing. A real shame. If only there was some kind of OS platform that did such a feat right out of the box. That would be all of the awesomes. :-)
> "Who's going to control that central update?"
> The user (or admin)
Then it's not a central update...
> Repository 1? Nup
> Repository 2? Nup
> Repository 3? Oh look, updates for this that and the other.
See? Decentralised. that's the point...
The poster to whom I was replying was talking about all updates being pushed to a central repository - hence the control question I (rhetorically) asked. The solution I proposed (and you elucidated) is to decentralise, and thus to avoid all those control issues...
I think we are splitting hairs. By "centralised" I mean one mechanism provided by the hosting OS. That may back onto a main network-server of some kind, or separate system but all the applications get updates from the same system which checks at the same time. Not each application running it's own checks and employing its own security (if any).
So, IMHO, the repos are "centralised" But that's all so much semantics.
Yes, if you update systems at different times you may hit problems. In that case you want some admin-type system to make all the related updates at once. There are a plethora of systems to do this, but they can only be as good as the data that feeds them.
By having some common repo-type system (apt, yum, whatever) it makes this much easier and one does not need a bazillion plug-ins or client scripts to click pop-ups just to get system updated.
As for version clashes...well yes that is ball-ache. It's been ball-ache since the dawn of IT and I don't see it getting any better any time soon. One option is to let a third party pack and test the various updates before rolling them out to you (say Red Hat or Canonical). But this means you may have to wait a while as things get tested, which may or may not be ideal.
At least you can access the source code and, possible, patch it yourself if it comes to that. Not ideal either I grant you, but it is at least another option.
> I think we are splitting hairs.
Of course. We're advocating the same solution. We've both used it, and seen just how well it works.
> By "centralised" I mean one mechanism provided by the hosting OS.
Yes, I got that - but I think it's important to hammer home the fact that this doesn't route through a single "updates provider"; each and every supplier of software can implement this mechanism with very little work, and the trust relationship is between the end-user and the supplier. No intermediary need be involved.
> So, IMHO, the repos are "centralised" But that's all so much semantics.
Well, I think those semantics are important: the updater application might be centralised (wrt the computer on which it is running), but the repos are very much decentralised. That's why they maintain their independence, whilst co-operating by the simple mechanism of dependency tracking.
That's one of the things that I find a bit of a ball ache about repos - multiple repos with differing versions of the same package or cross repo dependancies. Then there is the remembering which repos you had configured, if you rebuild a machine and forget to write the list down... Another problem is when you've got client/server software (mythtv in my case) where you do an update on the client or server and it stops working because of incompatibility between the new/old versions.
It's not an insurmountable problem but it is quite annoying, repos are good, but not a panacea.
It doesn't have to be memory resident, with just a tiny bit of thought most companies could do what Apple do with Quicktime and stick a schedule into the Windows Scheduler which fires up their custom downloader/installer to check for a new version once a week or so.
Also, Windows MSI files are great for installing as a package.
"Add to that the fact that some vendors (*cough*adobe*cough*apple*cough*) don't distinguish between security patches and bloated new versions"
Actually, you're incorrect. Reader 9 does not list Reader 10 as an "update." You'll update to 9.4.2 and no further. You have to download 10 seperately if you want the new version.
As for not using a program while the patch is /downloading/, yes, fail on the software! At least the Firefox update is quick....
MS has no way to let you subscribe to updates from third parties. Every updater runs on startup, takes up CPU/memory, has its own problems (security, etc). Many of the updaters push out features for strategic reasons, not because you need them. Example: google updater pushing out the new web video codec for IE and firefox, iTunes updater adding MS Outlook plugins for contacts, etc. Nobody trusts them
OS/X isn't that much better, believe me.
That's why I like Ubuntu Linux. Not for its inconsistent usability, but because I know that when I do a weekly update and reboot, it is up to date.
... includes built-in app updating too.
Even so, the "Sparkle" library has been very popular on Macs, so most apps have built-in auto-updating with identical UIs. The upshot of which is that you'll often be advised that a new update is available and given the option to download and install it as soon as you start up the app.
(Also, due to the way apps work on Macs, updating is generally painless, without the need for a complex installation procedure.)
"While it is possible to only run FOSS it becomes less possible if you're a company and need commercial databases, backup software etc."
Well yes and no. First up, our company uses FOSS backup software ;-)
Even if you don't, if you're in a company using managed systems, you'll probably have a sysadmin taking care of updates anyway.
> you need to be a certain size before you can really afford to run
> your own repo and package up commercial updates.
And that size is - a single person. Yes, it's true. You need to be a certain size.
Really - a repo is trivial. It's a webserver. Want to see how to set one up?
sudo yum install httpd
sudo service httpd start
sudo chkconfig --level 345 httpd on
Want to see how to set up a yum repository on that webserver?
I have absolutely no idea why you want to portray this as being difficult - it isn't.
> To my knowledge no non-free software is available from repositories
Your knowledge is incomplete.
I know of non-FOSS software in a repository because I wrote it .
The package manager does not care whether the software is Free or not; if you want to build a repo out of non-FOSS code, just assemble the relevant packages and run the appropriate command. You might not get your code accepted into, say, the Debian repositories - but since the whole purpose of this sort of application is to distribute the repository info, that really doesn't matter.
 There are discussions in progress about converting this code to FOSS, but we're not there yet.
 For a yum repository, for example, you'd just run createrepo, and all the repo data is built for you.
Can you point to any non-FOSS which is available for updates from a yum or apt-get repo? I'm not aware of any.
Within a company you'd typically package it up yourself, but that's not really doable for end users.
What I was getting at is that if you're releasing software like photoshop for Linux OSes, it's going to be pay for, but it is used by end users at home/small office. The updates for pay for commercial software won't be on your typical repo.
> Can you point to any non-FOSS which is available for updates from
> a yum or apt-get repo?
Yes, I can.
As I said in my post, I have written exactly such software, and set up the repositories to host it.
> I'm not aware of any.
That much is clear. Are you claiming that your ignorance of any such software is proof that it cannot exist?
> Within a company you'd typically package it up yourself, but that's not
> really doable for end users.
Aside from the fact that you'd still have companies doing the packaging of their own products, creating packages is easy. I've been doing it for years. It's entirely feasible for end-users. Even if it's unlikely to be necessary.
> it's going to be pay for, but it is used by end users at home/small office.
> The updates for pay for commercial software won't be on your typical repo.
Why do you say that?
There are many ways to control repositories such that access is granted to those with paid-up subscriptions. Just look at the way Red Hat runs theirs...
"So you don't run any non FOSS on your ubuntu box? To my knowledge no non-free software is available from repositories."
I see from other replies that it is already too late to avoid this logical detour, but...
Firstly, what's currently available does not limit discussion of what would solve the problem described in the article. I can't see any technical or business reasons why non-FOSS updates can't use the same distribution mechanism as FOSS updates. As others have pointed out, the Linux repository system is all GPL-ed, and *surely* Adobe and Apple between them (to name but two interested parties) could support a public Windows port.
(Truth is, they don't care. They haven't yet twigged that security is an issue. They're about ten years behind Microsoft in this regard. Astonishing, really, but I can't see any other explanation that fits the facts. It would just be *so* *easy* to do much better than they do at present.)
Secondly, just as an example, VirtualBox includes non-free-as-in-speech components, but I pick up updates from Oracle's repositories.
Thirdly, I suspect you will find that the main offenders identified by Secunia are free-as-in-beer applications like the Flesh Player and ArseOverTit-Bat.
"So you don't run any non FOSS on your ubuntu box? To my knowledge no non-free software is available from repositories"
From Ubuntu 10.04 onwards (at least), you can install Adobe Reader, Flash, Air, Java, Nvidia/AMD graphics drivers, mp3 decoding, and various other non-free packages simply by adding the relevant repository. And the Software Centre makes it easy - it knows about some of these repositories in advance, so you click on the package and it says "add this repository?". You say "yes", and bingo, it's installed, and you get updates. The hardware drivers can also be managed from the Hardware settings screen in preferences, but I think it's just covering for the package manager in the background.
I believe in future editions there will be the facility to pay for proprietary software through the package management system.
It could all work on Windows if there was the will
Given that this is getting more and more common (as the report states) what's needed is some kind of centralised system whereby patches for all your 3rd party software can be distributed automatically. Something like yum, or yast, or the OSX App Store (better late than never) - something that *every other damn OS on the planet* has already.
Given there are tens of thousands of Windows programs, from thousands of sources, how do you propose this works? The industry already conspired to minimise Microsoft's control over its desktop - does it now want to hand it back, along with the myriad new problems that have surfaced as a consequence.
Who is responsible for the quality and frequency of the patches?
Apart from Adobe and Apple's horrific "replace everything", invalidate old shortcuts and "spray the desktop with new shortcuts like a horny teenager" practicises, the worst stuff is the crapware installed by the OEM and driver suppliers. Most of that stuff needs to be ELIMINATED, not repaired.
Frankly given the size, frequency and intrusiveness of Apple and Adobe patches, I don't want to run them too often. Not everyone in the world has unlimited free download bandwidth to cope with all of these.
> how do you propose this works?
Go and have a look at how apt and yum work.
Each distributor publishes metadata about the current state of his repository - what's available, etc. This data is collated by a client program to work out what's needed.
> Who is responsible for the quality and frequency of the patches?
The owner of each repository is responsible for updating that repository.
The end-user is responsible for deciding how often to look for updates.
> I don't want to run them too often.
As a yum user, you have the option of enabling/disabling entire repositories at will, as well as excluding certain packages if you so wish.
I'd like to remove the old known-exploitable RealPlayer version 10.5 from my system.
Unfortunately the uninstaller component is missing/faulty on this version - a well-known problem. (Real claim to only offer support for problems with uninstalling for paid versions.)
So even with the best intentions... grrrr...
Own horn and all that. I use Secunia's PSI application on a couple of my machines and love it. It's CSI offering is under consideration at work as well for patch management.
Re: the actual topic though, poorly written 3rd party drivers cause the vast majority of Windows crashes. So of course 3rd party vulns account for the majority of the required patches.
i.e linux web servers might have a lovely yum update facility thats actually quite easy to run but things such as 3rd party php scripts can still leave the system open to exploitation if the system is not locked down.
I think ms would push more updates but they would want to charge for it so its cheaper for developers to just develop their own way of updating.
Best thing to do is disconnect the network/internet connections and hack off all the i/o expansion ports to be slightly more secure.
"I think ms would push more updates but they would want to charge for it so its cheaper for developers to just develop their own way of updating."
I doubt that very much, for commercial reasons. MS have spent ten years establishing Windows Update (and Microsoft Update) as *branded* update systems. If they start offering stuff from other vendors and one of the patches does real harm, that's real damage (however unfair) to Microsoft's own reputation. (That's not great in security circles, but it is better than most of the PC industry and better than one or two high profile vendors who Secunia have alluded to.) There's also the risk of a daft lawsuit, followed by a dafter decision, with MS paying damages for someone else's foul-up.
None of these concerns would apply to a Windows port of apt or yum.
loads of little icons next to the clock in the bottom right and click check for updates, or whatever it might be for that software then....
visit about 300 websites and download latest versions. Uninstall old versions (if possible), install new versions over the next 4 hours, rebooting occasionally.
fix the inevitable 4 BSOD's you are going to get
Are a pain. I work supporting a smaller retail retailer and have disabled as many auto-updaters as I can. The people working on these machines don't need to be bothered by balloon messages appearing in the notification area. It breaks their train of thought and disrupts the flow of dealing with the customer when they stop to read that Adobe Updater will now check for updates.
So, I've made the machines as lean as possible when it comes to applications - only what's needed to get the job done, and the those applications are updated weekly. No Itunes (really! the bosses were using the POS computers to load their iPods!), Real Player or Acrobat (Foxit works fine for what we do).
It bothers me that when I put in an updated version of an application the auto-updater gets re-enabled. I specifically disabled it, why can't my configuration settings be saved? Can't they ask me before assuming that I want it turned on?
They don't let you choose the time to update, unlike Windows update and anti-virus products. Maybe if they did, I would be more inclined to use them.
And yes, it is handy that Secunia has a tool for this. Funny how they managed to bring this to our attention. Nice of them, I guess.
So basically, each time Microsoft creat a new version of Windows, they have to try and make their end bulletproof and also try to protect users from the lousy programmers who created crap code and don't bother updating it when a vulnerability is being abused.
No wonder MS have such a tough time when Adobe and quicktime can constantly update but not fix flaws people will then blame MS for.
point you to the right updates for the respective programs.
That doesn't mean I don't recognize this press release for the propaganda that it is.
I wouldn't trust MS to be the central source for updating. I like the idea of MS adapting one of the Linux Tools to support centralized updates for Third Party apps. I would not object to them keeping the MS updater separate from the adapted Linux updater. As I see it the only problem with this route is MS has no idea how to monetize the solution.
The reason for this is that MS has no central update mechanism that third parties can hook into, and if every individual app vendor provides their own separate update system the system will quickly get bogged down in bloat.
The Debian system of repositories solves this problem nicely, but MS simply refuse to implement anything similar.
This isn't about whether Windows is secure. It is about whether a Windows system has had all the relevant available security patches applied. That is not the same thing. Windows with all patches in place still isn't secure: there are unpatched vulnerabilities. Each patch that you install represents Windows not being secure before you did that, and there's a handful of known outstanding insecurities that will be patched either some time in the future, or never. So 100% of Windows systems are non-secure BEFORE you consider Adobe Reader X and Flash updates, for third-party programs which are probably on the computer when you buy it, and Java, which probably isn't.
I'm not sure, but I think Java checks for updates by default once a month, Adobe Reader something similar, and Adobe Flash sometimes announces at bootup that you should download its new version - I don't recall seeing notification of this at other times.
"I have never been outside the MS-Windows environment and so have never experienced seamless package management as a system built-in function, therefore cannot conceive how such a thing could possibly work so it must not be possible."
The answer is, of course: in the outside world, package management via a single central program has been the norm for longer than Windows has had a version number greater than 3.1.
Yes, you do get the odd proprietary supplier who, coming across from the MS world, simply DOESN'T GET IT, but they tend to spent all their time whinging that no-one in the non-MS space is taking them seriously. Linux/BSD/etc. users have better things to do with their time than piss around with manual installs and updates, so a product has to be pretty damned compelling to get them to bother.
I don't know if others share my logic, but I run Windoze Update and then PSI, in that order, thus ensuring that PSI always finds Windoze is current whilst other applications may need updating. I do it this way because, when PSI notes a needed update to Windoze or Office, it links to the Windoze Update site and I end up running Micro$oft's search anyway; might as well run it first.
I assume that there is a legal reason for Secunia's choice of links, but their choice drives my choice of scanning order, and thus skews their results in my case.
Who else has noted this and altered their behavior accordingly?
Biting the hand that feeds IT © 1998–2019