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.
Simon.
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
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.)
Slashdot Mirror
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.
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
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.)