to patch or not to patch: an edge case

i find myself in a rather odd predicament today. i've been using an older computer (we'll call it one of my secondary computers since it get very little use compared to the one i'm writing this with right now) and i got a pop-up notification that i was running out of space on drive C:.

now i want to put this in context; this computer sees very little use, mostly it gets turn on, has some files transferred to it or from it, and then switched off. i can't remember the last time i actually installed anything on it (for that matter, since i've switched over to using portable software, i can't recall the last time i installed anything on my primary system either) so let's say it's been a really, really long time since i touched the C: drive at all. mostly it's the larger secondary physical disk that gets used.

so you can imagine my surprise when the notification about running low on space popped up. was there something malicious going on? had the system been compromised? no, it was in the process of applying system updates. patches had actually eaten up the majority of my free space - the WINDOWS directory was taking up over 7 gigs of my 10 gig drive. i'm actually in the position where i have to uninstall software so that the patching will succeed.

now, this is an XP system so one might reasonably suggest that i upgrade to the latest version of windows so that i can avoid having all those patches on my system. unfortunately, this system is so old, i doubt it will meet the system requirements of anything newer than XP.

one might also, entirely reasonably, suggest upgrading the harddisk to something larger. memory is cheap, after all. it's a little difficult to justify upgrading the drive just to accommodate microsoft's attempts to fix their earlier mistakes, though. it's certainly not like i'm going to get any additional benefit from greater space on a drive i never make use of.

one could even go so far as to suggest upgrading all the things so that not only would i be able to move to the latest version of windows, i could have more space and a snappier system that is more amenable to being used day to day. but i already have a computer that's more amenable to being used, so really everything that was wrong with the idea of upgrading the drive is also wrong with this plan, in spades.

it's times like this that make one question things we normally take for granted, like why does it patching take so much space? is the fixed binary that much larger than the one with the error in it? no, that doesn't appear to be what's going on. it appears that windows keeps a bunch of stuff around so that you can uninstall the patch if you want to. does anyone ever actually do that? there may be a way to reclaim the space those uninstall files take up, but it's not obvious just by looking at the system, and right now simply letting the updates happen the way an ordinary user would is actually reducing the utility of the system.

thankfully the utility that's been lost wasn't really needed anymore. but what about next time? support for XP is ending, but it's not over yet, there are still more patches coming. i'm going to be facing the prospect of no longer getting patches anyway, so i might as well get used to it early - and since the system is little more than a network attached storage device that spends most of it's time powered off, i can't really see the harm.

in security, we normally think of applying patches as a no-brainer. it may present some logistical hurdles in the enterprise, but it still needs to get done. sometimes, though, there are cases where it just doesn't pay off. no practice is so universally beneficial that it should be mindlessly applied 100% of the time.

the stupidity of exploit wednesday

exploit wednesday is the day after patch tuesday, so named because apparently exploits get released on that day supposedly so as to maximize the length of time the exploit can be used against systems...

but who says the day after patch tuesday is the best day to release exploits? does it really maximize the window of exposure? if an exploit were released one day earlier (ie. the same day as patch tuesday) would there really be time for microsoft to create and test a patch to be included in patch tuesday? how about 2 days earlier (as in today, the day before patch tuesday)? how about 3?

if we look at history, what is the shortest time microsoft has ever needed for researching, addressing, testing, and deploying a patch? an exploit should be releasable before patch tuesday so long as there isn't enough time for the patch to be included... right now there are currently 2 unpatched microsoft word vulnerabilities (one of which has been known about for a week or more) with exploits being used in the wild and they aren't getting included in tomorrow's patch roll-out because there wasn't time to go through the extensive development and testing process that microsoft puts patches through before deploying them...

if the exploit is serious enough to warrant an out of cycle patch then it doesn't matter when you release it because you won't be able to manipulate the size of the window of exposure through timing the release... otherwise the maximum window of exposure is achieved by releasing {minimum microsoft patch time} - 1 days before patch tuesday...

if the bad guys who make and sell the exploits don't know this yet then they're morons... if the bad guys who buy the exploits haven't figured this out yet and agree to an exploit wednesday release date then they're also morons... if the good guys are expecting the bad guys not to figure this out, if they genuinely don't expect to see many exploits until exploit wednesday then they are naive and they're eventually going to get caught with their pants down...

ZERT's 3rd party VML patch

ZERT, short for zero-day emergency response team, have released a patch for the microsoft VML vulnerability that has been recently uncovered and exploited...

there have been 3rd party patches in the past (the WMF one being a prime example) but the significance here is that an organization has formed (with an impressive set of members) specifically for the purpose of releasing 3rd party patches to vulnerabilities that are exploited before a patch is available from the vulnerable software's vendor...

