Huh? I though they already did this. I got an email from MS with an attachment that promised to patch all security issues:).
I don't think you'll get an argument from MS
by
Anonymous Coward
·
· Score: 5, Funny
Any slower and Microsoft would just start shipping exploits instead of patches.
Re:I don't think you'll get an argument from MS
by
Jason+Straight
·
· Score: 4, Funny
They already do!
Re:I don't think you'll get an argument from MS
by
pegr
·
· Score: 4, Insightful
Any slower and Microsoft would just start shipping exploits instead of patches.
This is essentially the point of the author...
"They [hackers] wait until the patch for the vulnerability is released, then they reverse-engineer the patch. This is orders of magnitude easier than finding the vulnerability directly."
I believe this idea is flawed. A general description may give a would-be "zero-day hax0r" a place to look, but patches are distributed not as patches to individual files (e.g. diffs) but as whole file replacements.
To further reflect the sophistication of the author, he also spews this gem:
"An exploit is a method devised to take advantage of a specific software vulnerability using a software virus, Trojan horse or worm. When the exploit is done without a virus, Trojan or worm, it's using an undocumented feature."
Conclusion? This guy is a putz...
Re:I don't think you'll get an argument from MS
by
_xeno_
·
· Score: 5, Interesting
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.
-- You are in a maze of twisty little relative jumps, all alike.
Like Microsoft is doing?
by
JPriest
·
· Score: 4, Insightful
Everyone already decided this was a bad idea when Microsoft starting doing it. We can't change our minds and copy them because we all know Microsoft does not Innovate.
-- Saying Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders.
I want it fixed ASAP
by
Gr33nNight
·
· Score: 4, Insightful
I dont know about everyone else, but if a bug or security hole is found, I want a patch for it ASAP, and not in 2 months when the next 'service pack' or whatever comes out.
I dont think the issue has to do with patches coming out all the time, but having a better way to install said patches. Lets just say I am really looking forward to Novells Zenworks Patch Management solution.
Re:I want it fixed ASAP
by
cK-Gunslinger
·
· Score: 4, Insightful
But that's part of the problem (according to the article.) When a software company releases a patch, it's not just the customers who receive it, but all the virus/worm writers. If they can reverse-engineer the patch and come up with an exploit faster than it takes for *all* the customers to apply the patch, they win. And trust me, they will *always* beat the masses, as long as there are people out there who seldom/never patch their systems.
Perhaps all software patches should be about 1GB in size, mostly consisting of random crap, with the little patch embedded deep inside.;)
Re:I want it fixed ASAP
by
Xentax
·
· Score: 4, Insightful
The article author suggests that the patch be distributed in an encrypted form, and then on a specified date, the key gets sent and everyone patches simultaneously.
Though if he really thinks that a patch in this form would be significantly harder to crack than a 'normal' patch, he's stretching.
Even if it was, the key would at least occasionally get leaked privately before it was publicly sent, and thus malware writers would have a field day.
All of that is also based on the assumption that exploit writers use the patch to reverse-engineer the vulnerability and exploit it. If this slower cycle he's proposing is too slow, there'll be plenty of "ne'er-do-wells" that will find vulnerabilities the old fashioned way. It's trading the current problem for yesterday's, not what I'd call a step in the right direction.
Working harder to make consumer machines and OSes able to intelligently patch themselves is a better solution. XPsp2 will switch Windows Update to "install by default" instead of "off by default", which will help there. Making it as transparent and yet as unobtrusive to Joe AverageComputerUser is, IMHO, the way to get the attack surface down from millions of machines to a few thousand or less.
The one thing I'll agree about as far as slowing the patch cycle down is that making sure any released patch DOES fix the problem and DOES NOT break other things in the process. Those are the kinds of arguments that various parties throw up when they're objecting to applying patches as soon as they're available (that's what was horribly badly wrong with the old NT service packs, for example -- they often broke applications and thus people would wait months or even stay a full service pack behind the latest version).
Xentax
-- You shouldn't verb words.
Re:I want it fixed ASAP
by
swordboy
·
· Score: 4, Insightful
I don't think that you are seeing the big picture.
Say, Microsoft finds a bug (either internally or via a good/trusted samaritan who will keep it private). Now, they go ahead and code up a patch for the bug but when do they release it?
Because the patch for blaster required Win2K SP2, many people were not able to protect themselves appropriately as SP2 is over 8 hours on a dial-up connection (more than half of the 'net). Now, if MS can get a "quarterly updates" on CD mailed to all of these people, then they can give everyone a better means of securing their boxen prior to letting the hackers pick apart the actual patch to find out what the hole is and how to exploit it (though blaster isn't a good example of a patch being reverse engineered into an exploit).
This is a HUGE dillemna for corporations. Especially those that have ooldes of laptops with users connecting via dial-up. I'm actually connected, as-we-speak (type?), to windowsupdate.com and have been for the past hour or so... ON BROADBAND...
What I would suggest is the best of both worlds - release patches only as exploits are found in the wild while compiling fixes for deployment en bulk. And you'd think that Microsoft, with billions in free cash, would start putting a bounty on some of this stuff (either reporting the holes themselves or the hackers that exploit them). It just shows how little Microsoft and Billy care about Joe User.
And how about some freakin' color schemes for XP? I mean, really... three whole color schemes?
--
Life is the leading cause of death in America.
Just more astroturf
by
Anonymous Coward
·
· Score: 5, Insightful
While it doesn't name any names, the gist of this article is exactly the same as when Microsoft said that exploits only come after patches are released. This is patent nonsense and we all know it; - every week there's a few stories about a new MS hole that's being exploited but that they refuse to (or cannot) fix. I wonder why such a vapid article was posted?
Patch release cycle
by
Ckwop
·
· Score: 5, Insightful
The problem with slowing down that patch release cycle is the software vendors get lazy. "I wont release this patch for 18 months because no-one knows the vulnerability"..
It's a difficult one. On the one hand you've got the problem of lazy vendors and on the other you've got full disclosure where the enemy will like develop the worm before you can test your patch properly.
I think the people that find these vulnerabilities should but an expire date on their vulnerability at which point full disclosure kicks in. There should be protections in law to ensure this practice is legal too.
That way.. we have motivated vendors and give the vendors enough time to fix the problem.
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).
But then how can vendors be 1337?
by
Rex+Code
·
· Score: 4, Insightful
The problem is that the standard for what constitutes a security hole has become (in some cases) ridiculously low. A few years ago, you'd have to have a demonstratable exploit to get a vendors attention. These days, someone notices an overflow, or an off-by-one error in the source code, and makes a post to full-disclosure or BugTraq, and next thing you know all the vendors have to patch it even if it doesn't pan out to have real security implications. On top of this, you've got the vendors themselves issuing advisories for low-level risk issues which forces the other vendors to issue advisories themselves.
After crying wolf so many times, it's no wonder advisories concerning critical security holes can get lost in the shuffle.
Quality not quantity
by
SkiddyRowe
·
· Score: 4, Insightful
Personally I'd rather see patches that won't open new vulnerabilities. Too many times we've seen these quick reflex fixes from Redmond, only to see that they release a patch for the patch. I'd rather patch the problem fully, than have a quick punch patch, that just gets exploited a week later.
in related news
by
jannesha
·
· Score: 5, Informative
There's new critical updates available on Windows Update (5 in all, for WinXP + IE 6SP1).
Greatest patch of all
by
cexshun
·
· Score: 5, Insightful
I think the greatest "fix all" patch would be to distribute a book with every PC sold titled "The Internet: How to not be an idiot".
I can't think of many email viruses out there that can exploit the ol' "Do not open unless I know what it is" bug!
Exploits are often hard to detect...
by
cheezit
·
· Score: 5, Insightful
This article is pretty interesting, but it is built on the assumption that vulnerabilities usually don't have exploits in the wild until the patch comes out. Sometimes that is true (as his examples show), sometimes it is not. The problem is showing the difference.
It is very difficult to establish what new exploits are being used in the wild. With the exception of viruses and worms (which have an analyzable payload), most exploits must be caught in the act to understand what they really are.
So if Company X has a vulnerability, they can: a) hold off on a patch since there is no exploit (as the article suggests), or b) patch right away, since there is an exploit in the wild
Option a saves Company X money....how hard will they look for an exploit?
-- Premature optimization is the root of all evil
Re:Do it right the first time...
by
negacao
·
· Score: 4, Insightful
It would also mean forcing more programers to do their jobs right,
Maybe if we were given some fucking time to do the job right......
It never says that.
by
oneiros27
·
· Score: 4, Insightful
You're just reading it in. It is however, stating that attacks seem to come rather quickly after patches are released.
Personally, I'd prefer if they didn't use valid scientific methods to prove if this is or isn't the case, if the result is network being saturated when the exploits finally hit, and manage to take out a significant number of hosts.
One of the key points that he didn't mention is that there was an attack about two years ago (sorry I can't be more specific, I was working on other projects at the time, as wasn't responsible for cleaning up after it where I worked), that one of the virus companies had a 'prefered customer' system, where they'd let certain customers know about virus outbreaks before the general public, and put out a press release that if you had been one of their clients, you'd have been protected from the virus outbreak. [I think it was one of the more hard hitting ones, too...like CodeRed, or at least near that time]
I would think that the issue that this article is talking about has absolutely nothing to do with speed -- it comes down to issues with the current procedures being exploitable, and needing to be fixed. He is simply giving a recommendation to fix the problem, which has a (not quite desired) side effect of longer times before systems are patched.
I would think that there's most likely some other solution out there that would have the desired end result (more difficult to reverse engineer the patches before the majority of users have patched their system), without creating some sort of intentional delay in the procedures. (and whoever comes up with it should probably patent it, to protect themselves and screw others, or should make sure to get it published, so it can be claimed as prior art before someone else patents it)
-- Build it, and they will come^Hplain.
Not about slowing down the cycle
by
merlin_jim
·
· Score: 5, Interesting
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.
-- I am disrespectful to dirt! Can you see that I am serious?!
Uninformed or just stupid ?
by
morcego
·
· Score: 5, Interesting
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.
--
morcego
yet again.
by
happyfrogcow
·
· Score: 4, Insightful
The article seems to be making yet another claim that security through obscurity is better. They say that the patch release contains enough information for an exploitation to be made immediately if there isn't one already:
The patch had the specific information embedded in it that the exploiters needed, and the exploiters already had the expertise and tools required to rapidly make use of the information.
Slowing it down won't do anything, and they jump to that conclusion at the last line. Slowing it down, will have the same effect of speeding it up. They used speeding it up as an example:
If the patch had been released a week earlier, the worm also would have come out a week earlier.
The same could be said if it were released a week later.
Slowing the quickness of release shouldn't be a factor, only implementation of distribution. If they can find and fix a problem *right now*, why wait 2 weeks to distribute it? I just don't get why they mention time as an issue, except as flamebait.
End users are in a dilemma, however, because the current method of deploying patches doesn't allow them enough time before an exploit based on reverse-engineering of the patch can be deployed.
The only dilema is that of the producers of software. How fast can we notify end users that a fix is available and if they don't install it, they will be vulnerable to some attack.
If someone understands why the article claims slowing down will benefit, please explain to me. This is pissing me off. It makes no sense. The only thing that makes sense is their statement about a "patch subscription system". But that is crying out "Pay for this service". So they want to make people pay to have quick security patches, the rest get slow patching? I don't get it. I give up trying.
It's like saying "hey, what i want to do makes no sense at all! therefore it HAS to be good, new, and innovative. So give us money!"
Not all right, but not all wrong either
by
emurphy42
·
· Score: 5, Insightful
Here's my analysis of some claims stated or implied in the article:
Some exploits are reverse-engineered insanely quickly from patches. (True, with an example cited.)
Slowing down patches will reduce the total severity of exploits. (Way too vague.)
Slowing down patches will delay the existence of exploits. (False; not all exploits are reverse-engineered from patches.)
Slowing down patches in a "Tuesdays only" fashion will make it easier for admins to check for patches on a predictable schedule, and install them soon after they're released. (True as far as it goes, but the reverse-engineers can also check for patches on a predictable schedule; this also totally ignores exploits that aren't reverse-engineered from a patch.)
Slowing down patches long enough to make sure they don't cause some other severe problem is a good idea. (True, but not mentioned in the article.)
Providing patches in an encrypted-but-usable form right away, and in a decrypted form later, will help admins keep ahead of reverse-engineers. (Obvious "this is anathema to OSS" aside, how would this actually work? Windows Update patches are already distributed in binary-only form, and they still get reverse-engineered.)
Managed-code languages like Java and C# will eliminate buffer overflows, which are a common source of exploits, but they're nowhere near universal. (Basically true, probably with numerous exceptions and caveats.)
An angle I haven't seen before
by
theLOUDroom
·
· Score: 4, Interesting
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.
Slashdot Mirror
We all know how well that works for MS Outlook.
Everyone already decided this was a bad idea when Microsoft starting doing it. We can't change our minds and copy them because we all know Microsoft does not Innovate.
Saying Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders.
I dont know about everyone else, but if a bug or security hole is found, I want a patch for it ASAP, and not in 2 months when the next 'service pack' or whatever comes out.
I dont think the issue has to do with patches coming out all the time, but having a better way to install said patches. Lets just say I am really looking forward to Novells Zenworks Patch Management solution.
While it doesn't name any names, the gist of this article is exactly the same as when Microsoft said that exploits only come after patches are released. This is patent nonsense and we all know it; - every week there's a few stories about a new MS hole that's being exploited but that they refuse to (or cannot) fix. I wonder why such a vapid article was posted?
The problem with slowing down that patch release cycle is the software vendors get lazy. "I wont release this patch for 18 months because no-one knows the vulnerability"..
It's a difficult one. On the one hand you've got the problem of lazy vendors and on the other you've got full disclosure where the enemy will like develop the worm before you can test your patch properly.
I think the people that find these vulnerabilities should but an expire date on their vulnerability at which point full disclosure kicks in. There should be protections in law to ensure this practice is legal too.
That way.. we have motivated vendors and give the vendors enough time to fix the problem.
Simon.
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).
The problem is that the standard for what constitutes a security hole has become (in some cases) ridiculously low. A few years ago, you'd have to have a demonstratable exploit to get a vendors attention. These days, someone notices an overflow, or an off-by-one error in the source code, and makes a post to full-disclosure or BugTraq, and next thing you know all the vendors have to patch it even if it doesn't pan out to have real security implications. On top of this, you've got the vendors themselves issuing advisories for low-level risk issues which forces the other vendors to issue advisories themselves.
After crying wolf so many times, it's no wonder advisories concerning critical security holes can get lost in the shuffle.
Personally I'd rather see patches that won't open new vulnerabilities. Too many times we've seen these quick reflex fixes from Redmond, only to see that they release a patch for the patch. I'd rather patch the problem fully, than have a quick punch patch, that just gets exploited a week later.
There's new critical updates available on Windows Update (5 in all, for WinXP + IE 6SP1).
I think the greatest "fix all" patch would be to distribute a book with every PC sold titled "The Internet: How to not be an idiot". I can't think of many email viruses out there that can exploit the ol' "Do not open unless I know what it is" bug!
This article is pretty interesting, but it is built on the assumption that vulnerabilities usually don't have exploits in the wild until the patch comes out. Sometimes that is true (as his examples show), sometimes it is not. The problem is showing the difference.
It is very difficult to establish what new exploits are being used in the wild. With the exception of viruses and worms (which have an analyzable payload), most exploits must be caught in the act to understand what they really are.
So if Company X has a vulnerability, they can:
a) hold off on a patch since there is no exploit (as the article suggests), or
b) patch right away, since there is an exploit in the wild
Option a saves Company X money....how hard will they look for an exploit?
Premature optimization is the root of all evil
It would also mean forcing more programers to do their jobs right,
Maybe if we were given some fucking time to do the job right......
You're just reading it in. It is however, stating that attacks seem to come rather quickly after patches are released.
Personally, I'd prefer if they didn't use valid scientific methods to prove if this is or isn't the case, if the result is network being saturated when the exploits finally hit, and manage to take out a significant number of hosts.
One of the key points that he didn't mention is that there was an attack about two years ago (sorry I can't be more specific, I was working on other projects at the time, as wasn't responsible for cleaning up after it where I worked), that one of the virus companies had a 'prefered customer' system, where they'd let certain customers know about virus outbreaks before the general public, and put out a press release that if you had been one of their clients, you'd have been protected from the virus outbreak. [I think it was one of the more hard hitting ones, too...like CodeRed, or at least near that time]
I would think that the issue that this article is talking about has absolutely nothing to do with speed -- it comes down to issues with the current procedures being exploitable, and needing to be fixed. He is simply giving a recommendation to fix the problem, which has a (not quite desired) side effect of longer times before systems are patched.
I would think that there's most likely some other solution out there that would have the desired end result (more difficult to reverse engineer the patches before the majority of users have patched their system), without creating some sort of intentional delay in the procedures. (and whoever comes up with it should probably patent it, to protect themselves and screw others, or should make sure to get it published, so it can be claimed as prior art before someone else patents it)
Build it, and they will come^Hplain.
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.
I am disrespectful to dirt! Can you see that I am serious?!
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.
morcego
The article seems to be making yet another claim that security through obscurity is better. They say that the patch release contains enough information for an exploitation to be made immediately if there isn't one already:
The patch had the specific information embedded in it that the exploiters needed, and the exploiters already had the expertise and tools required to rapidly make use of the information.
Slowing it down won't do anything, and they jump to that conclusion at the last line. Slowing it down, will have the same effect of speeding it up. They used speeding it up as an example:
If the patch had been released a week earlier, the worm also would have come out a week earlier.
The same could be said if it were released a week later.
Slowing the quickness of release shouldn't be a factor, only implementation of distribution. If they can find and fix a problem *right now*, why wait 2 weeks to distribute it? I just don't get why they mention time as an issue, except as flamebait.
End users are in a dilemma, however, because the current method of deploying patches doesn't allow them enough time before an exploit based on reverse-engineering of the patch can be deployed.
The only dilema is that of the producers of software. How fast can we notify end users that a fix is available and if they don't install it, they will be vulnerable to some attack.
If someone understands why the article claims slowing down will benefit, please explain to me. This is pissing me off. It makes no sense. The only thing that makes sense is their statement about a "patch subscription system". But that is crying out "Pay for this service". So they want to make people pay to have quick security patches, the rest get slow patching? I don't get it. I give up trying.
It's like saying "hey, what i want to do makes no sense at all! therefore it HAS to be good, new, and innovative. So give us money!"
Here's my analysis of some claims stated or implied in the article:
Some exploits are reverse-engineered insanely quickly from patches. (True, with an example cited.)
Slowing down patches will reduce the total severity of exploits. (Way too vague.)
Slowing down patches will delay the existence of exploits. (False; not all exploits are reverse-engineered from patches.)
Slowing down patches in a "Tuesdays only" fashion will make it easier for admins to check for patches on a predictable schedule, and install them soon after they're released. (True as far as it goes, but the reverse-engineers can also check for patches on a predictable schedule; this also totally ignores exploits that aren't reverse-engineered from a patch.)
Slowing down patches long enough to make sure they don't cause some other severe problem is a good idea. (True, but not mentioned in the article.)
Providing patches in an encrypted-but-usable form right away, and in a decrypted form later, will help admins keep ahead of reverse-engineers. (Obvious "this is anathema to OSS" aside, how would this actually work? Windows Update patches are already distributed in binary-only form, and they still get reverse-engineered.)
Managed-code languages like Java and C# will eliminate buffer overflows, which are a common source of exploits, but they're nowhere near universal. (Basically true, probably with numerous exceptions and caveats.)
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.
Life is too short to proofread.