Slow Down the Security Patch Cycle?

Ant writes "Computerworld has an editorial article about slowing down, not speeding up, patch releases."

Comments

Speaking of astroturf

[October_30th]

every week there's a few stories about a new MS hole

As opposed to the endless list of problems with free software?

Re:Speaking of astroturf

[the_mad_poster]

Ah yes. The old "Let's compare the security of programs that Microsoft makes against every hackjob program out there under the GPL or BSD license that might be exploited across a good dozen distributions."

While we're at it, lets fail to consider that there's no such thing as an exploit-free system that still does something useful, and let's not consider the other critical part of security: response and patch times.

In other news, there are a lot more apples in the world than oranges when you compare every apple in the world against the oranges in Utah.

Wouldn't be a bad thing

[The Desert Palooka]

Besides absolutely critical patches (for worms, and exploits in the wild and the like) I think this could be a really good thing. I know when I was a network administrator it was nigh impossible to keep up with all the patches on my linux boxen. If all patches were released like movies and music, on Tuesdays only. It would have been easier. Come into work every tuesday read what patches I need to install...

Either that or like one poster suggested, we just need better tools for keeping track and managing the flow of updates... Strangely enough, MS's XP update does a really good job at this (despite their slow release process).

Re:Yes.

[Frymaster]

We all know how well that works for MS Outlook.

the obvious solution is to distribute patches via an outlook virus. it seems to be the only distro method that's guarnteed to work.

Patches in the near future-

[TJ_Phazerhacki]

Although I believe it is important to focus more on creating a good product out of the door - Dev's take note, buggy releases are more of a headache to fix than to do it right the first time - I feel that in specific instances - online games, optimized databases, web-related code, it is vital that patches are up to current asap. In a game, a bug will be exploited thousands of times before it can be patched (especially larger MMORPG's), and it is only fair that Mission critical software have the latest fixes (although newer should mean better, not just more complicated!) All I'm saying is that it may not be vital that the latest 10-year-old-driver error fix be released as a complete upgrade, requiring downloading of massive files and lengthy installs. PS - While on the subject, is it that difficult to write programs that only change the affected code? Why must we continue to run complete file changes? A simple program that fixes the code is sufficient, and we get a massive chunck of data, most of which is repetitive. Sorry, some of us have broadband, but some of them don't. And even a couple of megs gets to be a big issue.

Will they make us pay?

[obsoletemind]

If they release Patches further apart from each other, possbibly then on cds, will we have to pay for them as there will, i would presume, be a lot of data on these cds. Would you want that?

Hrm

[ReciprocityProject]

For example, the patch for the SQL Slammer worm was released six months before the exploit was launched. This long delay enabled blame to be placed on lax systems administrators for not properly patching system

What are you talking about, "enabled?" It is their fault for not properly patching the system.

