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.
Re:Like Microsoft is doing?
by
Kenja
·
· Score: 3, Insightful
This all just lends credence to my theory that the best way for Microsoft to kill Linux is for them to adopt it. Nothing would make the Linux Zealots jump ship faster. Within days we'd be hearing about how much Linux sucks and how BSD or some other OS is the "One True Operating System".
--
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
Re:Like Microsoft is doing?
by
Anonymous Coward
·
· Score: 1, Insightful
Knowing your hardware is the first step, you need to learn how your hardware works with Linux...hitting "Next" all the way through doesn't work like it does in Windows, you need to answer some questions first
Re:Like Microsoft is doing?
by
Idarubicin
·
· Score: 2, Insightful
This all just lends credence to my theory that the best way for Microsoft to kill Linux is for them to adopt it. Nothing would make the Linux Zealots jump ship faster.
Actually, I'm pretty sure that most of the zealots would just be crowing about how "we won!" Microsoft distributing an operating system for which they are license-bound to also distribute the code? No hidden hooks for their own products? Bill Gates bowing down before the Altar of Linus?
The zealots would be thrilled.
-- ~Idarubicin
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
mapMonkey
·
· Score: 2, Insightful
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.
So, how does waiting longer to release the patch change that situation at all?
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
Anonymous Coward
·
· Score: 1, Insightful
Well put. There are probably hundreds of security patches per year across many vendors. The article's position is that drastic changes in the way patches are released are necessary based on one instance of a patch gone wrong. Not to say it is the only time that has happened, but he could have at least come up with a few more examples.
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.
Re:I want it fixed ASAP
by
rainman_bc
·
· Score: 1, Insightful
Disclaimer:
there's good IT people out there, I just haven't worked with many. I'm ranting about the bad ones I've seen (about twenty I can think of right now)
<begin rant>
IT People insist on testing patches. I agree. Good idea. Truth be told, IT people I've seen generally find testing and applying patches quite boring. They'd much rather be running around the office yelling "security hole" at every idea that comes up, or bitching about the fact they don't have any time while they are chatting on messenger or writing posts on slashdot. Truth is, many IT people haven't the faintest clue what security means. Last one I saw was obsessed about throwing the web app behind a PIX firewall (which is a good idea), but was six months behind in server patches (which IMHO should have been higher on the priority list). No PIX will defend you against IIS holes.
In fact, he couldn't even produce valid backups for us each time he was asked to restore a backup. Clearly he needed to understand that security began with recovery. Once the recover plan's in place you worry about prevention. You can't prevent 100% of the attacks, but you can recover from 100% of them with the right plan.
<end rant>
This will probably burn up my Karma even further, but whatever. I feel better
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?
Do it right the first time...
by
Banner
·
· Score: 2, Insightful
And you won't have to keep patching it, would you? Of course that would mean spending money and time up front, rather than being able to hide the costs of the continuous maintenance cycles.
It would also mean forcing more programers to do their jobs right, and more managers to learn what they're doing as well (And that code doesn't fix itself because you lit a candle for it the night before).
Re:Do it right the first time...
by
PoesRaven
·
· Score: 2, Insightful
sorry, but your obviously NOT a programmer no matter what you do, your code will have bugs. you just do everything you can to keep them to a minimum, but if you spent a hundred years working on the same project, when all was said and done there would still be bugs.
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......
Re:Do it right the first time...
by
Anonymous Coward
·
· Score: 2, Insightful
[Do it right the first time] And you won't have to keep patching it, would you?
Ever fail to notice part of some instructions, only to regret it later? Ever use the wrong [software] tool for the job because you couldn't afford the right one? Ever zone out or get distracted during a class/meeting? Ever make a coding error that the compiler didn't catch? Ever shortcut a process because you had to rush home to take care of a sick kid or to meet a "drop-dead" deadline? Regular people do this and programmers are just regular people; they make mistakes. That includes people like Linus Torvalds, RMS, and Larry Wall.
Putting together multi-MLOC software is a dammed tricky process, and saying "Don't make any mistakes" is just plain useless.
Re:Do it right the first time...
by
lynx_user_abroad
·
· Score: 3, Insightful
It would also mean forcing more programers to do their jobs right...
Once you get beyond trivial programs, there's no such thing as fault-free software.
The reason for this is that software does not exist in a vacuum; the "correctness" of the behavior of any software is always evaluated through the eyes of the person using it.
This is why software which is considered bug-free today can become bug-ridden tomorrow if an exploit is discovered which exposes some previously hidden undesirable behavior. The software has not changed, but our expectations have changed.
Programmers cannot be expected to know what our expectations will become tomorrow. They cannot even be expected to fully understand our expectations today. That is why so much effort is put into understanding and defining the requirements. It is why very complex software (of the multi-billion-dollar government-contract type) often fails before delivery. It's why the 1.0 version is often considered more "buggy" than subsequent versions (where the users have a better understanding of how it's "supposed" to work).
It's also why two different people can have differing views of the "bugginess" of the same software; each has different expectations and exercises differing features.
And they say you can't test quality into software. Bollocks! Testing is the only way to get quality into software, because only the user can decide what quality means.
And, if you'll forgive the rant, it's why Microsoft hasn't got a prayer against FOSS. The beauty of Free/Open Source Software is that each user can correct the behavior of the software to fit their own definition of bug free. And each user test it themself. If the behavior isn't what they wanted, they fix it themself, ask the developer to fix it, or move on to something else.
Currently, we live in a world where Microsoft gets to define what the correct behavior of software is. If you don't like it, tough. But the world is quickly becomming more educated about what software is capable of, and more people are demanding that their computers adapt, rather than accepting that they must adapt to their computers.
Microsoft tried to define executable attachments as acceptable, then had to redefine that behavior as the filter through which we use Microsoft's software (not the software itself) changed. Windows 95(unpatched) today runs just like it did back in the middle of last decade, but no one would consider it a functional piece of software today.
In a way, Microsoft's operating systems are more buggy than anything else simply because there are more people making up their minds about wether it works the way they think it should work.
And, as the article points out, announcing patches for certain behaviors only highlights the fact that a significant number of their customers believe the original behavior is wrong ( == exploitable).
Do you want to do something real to stick it to Microsoft? Go Educate Somebody.
--
The thing about things we don't know is we often don't know we don't know them.
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.
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.
fuzzy logic?
by
Zoko+Siman
·
· Score: 3, Insightful
I don't see how this really changes anything. Either way, once the patch is released from what this guy is saying is that an exploit will come out in not much time. He's basically just saying to release the patch at a later date, I don't see any real reason however to justify his reasoning. How do you expect to get the problem patched at all if you just don't release the patch? To me to seems like with this reasoning the man is using we could just forever delay all patches.
"...or allowed critics to claim the superiority of some other system that supposedly doesn't need patches."
He's right though. Just because certain closed source vendors aren't doing so well with bugs, doesn't mean that the open source movement can sit back and laugh at them. There needs to be as much participation as possible to maintain OSS's reputation for quality.
A perspective from a gentoo user
by
frodo+from+middle+ea
·
· Score: 2, Insightful
Every time I do emerge -pUv world, I remember I haven't synced the latest tree. So I do emerge --sync and , then bam, another 200 packages to upgrade.
Some times the changes are so minor, I really wonder if it is worth it.
-- for the last time people, I am "frodo from middle eaRTH", not "middle eaST".
How does the Kool-aid taste?
by
Minwee
·
· Score: 3, Insightful
[...] 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.
He's arguing that they should slow down the patch cycle because all exploits come from reverse engineering patches. Slow down the patches, and you slow down the exploits.
Because, you know, nobody ever figures these things out on their own. It sure is a good thing we live in a world where exploits are never found in the wild before a nice, safe, 100% effective patch is released to counter them.
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!
Re:Wouldn't be a bad thing
by
grasshoppa
·
· Score: 2, Insightful
Sorry, I'm going to go with a WTF here. Windows is, far and away, the harder system to keep up to date, and it's dead easy to do now ( so no excuse to those of you window admins that don't keep your systems patched daily ).
Depending on the distro, Linux is mindlessly easy to keep up to date. Of course, you wouldn't use slack in this sort of enviroment, but RH has a nice package management system, and let us not forget Debian.
Cron jobs, that's where it's at.
-- Mod me down with all of your hatred and your journey towards the dark side will be complete!
Re:Speaking of astroturf
by
Atzanteol
·
· Score: 3, Insightful
...that's being exploited but that they refuse to (or cannot) fix.
Let's get the *whole* quote shall we?
-- "Ignorance more frequently begets confidence than does knowledge"
- Charles Darwin
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:In case the site falls over....
by
cavebear42
·
· Score: 2, Insightful
Computer world isn't going to "fall over." If it does, we could post the article then.
WHY do we mod up people who pollute the comments by copying the article into the comments?
Not informative. damn, where are my mod points when i need them?
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.
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!"
The patch causes the exploit??
by
David+Hume
·
· Score: 3, 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.
What if the distribution of the patch is, as matter of emperical fact, what *causes* the development of the exploit? From the article:
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.
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.
Now I know that this looks like a call for security through obscurity (see also here), but it is an interesting point. It appears the argument is that but for the distribution of the patch, there woudn't have been an exploit. I don't know how often that is true, if ever. But it does appear worth investigation.
As to your last point, the article indicates that the issue is not finding a better way to install patches, but instead finding a better way to distribute them without, if possible, also disseminating information that can be exploited by black hats. Again, from the article:
The main idea is that vendors need to rethink the patch distribution process, slow it down rather than speed it up and deliver security patches in a way designed to defeat the reverse-engineering process.
Re:The patch causes the exploit??
by
srwalter
·
· Score: 2, Insightful
Now I know that this looks like a call for security through obscurity (see also here), but it is an interesting point. It appears the argument is that but for the distribution of the patch, there woudn't have been an exploit. I don't know how often that is true, if ever. But it does appear worth investigation.
It may be that it does happen sometimes, but more likely than not it happens the other way around. We've all heard about the MSIE holes that were floating around for weeks before MS released a fix for them. Fact is, if there are vulnerabilities, closed source or not, people will find them. They don't need the vendors to show them to us. From a logical perspective, unless somebody came up with an exploit already, the vendor would probably not have released a patch in the first place. It makes them look bad, having to release security patches all the time. Look at Microsoft, for example.
If it sounds like a call for security through obscurity, tastes like a call for security through obscrurity, and quackes like a call for security through obscurity, then it is a call for security through obscurity.
-- Freedom is the freedom to say that 2 + 2 = 4
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.)
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...
Partially Correct About C/C++
by
EXTomar
·
· Score: 2, Insightful
I'm always bummed when people poo-poo C/C++ because they fail to see the real problem. It is true that C/C++ is probably too "low level" to do effective and safe application writing but that isn't the problem since one can clearly write bulletproof apps in C/C++.
The problem is that, like most bugs, the complexity of the language makes it hard to predict problems. Even in memory managed systems like Java and C# you can have crippling errors. You don't "fix" the problem by moving to these types of memory managed systems. You just contain and shift the problem from one place to another. A sloppy C# app will cause all sorts of havoc when an exploit is found in the way it performs.
The fix isn't avoiding C/C++. The real is rigorous code reviews to keep implementations clean and orderly so problems can be predicted. FOSS helps here but like any other venture it requires diligence to make it work effectively. No runtime environment is bulletproof and therefore will never be a substitute for plain old fashion inspecting of the code.
Re:I never update
by
Lehk228
·
· Score: 2, Insightful
are you behind a NAT/Firewall/Switch, they protect against ***almost*** all remote exploits by making your computer unroutable from the outside "you can't get there from here"
-- Snowden and Manning are heroes.
Not slow down, but wait and deploy more rapidly
by
EMIce
·
· Score: 2, Insightful
The slashdot blip about the article is misleading as usual. The author's main point is that it takes time for all systems to be patched, such that someone will reverse engineer the patch and release a rapidly spreading worm/virus before a majority of systems are patched. Simply slowing down the release of patches won't really help unless all vendors pick a regular patch release interval that people actually follow. This is what Microsoft appears to be trying, but the system is too dependent on people staying on schedule. The author says a fundamental change is needed, perhaps allowing encrypted patch downloads for some time, and having the patch installer wait for a key to install those patches simultaneously at a later date. This is clever and leads me to expand on the idea.
Why not have a standard piece of software that scans your system for different programs you have installed, one that registers the programs as well as your machine's ip address with a server? There could be a centralized server system or each vendor could have their own server to allay privacy concerns. Encrypted patches then could be auto-downloaded upon release and then held until some point in the future. Then simple UDP packets containing decryption keys could be sent to all registered systems - at least once enough of them have downloaded the patch - allowing near simultaneous installation.
An added bonus would be that if a worm/virus is reported in the wild, patching can commence immediately. This would really put a damper on the ridiculous rate of infection we usually see, currently so rapid in fact that anyone not patched is usually hit within a day. I'm glad most of these worms don't carry destructive payloads, the recent destructive witty worm killed my weekend. Try recovering data after random parts of the drive have been overwritten.
What if it's a bad patch?
by
menscher
·
· Score: 2, Insightful
There are occasional cases of a "bad patch" -- one that crashes machines, etc. I've seen a few over the years.
Now consider what happens when *everyone* installs at the same time. No chance for the vendor to get feedback and pull the patch. Somehow this seems risky....
Re:Speaking of astroturf
by
Anonymous Coward
·
· Score: 1, Insightful
We invite the whole world to protect themselves. The flaw in your argument is that "the whole world" is not comprised of hackers. Nearly all of "the whole world" has a right to defend itself against a small minority of hackers, don't they? Exactly who does keeping things secret protect? Not the users, because it's an active exploit. Not the hackers. No, keeping secrets protects nobody--except for protecting software vendors from being held to any standards of accountability.
It was probably posted so we'll be aware what PHBs are being fed.
It is NO wonder why it was written... from the bottom of the article:
Bill Addington is a software entrepreneur and inventor, operating several application service provider companies. His spinoff technologies have been sold to companies including America Online Inc. and Microsoft Corp. He conducts his security business in conjunction with Dyonyx in Houston.
He does have a point about reverse-engineering, but the solution to that isn't "don't release a patch". His article reads like a Microsoft HOWTO Cover Our Ass document.
One thing that would be interesting (but very difficult) to measure would be the relationship between exploits and fancy features. Fewer features/capabilities must mean fewer potential exploits. And if, as some estimates stated, Word 2000 users on average exercised 10-15% of the features it provided, one must wonder if the other 85-90% of the features were worth the associated exploit and bug potential.
Imagine Internet Explorer minus ActiveX, minus silently-installing "agents", and minus some of the magical integration with the OS. It might look something like Firefox (fast, clean, and comparatively exploit-free).
The article recommends that the patches be encrypted when being distributed, this doesn't make it any harder to reverse engineer them. Just install the patch on a box and do a before/after diff...
Bad Writing
by
wonkavader
·
· Score: 3, Insightful
The substance of this article seems to be:
Catchy way of describing my idea (albeit misdirective)
Why we need my idea
My idea.
As you can tell from how Slashdotters are reacting, they never finished the article, or didn't read the whole of the last paragraph, where the idea of encrypting patches and distributing a key days or weeks later is actually stated.
It's a good idea. It solves badwidth issues for people with huge patches (Microsoft, in particular).
But he has so much in the first and second section and so little in the last section that his idea gets buried. I think he needs to make his ideas less mysterious. Give us some terms of the actually idea ("Slow down patches WITH CRYPTOGRAPHY") or something so that we actually READ the last paragraph.
Furthermore, there would need to be a darn easy way to do this for it to work. Microsoft's update feature could do it, as (we can pretend) every windows box has it.
If SSH has a vulnerability, you can release a patch this way, unless every OS it runs on has a automatic system -- one which gets patches and keys and installs patches when a key arrives. Red Carpet could be modified to do that, but what do the Plan Nine users use, the MacOS users, the FreeBSD people?
However, over time, such a system could get wide acceptance for configuration/vendor specific patches and then become useful for applications, as well.
It would have to be a well-defined OPEN system, and MicroSoft (it seems) need not be included -- they'd do their own thing and make the system non-portable.
Took them long enough
by
InsaneGeek
·
· Score: 2, Insightful
You kind of missed the point there. If you have something out running in the wild found you release a useable patch that day. He's talking about exploits found from the vendor, not ones out in the wild. i.e. when Redhat finds an extremely obscure buffer overflow not joe hacker. Instead of releasing a statement about the problem an hour after it's found, and then putting a patch out a day later, with admins patching couple of days after (a weekend you know) he's advocating that since nobody else knows about it: putting out an encrypted patch to the users to download over the weekend, then on let say every tuesday simultaneously unencrypt & activate all the patches, and send out a exploit report. With this method a greater percentage of the population will not have an issue with vendor found exploits.
He's not saying that all exploits are found in house, he's not saying that shit doesn't start outside, but he's saying if it's not in the wild now, why fuck over everybody on the internet over a threat that doesn't exist yet. If there is a threat release the day you find it, if there isn't it'd be nice to be able to wait for the admins to get over their weekend hangover.
Re:Speaking of astroturf
by
Fapestniegd
·
· Score: 3, Insightful
So we leave responsible people in the dark (and at risk) until every last irresponsible person gets a clue. Let's not reduce important work to the lowest common denominator, ok?
I don't care if "most people won't install a quick fix for a security hole even if it was available from day 1," I will, so let me protect my network and let their networks burn. Because the people you're talking about have shown that they will not install a patch *months* after "a major security upgrade is released," so how does this security model help at all? Hell most of them aren't even aware of the vulnerability untill their machines slow to a crawl and they hear about a new worm on the local news. So why should I wait for them to patch before I protect myself?
If I may expand upon that.
by
khasim
·
· Score: 2, Insightful
You are completely correct.
May I also point out that such is the case with the existing "anti-virus" market?
We see "patches" every week for the latest round of viruses. And we will continue to, until Microsoft addresses the actual vulnerabilities in their software (and the security model upon which it is based).
A virus or a worm (and, to a less extent, trojans) are all FAILURES in the security of a system. How many failures of an almost identical nature does it take before people realize that the model is flawed?
Re:Slowing patches doesn't work
by
Minna+Kirai
·
· Score: 2, Insightful
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.
No. Where did you come up with that odd definition?
That means that if you discover a bug in Linux 2.6.x kernel, that bug has been around since the Minix days!
By that interpretation, a zero-day bug would be so rare we wouldn't even need a word to describe them! (BTW: Linux has never contained any Minix source code)
Zero-day really means that the person running the exploit is the one who found the hole. Or a little more loosely, it means that some attackers are aware of the hole, but the software author or public at large is not (not truely zero-day, but appears that way to outsiders, as they don't know when the flaw was spotted).
By extension, an exploit that is used after the flaw becomes publically known might be a 2-day or 10-day rootkit, or however much time has elapsed since the disclosure.
Compared to script-kiddies who download rootkits from others, zero-day hackers are a threat that a sysadmin can't avoid by obsessively watching for security announcements. Zero-day approximately means "before there are any security announcements".
(Addington's article was incorrect about "zero-day" as well. He claimed it has something to do with not using trojans or viruses, which is actually irrelevant to the meaning)
that is a variant on the two.....
by
zogger
·
· Score: 2, Insightful
... explosive devices weapon. The first one goes off (take yer pick, truck bomb, land mine, whatever). Everyone runs over to assess damage and to help clear rubble and tend to the victims and whatnot, then WHAMO, the second bigger one goes off, the one that really inflicts the damage.
Basic assymetrical warfare 101
and using the patch for the clues needed for the next round improved virus would be akin to stealing the materials you need for your explosive device from your target, in other words, frosting on the cake
that would be asym wf 102
ways to beat it? Easiest way is to not be a target.
I'll let anyone figger the analogy out how that applies to cyber security
Besides that, unless the web is RADICALLY changed and every device has an unspoofable publiclly see able IP that is external and unique, and that IP has an identifiable human connected to it, and all web traffic is logged..well, it'll just always be an arms race and an intel race. We got to ask ourselves, do we want a web like that, or put up with it like it is now?
Me, I'll take the security concerns over "safe"
big bro surfing.
False premise
by
Alex+Belits
·
· Score: 2, Insightful
The code exploiters use the same tactics against the software vendors that the software vendors and antivirus companies use on them. They 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.
This is wrong, and therefore the whole article based on this premise is nonsense.
Most of the security flaws are found ransomly or through testing and observation of running software, by various people outside the companies that produce the patches. So the possibilities are:
A black hat hacker/cracker found the vulnerability. Then the exploit is soon to follow, and only after the exploit is found, the fix can be issued. Without any doubt, this has to happen as soon as possible because it will reduce the harm caused by exploit.
A security researcher or regular user found a vulnerability. Then he will follow an established procedure of notifying the vendor and waiting for some reasonable time for the fix to be issued, and after that he may publish a detailed explanation of the nature of vulnerability. This is by far the most common kind of situation -- just look at Bugtraq. Then unless the vulnerability is discovered independently, black hats won't start the work on exploits until at least the patch is ready (and then they will just have to look at what is patched -- no real need for any complex reverse-engineering), but most likely until the explanation of the vulnerability is published (and then only very lazy users are supposed to keep running the unpatched versions). The timing of the patch release is absolutely irrelevant for this case, the clock starts ticking at the moment when the evidence of vulnerability reached black hats, and stops when all the users get the patch. Will it happen sooner or later is irrelevant, but delaying the patch increases the probability of independent discovery, and then back to the case 1, so the sooner is the patch released, the safer the users are.
Same as above but the company managed to delay the release of the patch beyond any reasonable time. Then the person who discovered it may publish the vulnerability description, in hope that then it will be fixed. Will it be out of concern for the users (why are likely to be hit by an exploit if this vulnerability is found independently), or for himself (a user may rely on the software, and afraid that he will be attacked in case of independent discovery by black hats), or as an attempt to shame the company into fixing things faster in the future, or out of plain frustration of dealing with uncoperative vendor, it does not really matter -- vendor should react as soon as possible in either case.
Same as above but the description is published immediately by an uncooperative user/researcher. Needless to say, delays are even more dangerous then.
So the conclusion is: there is no possible scenario that justifies the delays of the patches release. Only a lazy software vendor may think of such a lame excuse for delays.
-- Contrary to the popular belief, there indeed is no God.
Slashdot Mirror
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?
And you won't have to keep patching it, would you? Of course that would mean spending money and time up front, rather than being able to hide the costs of the continuous maintenance cycles.
It would also mean forcing more programers to do their jobs right, and more managers to learn what they're doing as well (And that code doesn't fix itself because you lit a candle for it the night before).
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.
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.
I don't see how this really changes anything. Either way, once the patch is released from what this guy is saying is that an exploit will come out in not much time. He's basically just saying to release the patch at a later date, I don't see any real reason however to justify his reasoning. How do you expect to get the problem patched at all if you just don't release the patch? To me to seems like with this reasoning the man is using we could just forever delay all patches.
Nice ding against Linux and open source:
"...or allowed critics to claim the superiority of some other system that supposedly doesn't need patches."
He's right though. Just because certain closed source vendors aren't doing so well with bugs, doesn't mean that the open source movement can sit back and laugh at them. There needs to be as much participation as possible to maintain OSS's reputation for quality.
Some times the changes are so minor, I really wonder if it is worth it.
for the last time people, I am "frodo from middle eaRTH", not "middle eaST".
He's arguing that they should slow down the patch cycle because all exploits come from reverse engineering patches. Slow down the patches, and you slow down the exploits.
Because, you know, nobody ever figures these things out on their own. It sure is a good thing we live in a world where exploits are never found in the wild before a nice, safe, 100% effective patch is released to counter them.
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!
Sorry, I'm going to go with a WTF here. Windows is, far and away, the harder system to keep up to date, and it's dead easy to do now ( so no excuse to those of you window admins that don't keep your systems patched daily ).
Depending on the distro, Linux is mindlessly easy to keep up to date. Of course, you wouldn't use slack in this sort of enviroment, but RH has a nice package management system, and let us not forget Debian.
Cron jobs, that's where it's at.
Mod me down with all of your hatred and your journey towards the dark side will be complete!
...that's being exploited but that they refuse to (or cannot) fix.
Let's get the *whole* quote shall we?
"Ignorance more frequently begets confidence than does knowledge"
- Charles Darwin
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
Computer world isn't going to "fall over." If it does, we could post the article then.
WHY do we mod up people who pollute the comments by copying the article into the comments?
Not informative. damn, where are my mod points when i need them?
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.
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!"
What if the distribution of the patch is, as matter of emperical fact, what *causes* the development of the exploit? From the article:
Now I know that this looks like a call for security through obscurity (see also here), but it is an interesting point. It appears the argument is that but for the distribution of the patch, there woudn't have been an exploit. I don't know how often that is true, if ever. But it does appear worth investigation.
As to your last point, the article indicates that the issue is not finding a better way to install patches, but instead finding a better way to distribute them without, if possible, also disseminating information that can be exploited by black hats. Again, from the article:
Is this possible?
Only Women Bleed (Sex, Sharia remix)
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.)
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...
I'm always bummed when people poo-poo C/C++ because they fail to see the real problem. It is true that C/C++ is probably too "low level" to do effective and safe application writing but that isn't the problem since one can clearly write bulletproof apps in C/C++.
The problem is that, like most bugs, the complexity of the language makes it hard to predict problems. Even in memory managed systems like Java and C# you can have crippling errors. You don't "fix" the problem by moving to these types of memory managed systems. You just contain and shift the problem from one place to another. A sloppy C# app will cause all sorts of havoc when an exploit is found in the way it performs.
The fix isn't avoiding C/C++. The real is rigorous code reviews to keep implementations clean and orderly so problems can be predicted. FOSS helps here but like any other venture it requires diligence to make it work effectively. No runtime environment is bulletproof and therefore will never be a substitute for plain old fashion inspecting of the code.
are you behind a NAT/Firewall/Switch, they protect against ***almost*** all remote exploits by making your computer unroutable from the outside "you can't get there from here"
Snowden and Manning are heroes.
The slashdot blip about the article is misleading as usual. The author's main point is that it takes time for all systems to be patched, such that someone will reverse engineer the patch and release a rapidly spreading worm/virus before a majority of systems are patched. Simply slowing down the release of patches won't really help unless all vendors pick a regular patch release interval that people actually follow. This is what Microsoft appears to be trying, but the system is too dependent on people staying on schedule. The author says a fundamental change is needed, perhaps allowing encrypted patch downloads for some time, and having the patch installer wait for a key to install those patches simultaneously at a later date. This is clever and leads me to expand on the idea.
Why not have a standard piece of software that scans your system for different programs you have installed, one that registers the programs as well as your machine's ip address with a server? There could be a centralized server system or each vendor could have their own server to allay privacy concerns. Encrypted patches then could be auto-downloaded upon release and then held until some point in the future. Then simple UDP packets containing decryption keys could be sent to all registered systems - at least once enough of them have downloaded the patch - allowing near simultaneous installation.
An added bonus would be that if a worm/virus is reported in the wild, patching can commence immediately. This would really put a damper on the ridiculous rate of infection we usually see, currently so rapid in fact that anyone not patched is usually hit within a day. I'm glad most of these worms don't carry destructive payloads, the recent destructive witty worm killed my weekend. Try recovering data after random parts of the drive have been overwritten.
Now consider what happens when *everyone* installs at the same time. No chance for the vendor to get feedback and pull the patch. Somehow this seems risky....
We invite the whole world to protect themselves. The flaw in your argument is that "the whole world" is not comprised of hackers. Nearly all of "the whole world" has a right to defend itself against a small minority of hackers, don't they? Exactly who does keeping things secret protect? Not the users, because it's an active exploit. Not the hackers. No, keeping secrets protects nobody--except for protecting software vendors from being held to any standards of accountability.
It was probably posted so we'll be aware what PHBs are being fed.
It is NO wonder why it was written... from the bottom of the article:
He does have a point about reverse-engineering, but the solution to that isn't "don't release a patch". His article reads like a Microsoft HOWTO Cover Our Ass document.
One thing that would be interesting (but very difficult) to measure would be the relationship between exploits and fancy features. Fewer features/capabilities must mean fewer potential exploits. And if, as some estimates stated, Word 2000 users on average exercised 10-15% of the features it provided, one must wonder if the other 85-90% of the features were worth the associated exploit and bug potential.
Imagine Internet Explorer minus ActiveX, minus silently-installing "agents", and minus some of the magical integration with the OS. It might look something like Firefox (fast, clean, and comparatively exploit-free).
.sigs are for post^Hers.
The article recommends that the patches be encrypted when being distributed, this doesn't make it any harder to reverse engineer them.
Just install the patch on a box and do a before/after diff...
The substance of this article seems to be:
Catchy way of describing my idea (albeit misdirective)
Why we need my idea
My idea.
As you can tell from how Slashdotters are reacting, they never finished the article, or didn't read the whole of the last paragraph, where the idea of encrypting patches and distributing a key days or weeks later is actually stated.
It's a good idea. It solves badwidth issues for people with huge patches (Microsoft, in particular).
But he has so much in the first and second section and so little in the last section that his idea gets buried. I think he needs to make his ideas less mysterious. Give us some terms of the actually idea ("Slow down patches WITH CRYPTOGRAPHY") or something so that we actually READ the last paragraph.
Furthermore, there would need to be a darn easy way to do this for it to work. Microsoft's update feature could do it, as (we can pretend) every windows box has it.
If SSH has a vulnerability, you can release a patch this way, unless every OS it runs on has a automatic system -- one which gets patches and keys and installs patches when a key arrives. Red Carpet could be modified to do that, but what do the Plan Nine users use, the MacOS users, the FreeBSD people?
However, over time, such a system could get wide acceptance for configuration/vendor specific patches and then become useful for applications, as well.
It would have to be a well-defined OPEN system, and MicroSoft (it seems) need not be included -- they'd do their own thing and make the system non-portable.
You kind of missed the point there. If you have something out running in the wild found you release a useable patch that day. He's talking about exploits found from the vendor, not ones out in the wild. i.e. when Redhat finds an extremely obscure buffer overflow not joe hacker. Instead of releasing a statement about the problem an hour after it's found, and then putting a patch out a day later, with admins patching couple of days after (a weekend you know) he's advocating that since nobody else knows about it: putting out an encrypted patch to the users to download over the weekend, then on let say every tuesday simultaneously unencrypt & activate all the patches, and send out a exploit report. With this method a greater percentage of the population will not have an issue with vendor found exploits.
He's not saying that all exploits are found in house, he's not saying that shit doesn't start outside, but he's saying if it's not in the wild now, why fuck over everybody on the internet over a threat that doesn't exist yet. If there is a threat release the day you find it, if there isn't it'd be nice to be able to wait for the admins to get over their weekend hangover.
So we leave responsible people in the dark (and at risk) until every last irresponsible person gets a clue. Let's not reduce important work to the lowest common denominator, ok?
I don't care if "most people won't install a quick fix for a security hole even if it was available from day 1," I will, so let me protect my network and let their networks burn.
Because the people you're talking about have shown that they will not install a patch *months* after "a major security upgrade is released," so how does this security model help at all? Hell most of them aren't even aware of the vulnerability untill their machines slow to a crawl and they hear about a new worm on the local news. So why should I wait for them to patch before I protect myself?
You are completely correct.
May I also point out that such is the case with the existing "anti-virus" market?
We see "patches" every week for the latest round of viruses. And we will continue to, until Microsoft addresses the actual vulnerabilities in their software (and the security model upon which it is based).
A virus or a worm (and, to a less extent, trojans) are all FAILURES in the security of a system. How many failures of an almost identical nature does it take before people realize that the model is flawed?
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.
No. Where did you come up with that odd definition?
That means that if you discover a bug in Linux 2.6.x kernel, that bug has been around since the Minix days!
By that interpretation, a zero-day bug would be so rare we wouldn't even need a word to describe them! (BTW: Linux has never contained any Minix source code)
Zero-day really means that the person running the exploit is the one who found the hole. Or a little more loosely, it means that some attackers are aware of the hole, but the software author or public at large is not (not truely zero-day, but appears that way to outsiders, as they don't know when the flaw was spotted).
By extension, an exploit that is used after the flaw becomes publically known might be a 2-day or 10-day rootkit, or however much time has elapsed since the disclosure.
Compared to script-kiddies who download rootkits from others, zero-day hackers are a threat that a sysadmin can't avoid by obsessively watching for security announcements. Zero-day approximately means "before there are any security announcements".
(Addington's article was incorrect about "zero-day" as well. He claimed it has something to do with not using trojans or viruses, which is actually irrelevant to the meaning)
... explosive devices weapon. The first one goes off (take yer pick, truck bomb, land mine, whatever). Everyone runs over to assess damage and to help clear rubble and tend to the victims and whatnot, then WHAMO, the second bigger one goes off, the one that really inflicts the damage.
Basic assymetrical warfare 101
and using the patch for the clues needed for the next round improved virus would be akin to stealing the materials you need for your explosive device from your target, in other words, frosting on the cake
that would be asym wf 102
ways to beat it? Easiest way is to not be a target.
I'll let anyone figger the analogy out how that applies to cyber security
Besides that, unless the web is RADICALLY changed and every device has an unspoofable publiclly see able IP that is external and unique, and that IP has an identifiable human connected to it, and all web traffic is logged..well, it'll just always be an arms race and an intel race. We got to ask ourselves, do we want a web like that, or put up with it like it is now?
Me, I'll take the security concerns over "safe"
big bro surfing.
The code exploiters use the same tactics against the software vendors that the software vendors and antivirus companies use on them. They 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.
This is wrong, and therefore the whole article based on this premise is nonsense.
Most of the security flaws are found ransomly or through testing and observation of running software, by various people outside the companies that produce the patches. So the possibilities are:
So the conclusion is: there is no possible scenario that justifies the delays of the patches release. Only a lazy software vendor may think of such a lame excuse for delays.
Contrary to the popular belief, there indeed is no God.