i've mentioned 3rd party patches before and why they're needed (because certain vendors don't do enough to shut the window of exposure quickly enough)... i thought they were a good idea and i think they're an even better idea now... rumor has it that microsoft may release a patch for the VML vulnerability out of cycle (before the 2nd tuesday of next month) but this rumor only seems to have surfaced after ZERT released their 3rd party patch... furthermore, another rumor has it that microsoft was/is considering releasing an early patch for their onecare customers (which just goes to show what i said before about their being no moral high ground for microsoft in the security industry is proving moot because they clearly have no interest in the moral high ground)... i have no idea if the 2 rumors are related, but regardless of that it seems to me that 3rd party patches may serve to help keep microsoft honest in a way that full disclosure was supposed to do...

i can't mention ZERT's VML patch without drawing attention to what randy abrams has written about it, though... in spite of being a member of ZERT, he wisely posts words of caution over the use of their 3rd party patch that basically boil down to this: most people don't need or use VML in the first place and so the existing workaround of disabling it is a better option than the 3rd party patch under those circumstances - you should only need the 3rd party patch if you really need the vector graphics (not just regular graphics, mind you) rendering engine to operate, and then you should only need the 3rd party patch until the vendor releases their own patch... that's good advice and i think it can probably be applied to 3rd party patches in general, not just this one...

linus torvalds is not a villian

linux creator linus torvalds recently fixed a bug in the linux kernel that was revealed by the failure of the new cross-platform virus to operate properly on newer versions of the linux kernel...

but some folks, like the normally bright eddy willems, take offense to this... they seem to be thinking that mr. torvalds made the patch so that the virus would operate - that's a ridiculous notion...

there was a BUG in the OS... linux was not operating the way it was supposed to... i don't care if it was a virus or satan himself who revealed the fact, the kernel needed to be fixed... sure fixing the OS so that it behaves as intended helps the virus operate - making sure the OS behaves as intended has the potential to help ALL software for that platform...

unbelievable and unforgivable? hardly... i'd reserve those terms to someone who'd keep their OS broken just to spite a particular proof of concept virus... talk about cutting off your nose in spite of your face... i think some folks are missing some perspective here...

i'll grant you that mr. torvalds is a little off on his understanding of what viruses are if he thinks this thing isn't a virus, but fixing the OS was still the right thing to do...

why microsoft hates 3rd party patches

it's not exactly news anymore, but it's happened again - a bug has cropped up in microsoft's software that is so serious that outside parties have been forced to create patches for it due to microsoft's glacial pace...

microsoft doesn't like this, it doesn't like this one bit... it makes them look like chumps... here they are with full access to the source code, tens of thousands of developers, and billions of dollars to throw around and some guy at some security firm somewhere makes a patch faster than they can? they do not want these kinds of comparisons to happen, they do not want people to see what kind of performance the microsoft security machine is really giving them...

one of the things they say is that only microsoft patches are guaranteed to work with everything... they have all these tests they need to perform to make sure they don't break anything and comparing their process to what 3rd party patchers do just isn't fair... problem is, not only are microsoft's patches NOT guaranteed (there have been multiple instances where their patches inadvertently broke things) but it also underlines the fact that compatibility rather than security is their first priority... and this comes from a program manager at microsoft's security response center....

microsoft's security efforts are a failure, a farce, and the public has lost confidence in them... and not just a little bit of confidence either; the WMF incident back in december and now the new IE vulnerability just a few months later, both with wide adoption of 3rd party patches, indicates that this is a watershed event... confidence in microsoft's security efforts has crossed a threshold...

the worst thing, for microsoft at least, is that they're losing control over a captive market... 3rd party patches open the door for competition for their paid support program(s), as well as eat away at the leverage they have for getting people to upgrade by ending support for older versions of their products... ending support has a lot less meaning when other people are willing to pick up the slack...

microsoft talks a good game about security, i saw one of them talk about it at RSA2002, they go to great lengths, but they seriously underestimate the significance of risk when they leave the window of exposure open as long as they do while trying to make the perfect patch... when there's a serious exploit in the wild there should be no question of whether or not to release a patch out of cycle, it should be released as soon as it's made and refined and updated after the fact... so long as a seasoned expert at writing secure code is making the patch (rather than some green code monkey they're trying to train), any problems that might arise from a rushed patch are almost certainly going to be less severe than than the one it's supposed to fix... further, new vulnerabilities from a rushed patch would require additional time and effort from the attacker community to exploit so as long as the development of the patch continues after the initial release so that updates to the patch can be pushed out if needed...