Ultimately, more systems will be developed using managed code (for example, Java and C#). This will narrow the problem to the bootstrap code those systems rely on without every application developer needing to be hypervigilant about buffer overflows.

That only makes sense if you think buffer overflows are the only security risk. Using Java doesn't magically make programs secure. In fact, a lot of damage can be done even when you don't have the ability to run arbitrary code on a remote machine.

Lastly, and most importantly, once the patch was released, the exploit was released the very next day. This wasn't a coincidence where the exploiters just missed having a zero-day exploit. If the patch had been released a week earlier, the worm also would have come out a week earlier.

So it doesn't matter in the slightest how often you release patches, exploiters will exploit them. Nothing in the article explains how delaying a patch release will make the system more secure.

[To make the system more secure] . . . software owners would subscribe to an automated patch service. . . . Subscribers would receive a predeployed, encrypted version of the patch.

That entire statement sums the entirety of the useful information in this article. Erase the whole thing and leave that statement. (I'm mean. Sorry.)

Not about slowing down the cycle

[merlin_jim]

This article is not advocating slowing down the security patch cycle; the slashdot title is misleading... the author is advocating slowing down the security patch distribution method.

He makes the point that as soon as a patch is available, it is reverse engineered and exploited. He is advocating sending out encrypted versions of a patch, get everyone who is always-connected to the internet to automatically download the encrypted version, and once the downloads per second curve decreases by a certain amount (say 95% or so), then you send out the decryption key. Everyone installs the patch simultaneously; and zero-day exploits have as targets only those systems that do not subscribe to the patch service, and use traditional methods to procure patches.

This is based on the assumption that zero-day exploits reverse engineer patches. I have found this not to be the case; they usually just exploit the vendor description of the vulnerability; in many cases, this description is posted to a security mailing list a few days (or weeks depending on the vendor) before a patch is available; usually this is the method by which a vendor finds a vulnerability.

This process is right and proper as it gives the vendor a huge incentive to correct flaws quickly; many people who discover a vulnerability report it to the vendor, wait for it to be fixed, and then when a fix is not apparent, report it to the community to give the vendor a sense of urgency. Unfortunately, it is a necessary part of the security patch cycle; without it, we would have a priviledged few individuals who could write truly devastating worms and virii, for which the vendor may not even be working on a patch.

SQL Slammer was bad. But imagine it if Microsoft had no intention of correcting the vulnerability at the time it hit. How many more people would it have hit, considering that a significant portion of Microsoft's customers had already patched at that point? How long would it take Microsoft to issue a patch? How would they distribute it with so much of the internet simply unavailable? How long until our infrastructure approached something like normalcy?

That's what could happen in a world where public forums don't hold vendors accountable for fixing vulnerabilities. And that's exactly the kind of world necessary for it to make sense to slow down your patch distribution.

Re:Do it right the first time...

[PoesRaven]

and im telling you your crazy the highest levels of software quality control are in terms of bugs per so many lines even important life critical software used by the military and government institutions has bugs -- 1 bug per many thousands of lines, after spending millions of dollars auditing it you can keep bugs to a minimum, but you cant get rid of them from any project of real size

Re:Do it right the first time...

[Mateito]

> no matter what you do, your code will have bugs.

True, but there are steps you can take to minimize bugs. There are ways to check programs for out-of-bounds conditions. There are ways of fixing exploits relatively quickly. (And I mean weeks instead of months). There are ways of releasing "work arounds" instead of fixes.

True, the above may no produce the fastest code, but shit.. we are talking about Windows here. You want it to run faster? Buy a bigger computer.

Uninformed or just stupid ?

[morcego]

The degree of ignorance demonstrated on this article almost left me speachless. Not only the logic, but the data he uses is so flawed, that I should be laughting hard right now, except for the possible consequences of the article.

Just because a Worm was released right after the patch was released, it mean that they used the patch to create the exploit ? That is simply being obtuse.

Real cracker (or whatever you like to call them) are not there to make their name. They are out there to make a profit. Simple as that. Those are the guys with real motivation (and I mean money) to explore all possibilities. I do agree that the kids that make the worms to became famous among their 13371 frieds won't spend days working on disassemble code, but you can be very sure someone willing to compromise an specific target (a bank, or a given company) will do that. Add a little social engeneering to the mix, and things get real ugly.

Usually, worms are released after the patch. True. That is usually when the so called "zero-day" exploit becames useless, or nearly so. Also, releasing a worm is a good way to divert the attention from the other bug the cracker will be exploiting. Believe me, I have seen companies with 400+ employess come nearly to a halt due to patch deployment after a new worm shows up.

So, slowing down patch releases will slow down new worms ? At first glance, yes. It will also multiply the number of active worms on the wild, and allow the bad-bad-bad guys to keep making money, and cause real trouble, the kind of trouble take can take a company out of the market.

Re:I want it fixed ASAP

[magead7]

Just slowing it down by itself won't help. If the patches were all listed at some very convenient central location and everyone knew that the first of the month was patch day, maybe people would remember to patch. If it were some set day, each OS could pop up a little message saying to go get all of this month's patches. Additionally, if the patch schedule is random like it is now, then the exploiters are much more likely to hear about the patch than the average computer user. Having a set day might eliminate that advantage, assuming users do go get the patches on the right day.

Slowing patches doesn't work

[dre23]

This guy doesn't even know the meaning of zero-day. Zero-day means that the programming bug has existed since the software was written. That means that if you discover a bug in Linux 2.6.x kernel, that bug has been around since the Minix days! It has nothing to do with being "elite" -- that's all the kiddie mumbo-jumbo.

Security "experts" (have you ever met any? oh really?) are confusing topics here. This is the same argument I've seen time and time again in the security world. Here are a few examples:
1) chroot environments
2) stack protectors

