June has been a busy month for web-centric security patches. Microsoft fixed 31 different vulnerabilities (many affecting IE and Office), Adobe patches critical vulnerabilities in Adobe Acrobat and QuickTime, Google plugged some WebKit holes in Chrome, Apple released over 50 security fixes for Safari, and Firefox had 11 security vulnerabilities fixed, half of which were rated critical. With a lineup like this, a majority of the world is going to need to install patches to keep safe.
Despite the patches being available, history has shown that people don't always install them. Installing patches is an inconvenience; it interrupts the use of the system and potentially requires reboots. In enterprise environments, all of this can be semi-automated with patch management and deployment systems, centralized patch repositories like WSUS, and policies that dictate the employee just sit tight while mandatory patches are applied. But for home users, computer use is often casual--which means convenience has a very strong influence. If they get on the computer to check email or surf MySpace, they are likely to not want to postpone those computing desires in order to deal with installing patches first. That's assuming they even know about the availability of patches in the first place.
Recently some folks from Google and their partners released an analysis of web browser auto-update approaches. The analysis looked at the different effectiveness of how quickly patches gained widespread deployment due to the different patching processes they offer. For example, Chrome does "silent updates"--it will download patches/new versions and automatically install them without telling you. Firefox will automatically download updates, but then you have to still manually agree to the installation via a prompt given to you by Firefox. Safari tells you that an update is available, but then you have to manually agree to download and then install the update. Opera will inform you of a new version, but then you have to manually download the update yourself and proceed through the install wizard. Internet Explorer relies on Windows Automatic Update agent to download and install patches.
Overall, the Google analysis found that Chrome’s silent update approach resulted in the widest spread of update deployment (97% of systems patched/updated) within a fixed period (three weeks). Firefox wound up with 85% of systems patched/updated after three weeks, and Safari and Opera wound up with some pretty low numbers. The conclusion? Badgering the user to be involved in the update process causes them to interrupt, abort, or ignore the process, leaving the patches/updates unapplied. That is non-ideal when security is involved.
But just because there are auto-update mechanisms available (Chrome, Windows), doesn't solve the problem per se. I've encountered situations on numerous occasions where the user has disabled the automatic updating process because the software they were using was, well, "borrowed." Microsoft has been struggling with this issue for years now: whether to allowed pirated copies of Windows to be eligible for service pack updates and other patches. They have slipped various anti-piracy checks into their update process under the moniker Windows Genuine Advantage, which means only legitimate copies of Windows have access to the collection of updates. But even if the software vendor doesn't implement technical restrictions to prevent pirated versions from updates, the user's conscience might still prevent it. A person who "borrows" a commercial software application from their friend is less likely to run to the vendor asking for support and updates, because they do not want to get their friend in trouble for handing out pirated copies; so such people are more likely to disable anything that automatically alerts the vendor to the second copy, and/or will ignore any updates (where they might be asked how they got the software in the first place) and just stick with the original (now outdated and insecure) version.
Overall this whole timely security patching business is a tough problem to solve, because it's not simply just a matter of expecting users to download an installation file off a website and double-clicking it.
Until next time,
- Jeff
Showing posts with label patches. Show all posts
Showing posts with label patches. Show all posts
Monday, June 15, 2009
Friday, March 13, 2009
Patch to Get Some New Holes
According to many news outlets (but interestingly, not Panda Labs' blog, which most of the reports cite), a couple of days ago, Panda Labs said MS09-008 doesn't fix one of the vulnerabilities it set out to fix. This complaint may or may not be the same as the one from nCircle, in which the patch installs differently and does not provide future protection if the vulnerability has already been exploited (calling this behavior an incomplete fix seems pretty reasonable to me). There's a whoops or two in here somewhere, be it an unsuccessful fix from Microsoft, Panda publicly disclosing a vulnerability without giving the vendor time to provide a patch, news outlets propagating a bogus story, Panda not posting anything to back up their claim, or my inability to find the actual data Panda posted. Conveniently, I don't need the details to ramble on about patches & security in general: whether this patch in particular had problems or not, security patches have holes, too.
Why is that?
To start with, many security issues are correctness issues. What applies to software in general also applies to security patches: writing bug-free code is hard to the point of impossible (depending on whether you're talking to a formal methods geek). To approximate it, one typically needs extreme attention to detail; very good knowledge of the surrounding code, intended architecture, and behavior of surrounding systems; a full coverage test suite; a good development process; and enough time to carefully design, code and test the software in question. As you can see from this simplified view, there will be quite a lot of work involved. There will be correctness issues in software, including security patches, and some of these correctness issues will cause security problems.
For security issues that go beyond correctness issues, you can take the above list of stuff you need to write high-quality code and increase the existing knowledge, test & time requirements substantially, and add knowledge about the specific security issues; security issues that go beyond correctness are usually more complicated to understand and reproduce than "simple" correctness issues. Complicated tends to mean more bugs, and some of the bugs will be security issues.
Now let's add in the fact that it's a patch.
Even if you only maintain one supported version (i.e. you work for a SaaS ;) ), you're not going to work on that supported version every day. You're mostly going to work on some future release. Chances are good that you have unconscious expectations about what features are available to you, and how the surrounding code acts, based on the code you work with regularly. Quite a lot of this may be new since the supported release, but since your assumptions about its presence are unconscious, you probably don't have a complete list of new features in mind and you may not think to ask yourself whether what you are doing will always work safely given that X is not present. The wider the gap between the supported version & what you're working on now, the more likely you are to slip up in this way.
If you have multiple supported versions, you get to repeat the above for every supported version. And it gets worse: again, unless you work for a SaaS, you have to cover the possibility that not all your previously published patches (security or not) have been installed. Your fix needs to work whatever the patch state, for all your supported versions, which means you have to think it through and test for each supported version & possible patch state.
For most developers, adding new features is way more fun than writing patches. You probably can't wait to get back to whatever you were working on when somebody reported this bug.
And for a security patch?
Security is a specialty & mindset of its own, and it can be hard for non-security developers to understand the issue they're fixing as deeply as they would understand a correctness issue.
There is extra pressure to get a security patch out fast. Distracted people in a hurry make more mistakes.
Typically, a security patch will reduce functionality. Backwards compatibility is a big issue: customers hardly ever want you to take something away. Ideally, you would remove the functionality the attacker can use without affecting the functionality legitimate users use, but this isn't always possible, and then you have some really tricky decisions to make.
Because of all these factors, you can expect security patches to have holes now & then. Sometimes they'll be the same holes, not yet fixed, and sometimes they'll be shiny and different. Personally, I feel the same way as most of the security administrators I know: I'll take the new hole over the old hole every time, and keep on patching as quick as I can.
--Brenda
(Yes, this counts as more fuel for the give-me-an-interim-patch-while-you-do-all-that-work fire.)
Why is that?
To start with, many security issues are correctness issues. What applies to software in general also applies to security patches: writing bug-free code is hard to the point of impossible (depending on whether you're talking to a formal methods geek). To approximate it, one typically needs extreme attention to detail; very good knowledge of the surrounding code, intended architecture, and behavior of surrounding systems; a full coverage test suite; a good development process; and enough time to carefully design, code and test the software in question. As you can see from this simplified view, there will be quite a lot of work involved. There will be correctness issues in software, including security patches, and some of these correctness issues will cause security problems.
For security issues that go beyond correctness issues, you can take the above list of stuff you need to write high-quality code and increase the existing knowledge, test & time requirements substantially, and add knowledge about the specific security issues; security issues that go beyond correctness are usually more complicated to understand and reproduce than "simple" correctness issues. Complicated tends to mean more bugs, and some of the bugs will be security issues.
Now let's add in the fact that it's a patch.
Even if you only maintain one supported version (i.e. you work for a SaaS ;) ), you're not going to work on that supported version every day. You're mostly going to work on some future release. Chances are good that you have unconscious expectations about what features are available to you, and how the surrounding code acts, based on the code you work with regularly. Quite a lot of this may be new since the supported release, but since your assumptions about its presence are unconscious, you probably don't have a complete list of new features in mind and you may not think to ask yourself whether what you are doing will always work safely given that X is not present. The wider the gap between the supported version & what you're working on now, the more likely you are to slip up in this way.
If you have multiple supported versions, you get to repeat the above for every supported version. And it gets worse: again, unless you work for a SaaS, you have to cover the possibility that not all your previously published patches (security or not) have been installed. Your fix needs to work whatever the patch state, for all your supported versions, which means you have to think it through and test for each supported version & possible patch state.
For most developers, adding new features is way more fun than writing patches. You probably can't wait to get back to whatever you were working on when somebody reported this bug.
And for a security patch?
Security is a specialty & mindset of its own, and it can be hard for non-security developers to understand the issue they're fixing as deeply as they would understand a correctness issue.
There is extra pressure to get a security patch out fast. Distracted people in a hurry make more mistakes.
Typically, a security patch will reduce functionality. Backwards compatibility is a big issue: customers hardly ever want you to take something away. Ideally, you would remove the functionality the attacker can use without affecting the functionality legitimate users use, but this isn't always possible, and then you have some really tricky decisions to make.
Because of all these factors, you can expect security patches to have holes now & then. Sometimes they'll be the same holes, not yet fixed, and sometimes they'll be shiny and different. Personally, I feel the same way as most of the security administrators I know: I'll take the new hole over the old hole every time, and keep on patching as quick as I can.
--Brenda
(Yes, this counts as more fuel for the give-me-an-interim-patch-while-you-do-all-that-work fire.)
Subscribe to:
Posts (Atom)
Posts