In the case of chroot environments, people were wanting to protect 99.9% of remote attacks because "kiddies" used remote buffer overflows as the primary method of breaking into computers. What happened? Somebody figured out ways of breaking out of chroot environments. It wasn't difficult. Now, kiddies and damn near everyone can read about how to break out of chroot environments. They don't protect anything when the technique/knowledge of how to break them is so widely available.

In the case of stack protectors, people again wanted to protect against 99.9% of the attacks. In this example, it's more clear because new attacks became available because of the protection methods. Buffer overflows were 99.9% of the attacks back in the day. When stack protectors started popping on the scene, tons of papers and research went into heap overflows, format string holes, shared library injection, et al. Now, buffer overflows represent maybe 60-80% of the exploits out there. Since the other methods are now well-known, stack protectors are not anywhere near full-proof, and becoming less so by the day.

Exploits are found in the wild. Anyone with ASM or C knowledge can find them, however some attacks require different ways of thinking and different coded implementations. There are many attacks against HTTP, for example, that require no knowledge of ASM or C. Anyone with the desire to find an exploit in almost any computer PROGRAM or line of code (and how many lines of code are there?).... will find one. Give a person a 6-pack of jolt and a box of Cap'N Crunch cereal, and that person will break code for fun or for profit.

Slowing down patches just makes the real hacker's results worth more. And software bugs (which what security holes are) can cause mass hysteria and even human death. Why delay a patch to a fix that could cause events such as historical software-related disasters? I see delaying patches as Armageddon. Who's with me on this?

There are two type of patch management

[Anonymous Coward]

I believe that there are two ways that patches should be managed. If an exploit is already available, the patch should be immediate -- what is there to wait for? If an exploit is not available, a patch should be released at the end of the month, say.

However, if you have just discovered a vulnerability in your software, odds are some black hat hasn't just coincidentally discovered the same thing, so releasing a patch immediately is not likely buy you much security. Anyway, releasing a single patch when a bug is found is not a problem. What gets to be a problem is when 10 bugs are discovered in a given month, and people need to patch 10 times. This creates 10 times as many opportunities for somebody to exposed to an exploit because they didn't have a chance to have their system patched. Also, there is no predictability, so a good admin has to constantly poll for patches! If there was a predictable schedule (say, the first Wednesday of every month at noon), a good admin could plan for it, even arrange vacations around such a time.

Additionally, the author has an excellent point. Many exploits are derived from the patches themselves, so by delaying patches until a predictable time, vendors are actually delaying exploits until users are more likely to have their systems patched!

aQazaQa

Job Security

[devobelisk]

I don't know about you guys, but without exploits I would be out of a job. There would be no need for administration or security. So.. bravo Microsoft, keep up the good work. /me golf claps

An angle I haven't seen before

[theLOUDroom]

While reading the responses to this article I came across an idea that hadn't struck me before:

What if the reason some of these exploits aren't happening until the patch has been released is because the blackhats are being careful not to break into systems that belong to clueful users (tm)?

The reasoning would be: -I want to break into a computer
-I don't want to get busted
-I want to make sure whoever I break into isn't going to bust me
-I'll pick a computer that obviously isn't having much attention payed to it -If a system isn't getting patched, it probably isn't being checked for intrusions either.


Now I'm not saying that it accounts for the majority of cases, but it is interesting to consider.

Remote buffer overflows or ????

[dre23]

Remote buffer overflows are not as big as many people say they are.

Computer systems are more likely to get compromised in the following two ways:

1) Poor choice of passwords. This is a vendor implementation problem. Computers and programs should not allow people to choose bad passwords. There should NOT be a setting to make this optional. If passwords aren't secure, why require them in the first place?
2) Exploiting a trust relationship of some kind. This is generally a protocol design problem, that quickly becomes a vendor implementation problem once found. If Microsoft stopped using old protocol/security technology to share files, print things, and authenticate users -- and adopted a SANE model where ports weren't open and available for the whole world to take over -- then we wouldn't have the remote buffer overflows, worms, or any of the big problems we have today in the security world. Patch management would mean "new features, less bugs" and not "save my computer from the worm of the week".

Stop Releasing Patches

[caffeinebill]

Clearly, if it is better to slow down the release of patches, it would be best to NEVER release a patch. That way, there is nothing to "reverse-engineer" and there is no way the "exploiters" will have nothing to work with. Better yet, don't even release the software in the first place, and no exploit will ever be found, even for the less lazy, more sophisticated exploiters who find bugs in the original code!!!

Re:I want it fixed ASAP

[rgmoore]

What the author is proposing is that patches need to be distributed in two stages. First the distributor would pass out the patch itself, but with the wrinkle that it would be encrypted. The decryption key would only be released after a delay calculated to give people enough time to learn about the problem and download the patch.

The theory is that this gives the good guys an advantage in the information race. The distributor can give users plenty of time to find out about the patch and download it while still not providing the malware writers any usable information. When the decryption key is finally released, everyone should be able to download it in short order- the key itself is likely to be smaller than the network overhead it takes to transport it- and be done patching well before even a fast coder can understand the patch and turn it into a workable exploit.

There are still some obvious problems, of course. It won't work with the common Free Software development model, since the patches will still be visible. It also won't work for users who want to test a patch before trying it out on their production systems. It also depends on warnings about the vulnerability remaining vague enough that malware authors can't derive useful information from the warning. It may not be possible to find a vulnerability just because you know it's somewhere in a very large program, but once you know that it's localized in a particular subsystem there may be enough info to find it yourself.

Re:This will tick off C++ programmers but...

[Anonymous Coward]

Buffer overruns in Pascal are very unlikely. That is its strength.

People mod down what they do not understand.

Re:I don't think you'll get an argument from MS

[_xeno_]

but patches are distributed not as patches to individual files (e.g. diffs) but as whole file replacements.

You are aware that with a complete copy of the original directories, even with "whole file replacements," you're now just one step away from getting a diff?

Although I still think patches should be released as soon as possible because even if they do help "crackers" (or whatever we're calling them today) find exploits, there are still very intelligent black hats who will eventually find the exploit and start spreading it around. Patching it faster may mean more exploits sooner, but it also means that people can patch against the flaw without waiting for some black hat to make the entire point moot.

Re:Do it right the first time...

[Minna Kirai]

Have you ever written military software? I have.

So have I. And while I agree that it's theoretically possible to write bug-free software (for a sufficiently small program), even sky-high military budgets can't afford that level of redundant effort. (By quantum physics, nothing is truely impossible. But some things are hard enough to be practically impossible)

The V-22? Lethal software bugs. The FA-22? Software crash every 2 hours.

Funny how those nukes don't go off by accident isn't it?

Just because you haven't observed any catastrophic bugs is no proof that bugs don't exist.

Serious bugs can be prevented if you just want to make the effort.

If you're now talking about "serious bugs" instead of "bugs" in general, then you've backed away from the stronger assertions made earlier.

But it can be done, and is done all the time in some industries.

Which industries, exactly? Aerospace and military software certainly isn't bug-free! They often try, but even they make publicized mistakes (and the majority of bugs found post-fielding are kept quiet for security).

OpenSSH tried this once

[kasperd]

One time (a few years ago, I don't remember exactly when) a flaw was discovered in OpenSSH. It was anounced that a bug had been found, and that a patch would be released one week later, such that every distributor could release them at the same time and administrators would be prepared to install them. That aproach was very similar to what this article describes. (Yes I actually read it)

It was a complete failure. It lead to some of the worst criticism the project had ever experienced. And they ended up releasing the patch earlier than announced, not because of the criticism, but because exploit code was being written despite of the patch not being made generally available.