Slashdot Mirror
Is Finding Security Holes a Good Idea?
ekr writes "A lot of effort goes into finding vulnerabilities in
software, but there's no real evidence that it actually improves security. I've been trying to study this problem and the results (pdf) aren't very encouraging. It doesn't look like we're making much of a dent in the overall number of vulnerabilities in the software we use. The paper was presented at the Workshop on Economics and Information Security 2004 and the slides can be found here (pdf)."
Is finding security holes a good idea?
Writing Security Considerations Sections
Hmmm.
In order to fix vulnerabilities, you have to find them. However, as soon as they are found and publicized, some script kiddie exploits them. So yes finding them is a good idea, patches just need to be released and INSTALLED before script kiddies expliot them.
While we still have a long way to go regarding security, I believe we're still learning how to design security into systems. People are creative. Computers are not. I believe that we're infants at this stage of computer development. Look at how far we've come in 30 years? Where will we be after 30 more?
It's still a brand new world to explore. We have alot of work ahead of us.
Has Comcast disconnected your Internet account? Same here. You can read about it at http://comcastissue.blogspot.com
Looks like Microsoft had it right all along! :o)
/me ducks and runs
If no one fixes the holes, someone's going to find them, and exploit them. That's all there is to it.
I'm not 100 percent with the whole free software foundation ideology, but something about it that really appeals to me is the implication for computer security. If we could just get people to provide the blueprints for their software, I think it would go a long way to increasing computer security. Having thousands of people across the world looking at code for bugs is a heck of a lot better than just the dozen developers assigned to a particular product. It's already easy to find ways to make programs crash; let's focus on trying to find ways to keep them up by fixing bugs. Rolf
Sounds alot like something Microsoft has been saying...
I cannot believe that sticking your head in the sand is any better. I would think that there are many examples of security holes being found and patched before they could be exploited.
If anything, the data seems to point to the fact that software companies and users need to act on security holes and patches more quickly. This may require better education of the user, and it also would help to have better patching mechanisms.
Great ideas often receive violent opposition from mediocre minds. - Albert Einstein
I like sticking my head into the sand, but the grit keeps scratching my sunglasses. Any suggestions?
'Cause trusting the manufacturer to make their product secure has shown to be such a good solution in the past.
The alternative is to not look and leave that to the people who will fix it or the people that will exploit it. Are you really comfortable with that?
how does this sound. We leave all the holes and every PC gets turned into a zombie spammer and the internet gets slashdotted by the spam.
If you ignorethe problem it gets worse untill no one can deal with it. If you dig at it little by little you may notkill it but you restrict it's growth and make it manageable.
--- [Insert intresting Sig here]
I guess I'm a little unclear on what the research stated is supposed to actually accomplish.
Roving Web-Teleoperated Robot
As a sysadmin, I can tell you for certain that reading bugtraq and other vulnerability lists helps me. I can study trends in software, trends in company response and protect myself against problems. If I know a new worm or vulnerability has a prerequisite configuration then I can make sure to configure software in a way where I won't be vulnerable until a patch is release or until I can apply it.
Anyone who is subscribed to bugtraq can see the bad situation some software is in. Lately there was a lot of posts about Linksys that raised my eyebrow. Do I really want to deal with a company that doesn't properly address vulnerabilities it's made aware of? Good thing bugtraq posters had a workaround for the Linksys remote administration problem.
The global economy is a great thing until you feel it locally.
The real problem in software security lies in the design of the software itself. No amount of patches and service packs can secure unsecure software. Instead to be secure it has to be biult that way from the ground up. These findings seem to make sense in this context beacause patching software doesen't change the fundamental way it works.
411 Y0UR 8453 4R3 8310NG 70 U5!! -NSA
The goal of searching out vulnerabilities is to find them before the people with black-hats do. This is why most clearinghouses of such reports don't release the information until there is a fix (or until such time passes that vendors have demonstrated a lack of interest in producing a fix): the people who would exploit the bugs need to mount their OWN efforts to discover them.
Ignoring actual bugs, there are many other kinds of security vulnerability. We know that software will always have side-effects that we don't intend. In fact, we desire this (e.g. providing a user with the flexibility to use the product in ways not envisioned by the creator). Sometimes those side-effects have security implications (e.g giving someone an environement variable to control a program's behavior lets a good user do something you might not have thought of, but it turns out a malicious user can abuse this in order to raise their security status).
This means that, as long as software is not static, security bugs will continue to be introduced. Discovering them as fast as possible is the only correct course of action... you KNOW the black-hats will be.
Is finding security holes a good idea? Only if you want to fix them.
Should we jail murderers, since it doesn't seem to prevent murders, or curb the murder rate? Whatever.
Anyway, he is looking at the problem on too wide a scale. Slash (the code running this site) is much less vulnerable to various exploits than many of the alternatives that have cropped up, and yes, it has been a huge benefit to the people who run and use this site, undoubtedly.
In other news, a new study shows mowing the lawn doesn't stop the grass from growing. Scientists are perplexed at this unusual discovery.
one of the reasons I now use Firefox as my primary browser is because so many exploits were found in IE. So even if Microsoft doesn't respond when exploits are found, these exploits do cause some people to look for more secure alternatives.
To answer the question, yes. Finding security holes is a good idea.
To the unasked question, "Is finding individual security holes the best possible use of a security researcher's time?", the answer is No. The best use of security research is to classify different types of security holes and use that information to create a development framework where those security holes are extremely difficult to recreate. For example, you're not going to find buffer overruns in Java code, since the memory is dynamically handled for you. Eventually, having security levels, encrypted buffers, etc. will all be part of a standard developer's library.
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
Seems like the future is no longer "Security Through Obscurity" but more like "Trust but Verify"
;-)
I trust you
what is needed is for security to be part of the design from the beginning. We can remove many or all of the over flow problems by just changing the language used to write the software. no password should be saved or sent unencrypted ( with good hard to brake encryption. For example. This needs to designed in to the program or OS not added latter. By dealing with these kind of problems after the fact we are chasing the bugs and pushing the bad design around the code, instead of just having a good design from the start. secure be design not after thought.
but ignorance is bliss.
take your pick
Of course there are many found and patched before the damage is done - they just don't get the kind of press that exploited ones do.
A proper experiment would be an application where the developers made no attempt to find security problems. Any volunteers ? Anyone want to install such an application. (Nevermind all the joking about MSoft having already volunteered and how it's widely installed).
Evidence wouldn't show us that searching for security holes improves security... Rather, such a judgement requires reasoning and evalution of the evidence. Common sense stuff, here.
Do smashing cars head-on into brick walls improve car safety? No, of course not. Evalution of the results of the crash, and using those findings to build better cars, that is what improves car safety, and the situation is entirely analogous in the security world. The assumption is that there is always a weakest link in security, that link is the most likely one to be exploited, and the trick is finding that link and strengthening it against attacks in the future, hopefully to the point where it is more likely that other links are weaker.
Another good point, IMHO, is that patching holes allows for hackers to reverse engineer the patch quicker. It's easier to reverse engineer than to develop
Software companies should work to patch less. In particular Microsoft should save patches for Service Packs. This would keep worms and viruses out longer.
That's my IMHO. What do you think?
>
UID 1000000 is just around the corner.
The ideas of White Hat and Black Hat finding versus the impact and cost are valid points.
I look at it this way. It may cost to fix a security problem, whether it be time, money or both. However fixing a problem that is found is far better than just letting it dangle. So what if only 1 in 5.67 million can find the flaw. It was found once and it will be found again. Err to the side of caution in this case. I prefer to have all my bases covered with current known problems versus losing data/time/money on something that I could have fixed.
In terms of more security bugs being found and fixing the problems. The internet and this technology is still growing. Fixing and securing software/hardware is one of the growing pains for our industry. It is better to fix what is broken then to stick your head in the sand and hope no problems arise.
Besides where is the fun in not having to change things up once in a while? =P
Push harder towards Open Media/Content
"but there's no real evidence that it actually improves security"
OK, didn't RTFA, but is there 'real evidence' to the contrary?
You can't fix what you don't know is broken. Is ignorance a better security solution?
...that hunting down thugs and thieves and terrorists is not necessarily helping the nation's security, so let's not do it. Asinine suggestion.
to find problems in any line of products. Quility and relaibility is important.Would you buy an unreliable car that would kill everyone in an accedent,U may never be in an accedent but would u risk it when it comes to a car.how about a lock for your front door?
Here is the freecache to Google's HTML versions: Here and here.
then someone who wants to do the real hacking will find them. If a malicious hackers finds the security hole, then he/she might utilize it, and they won't be nice enough to give us a patch to protect against it. So since the holes are there, lets find them and patch them BEFORE some malicious programmer does. Finding security holes is a good choice, making patches for security holes is a better choice, actually UTILIZING these patches for security holes is the BEST choice...unless you want to be on Citibank Identity theft commercials :)
I mod down so you can mod up. Your welcome.
software is like art and the only flaws in it are the ones we place there. software will never be 100% secure face it thats how the world works. even if the whole open-source community worked on a single piece of software ( wouldn't that be interesting) there would be a few that would work against it. heres a solution to the problem... have people start making software that no one wants to find holes in. just release it and everyone gets along.
Force of Will = Glue 'nuff said.
The people trying to abuse security may likely have the same sort of skills as the flaw hunters, though hopefully less skill. Its not just that some bugs are found but perhaps the most obvious ones are found.
Embarrassment encourages vigilence: Software firms are always looking to reduce costs (who isn't) - outside bug hunters encourage them to test more completely.
I think really bad software abuse usually has a motive connected with bad treatment or reputation for bad treatment. Even if there is a small lag time between the discovery and fixing of a hole it doesn't let the problem lie around where people who develop a grudge can use it.
Finally (and most importantly) fairness dictates that if I'm using a product you know a problem with - you should tell me about it. Consumers deserve the chance to disable systems, switch products etc.... if they feel vulnerable.
Especially if software is closed source - how do you know this bug isn't the tip of the iceberg. Companies have conviced consumers they dont get to look inside software -- they can't stop others from hearing about its flaws.
ls
If you find a security hole then the mistake has already been made. Fix the hole, but also make sure the same bug doesn't exist in any other program. Finding the same exploits again and again (buffer overruns, format string vulnerabilities, tempfile symlink vulnerabilities) reflects very badly on free software and programmers' ability to learn from bugs found in other software. (Not that proprietary software is necessarily any better - I am just not discussing it here.)
The OpenBSD people have built up a good track record on security by finding holes and fixing them everywhere possible. I am sure they would disagree with your assertion that finding holes does not help to improve security. Finding the bugs is an important first step towards not putting them back in next time you write code.
-- Ed Avis ed@membled.com
The OpenBSD folks have known that for ages.
The idea is to find the security holes before the bad guys do, so you can fix the problem before its in the wild and exploiting people, without your knowledge.
Every program has bugs. There is no way around it. What makes the difference though is how you respond to bugs when they are found.
You have a choice - either be like Microsoft, try to deny that the bugs exist, or downplay the bugs, and try to stifle the person who found it - or be like a real programer, fix the bug, and get people to fix the problem, and go on with life.
Brielle
Working to discover what security flaws exist in any given program, series of prgrams, Operating Systems, hardware, etc is not the real issue in my opinion: it is the idea of working to design a system that is as stable, flexible/adaptable, transparent, and clear as possible while at the same time providing a foundation that allows room for future growth. To really execute all of these concepts well can be a truly daunting task, IMO, given the often limited salaries/wages, time and other constraints (e.g. management) that progammers in particular have to face. This is just one of the reasons programs/kernels/systems, etc go through so many revisions.
I know the article doesnt imply this at all but the solution to security and stability problems does not lie in simply sticiking our collective heads in the sand. We have to answer the who/what/when/where/why elements of design. Building a better mousetrap involves many elements, as I alluded to above.
uR iGn0ranc3, Their Power
Is it just me or does it seem a stretch that within the first couple of paragraphs the assumption is made that there is somehow a direct relation between the number of intrusions and the cost of those intrusions:
"If a vulnerability isfound by good guys and a fix is made available, then the number of intrusions--and hence the cost of intru-sions--resulting from that vulnerability is less than if it were discovered by bad guys"
While I'm not certain that there is NO relationship between the two, I'm certainly NOT comfortable positing such a blanket assessment.
Perhaps there is a relationship between the net economic cost and the number of intrusions, but it seems equally likely that it would be possible through full disclosure the marginal cost of each instrusion could be reduced; a possible seemingly left lightly treated at best in this essay.
Bryan "BJ" Hoffpauir
Nowadays so many people are still ignorant about software security... If we were not searching for (and finding) security holes, the situation would be even worse ! The bad guys would be even more dangerous with their very well organized information channels... Think about this.
However, the real world is not like that. There are nasty people (inviduals as well as organized criminal groups). We can't stop them from studying security and, as long as there are serious securtiy problems, these people will find some of them and use them to do whatever evil deeds they want to do commit (like turning PCs of innocent people into spam-spewing zombies, credit card fraud, etc etc.)
The only way to effectively counteract this is to bring problems into the light. Without security research by "whitehats" (people who look for vulnerabilities but don't use them without prior authorization from whoever is in charge of the vulnerable computer system), only the "bad guys" (blackhats) would have any in-depth knowledge of security issues. There'd be no hope of making systems secure if only the bad guys have the knowledge that matters!
Under construction: swpat politics overview article
Many posters have already taken to jumping to bad conclusions having not latched on to one of the report author's best conclusions. If patches are not applied then the time and money spent on discovery are worthless. The only ways to make discovery worthwhile is if the patches are applied, otherwise discovery does not resolve the vulnerabilities.
Automatic/Forced patching is the only way to make discovery worthwhile because otherwise the number of vulnerable systems is unpredicatable over time and constitutes a large risk. Security issues must be resolved as quickly as possible in order to mitigate risks, and unless patch application is automated and enforced then discovery becomes meaningless.
Even if I knew that tomorrow the world would go to pieces, I would still plant my apple tree. -Martin Luther
Security holes are bound to be discovered eventually, either by unscrupulous users or professionals with honest intentions.
By hunting for flaws in software and making them public, these flaws can be fixed... Not making a vulnerability public doesn't help anything. It just gives Joe hacker his own personal backdoor that he's free to use indefinitely.
-yeah
The value of finding security holes is totally dependant upon the company whose product has the hole.
I work at Barnes & Noble as a bookseller; within a few months of working there, I found huge security holes in their in-store search system and network. I reported these to my manager; as soon as she grasped the scope of the hole, she called tech support in New York. I spent 30 minutes explaining all the different problems to them, and that was that.
I didn't think they'd do anything about it, and that's the problem--since it costs time and money, most companies can't or won't fix holes. To my surprise, however, my store began beta testing the next version of the in-store software. What was even more surprising was that every hole I had reported was gone (so I went and found more, of course).
There's never a silver-bullet; a new vulnerability will always surface. It's really hard to stay ahead of the curve, but it's something that must be attempted.
I don't think you can argue effectively that it's not economically viable to search for vulnerabilities. Each exploit prevented saves money on rolling out patches, legal liability (earned or otherwise), and reputation. Just because you can't measure these without their actually happening doesn't change the fact that you will save money in the long run by preventing vulnerabilities from being released. It seems to me that by economical is really meant finding the most vulnerabilities for the least investment. So the proper question to ask then becomes what is the best method for economically finding vulnerabilities?
Security isn't an add-on, it's an integral part of every component of every system--whether functional or flawed--and needs to be a design consideration ranking right up there with the user interface.
One of the obvious benefits of posting secuity holes is that it gives developers the insight and the opportunity to not duplicate that same security flaw in another system. How consistently, or not, we are learning these lessons is a different issue.
because it costs too much.
You must design in quality from the beginning, and develop systems with a process that guarantees the quality is not lost.
This is known to be true for everything from trivial widgets through the most complex systems that humans are capable of designing.
I suppose it is nice to have it confirmed for security flaws, but it isn't surprizing.
Lew
"The Constitution, the WHOLE Constitution, and nothing but the CONSTITUTION."
corepirate nazi puppet PostBlock censorship devise? he must be a closet refudlicking nazi puppet? what's the point?
what a hoot, if it weren't so scarIE?
Due to excessive bad posting from this IP or Subnet, anonymous comment posting has temporarily been disabled. You can still login to post. However, if bad posting continues from your IP or Subnet that privilege could be revoked as well. If it's you, consider this a chance to sit in the timeout corner or login and improve your posting . If it's someone else, this is a chance to hunt them down. If you think this is unfair, you're the only one that cares.
'security' buy censhorship. sheesh!@#$%
Really. I didn't make that up, check the link! Who is this guy, and why is he giving me software security advice?!
... then someone else will. Hard to say if finding and fixing is helping, because noone knows how bad it would be if we didn't do it.
Then again, MS doesn't seem to be trying to find vulnerabilities in their own code; often it's found by others. Sometimes it's the bad guys.
Point being, it's hard to say what effect something is having when you can't contrast it against "not doing it."
It might help against worms or script kiddies, but I'm keeping up with patches.
Worms are annoying, they might force you to restore backups and rebuild machines, but a real person targetting you/your enterprise in particular can be much worse.
Obviously doesn't help with preventing existing flaws, but if a software company or developer is any good, they'll use the information to build better software in the future and to see where most of the holes orginate and maybe spend some extra time testing. It will at least fix large holes that can be fixed, and may alert users to stay away from products that consistently have security issues.
Security is almost impossible to build into an application after the fact, especially if security wasn't even considered during the development of a product. You can't learn from past mistakes, though, if they are not documented and studied.
In principle, I agree that automatically installing patches is a good thing in principle. But Microsoft has a habbit of changing their licenses and installing DRM when people "upgrade" and/or "install patches."
Also, imagine I have 2 programs. Both automatically install patches. Unpatched they both work fine. But when program #1 is patched, program #2 cannot run at all. Now this will probably be fixed eventually, but in the mean-time, I cannot run program #2 at all. If I need both programs, I'm fucked with the system of auto-patches.
However when I have a choice, how likely am I to install a patch? Not as likely (due to laziness). So the effectiveness decreases significantly.
Just read the article and have to point out a number of flaws in the methodology. First- it assumes that if the vulnerability is only known to a few then the number of intrustions will be low. Given the number of zombie computers out there, I do not think that is a safe assumption. Look at how the last few big viruses went around. I know those were exploiting known and patched vulnerabilities, but there is nothing to say that the same thing couldn't be done with a "day-zero" exploit.
Second- it doesn't address the level of the vulnerability. If it is an exploit that lets someone take over a machine, or format a drive, the cost of even those first, possibly limited, intrusions will be astronomical.
FYI FWIW: If you want to link to the Slashdot Nigritude Ultramarine artcile you need to link to the archived URL as done here.
Hulk SMASH Celiac Disease
Is it important to find security holes? Do you care if a hacker exploits a vulnerability to make their vote count more than yours? Do you like your kids to play in the same sandbox that cats defecate in?
Unless the software is to be used only by you or is in a protected 'sandbox', it needs to be as secure as possible.
Live wrong, impostor.
What kind of fool asks such a question?
Until people learn how to write completely secure software we will have to fix the holes.
Not that it's very likely to happen anytime soon.
Sounds like one of those nutty ideas coming from psychs - did I hit you or did you run into my closed fist?
True it's relative, but you going to have to be REALLY stupid to not get it. Same thing with this question. Whoever even let it get posted is equally dumb. What a waste of time!
I hate loading Adobe's bloatware... I meant to post as AC anyways. Damn... lay off.
Hmmm.
No, it's a pointless waste of time. We'll never catch them all, so why bother trying? I think Homer sums it up best: "ou tried your best and you failed miserably. The lesson is 'never try'."
-------
"Every artist is a cannibal, every poet is a thief."
Morally, finding security holes has to be done. It doesn't matter what the percieved quality improvement is.
But instead of trying to plug the holes, it's better to understand why the holes pop up and what we can do to alter the behavior that leads to holes.
[insert plug for your favorite high level language here]
But even better development tools only gets you so far. The burden has to be laid square on the shoulders of the project leader and their managerial counterparts. You cannot continue to do the business side "favors" by including some technically unnecesary component after the specs and requirements are done, and expect it to get integrated seamlessly and without effecting everything else. once you say "yes" to something, it will be harder to say "no" the next time. Maybe you need to understand the business problem you are trying to solve better before you finish the design. Maybe the business folks need to better understand the development process, so they know they can't add features late in the game.
this is just my "2 years in the system" view of things, after time and again getting an email saying "so-and-so wants such-and-such done to this thing" after the thing's design has already been settled upon. when i ask why, it always comes down to someone not being able (yay office politics) to say no to someone for some reason or another.
want fewer security holes? start with better communication between different groups. end with a written in stone spec. leave out all feature creep until the next design phase.
good luck with that! ha!
The problem I can see in this paper is that it makes certain assumptions about the behaviour of black hat hackers which aren't necessarily true. The majority of vulnerabilities discovered by black hat hackers are eventually leaked from the hacker community to a white hat which will seek a solution to the problem. But there's no reason to conclude that this is true of all vulnerabilities.
I forget the terminology for it, but there's the concept of worms that are launched on a large number of vulnerable machines simultaneously. I'm not aware of an attack like this in the wild but it's theoretically possible and would be terribly destructive. If a black hat hacker plays his cards right, he can probably sneak his exploit onto a few thousand computers without anybody noticing. Then he can launch a massive attack before anybody even knows the vulnerability exists.
Having said that I think that, in the real world, the amount of effort put into finding vulnerabilities by white hats has a minimal cost. There's essentially three areas where security vulnerabilities are discovered by the friendlies:
1) QA of the product developers
2) Hobbyist white hats
3) Network security auditing
The cost of #1 is an assumed cost of any product and is part of the basics of releasing it to the public. You check for typos in the documentation and you check for security bugs.
The cost of #2 is zero because it's people doing these things on their own time for their own amusement.
The cost of #3 is substantial but it's critically important to some businesses to have zero security vulnerabilities. A security breach not only has an immediate cost in time to fix the problem, but it also has a long term cost by damaging the integrity of the company. If your bank got hacked and you lost all your savings, even if it was insured, would you keep your money in that bank?
This sig has been temporarily disconnected or is no longer in service
'confronting terrorist supporting countries only serves as a more valuable recruiting tool for organizations such as al queda'
In the long term, one might hope that the vulnerability finding would feed back into software engineering, and eventually decrease the rate of introduction, but we're clearly not there today, and I'm not holding my breath for tomorrow.
So we've got 18 pages of math measuring an irrelevancy.
I'm less likely to read a PDF then a HTML file.
I hate PDF.
Someone finds a buffer overflow problem. Someone finds another one. Someone finds another one. Someone finds another one.
Someone realizes: "what if I centralized all my buffer routines and just got one little section of code working perfectly?" Then you get projects like qmail or vsftp, which simply are more secure. Then people start using these programs, and their systems really are less vulnerable.
This paper looks keeps using the phrase "given piece of software." It's talking about (lack of) improvements at a micro-scale, but ignores improvements in the big picture that can happen due to people getting fed up or scared.
If vulnerabilities were not discovered, would anyone bother to develop secure software?
I think this paper has as an underlying assumption, the popular view that it just isn't possible to write secure software, and that every large software system is just a big leaky sieve that requires perpetual patching. I don't accept that. I understand why the belief is widely held: most popular software was not originally written with security issues in mind. But this is something that will be overcome with time, as legacies die off.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
you can plug all the individual holes you want, it is still a crappy designed dam.
/me goes back to condeming the world to doom
if it designed differently, the number of cracks is smaller...
i wish reporters understood that. flame MS for not bringing lonhorn out sooner. XP is not good enough. everyone knows this, nobody in the popular press is saying it in the right way.
*sigh*
So should architects stop doing structural analysis? Should car manufacturer's quit doing crash tests? I think the point of any kind of design or product analysis is to verify that it is robust and reliable. Why should it be any different for software?
There is no bug in the code of which I wish to add one to a variable:
More than 80% of the programmer will agree with me that it is possible to write a perfect program (provided that such a problem statement is carefully written).The rest of the 20% can go take a hike. :-P
The study sheds light into a little studied phenomenon, and therefor shows interesting facts. It shows that the difference between black-hat-discovery and white-hat-discovery basically reduces to the number of exploits between discovery and public disclosure of a bug, which is negible compared to the total number of exploits during the lifecycle of a bug.
That may hold true and make sense if you study the total number of exploitable systems on the net, but totally ignores the fact that there are a very large number of systems with little priority for security while only a few depend on 100% system security.
Those few high security sites have the need and pay for resources to fix known flaws or patch their software asap. It are those who gain from the knowledge of a security flaw before the black-hat guys do. They cannot live with even the shortest vulnerability timeframes and usually patch exploits as soon as they get published on public security channels.
It may hold true that the work put into security auditing does not pay out on whole, taking all software users into account, but for those few who really care about security it surely does...
I think the story raises a good point. The best analogy I could pint out would be a dam where new leaks keep popping up and you quickly rush to patch them. You spend so much time patching over the leaks that the fundamental design problems in the dam are never fixed. :p
There are multiple strategies that will actually improve security far more than just trying to ferret out a new vulnerability. I personally recommend using Java or another type-safe language for programming if at all possible since the most common memory management errors are eliminated. Hoevwer, the best way to stop major security breaches is to have a security layer that will assume software programs will be compromised somehow. Then, the security layer is more interested in enforcing access to the system that program ought to have instead of just trusting the effective user ID of the program to hopefully do the right thing.
A bit of karma-whoring here for my thesis project which is based on earlier work in Mandatory Access Controls in Linux, as well as the much more well-known SELinux
kernel modules.
I personally did my thesis in Domain & Type Enforcment which simply puts running processes into various different domains that have certain access rights to Types. A type is just a name tag assigned to files, and in my case you can also type system calls, network sockets, and eventually even Linux capabilities. It is similar to part of SELinux but also designed to be much simpler to understand & implement as well.
Anyway, these systems all are designed with the assumption that vital processes will be compromised and the onus is on the policy writers to enforce least-privilege on the processes. This may sound difficult to do, but it is actually trivial compared to the approach we are using now which is to try and figure out every possible attack and write perfect software (the point of the article). It is much easier to define what a program is supposed to do than every nasty malicious thing someone on the Internet can dream up that it should not do.
I've ranted long enough, but I think that there are good solutions to stopping about 90% of the crap that we see going on today, and that the other 10% will be fun to keep us security professionals employed
AntiFA: An abbreviation for Anti First Amendment.
"It doesn't look like we're making much of a dent in the overall number of vulnerabilities in the software we use."
Oh ok Mr. Microsoft, let's just them pile up instead of taking care of them so that new ones don't bury us.
"To err is human, to forgive divine, to persist devilish" at least I think that's the quote...
But what we need to keep in mind is that no matter how hard we try our code is never going to be completely perfect. It's in our nature. I think finding security holes in software is necessary to build on our understanding of security flaws.
Marvellous young ladies those Securicor guards.
I'll move to a browser that people don't exploit as much. One of the big reasons I use Mozilla is for security. Security through obscurity doesn't work, unless no-one knows about the program/not enough users use it to make exploiting vulnerabilities productive.
The parent is exactly right. Having read through this paper now, I realize what it misses: the economic impact of the information.
Much work has been done in economics regarding the affect that inadequate information flow has on a market; a Nobel Prize was wone in it lately. The paper assumes that there are a constant number of vulnerable machines, as you can see on page 2, for any given vulnerability. First of all, it ignores the fact that someone has to choose to use these vulnerable products. Second, it ignores the choice that comes to sysadmins when they learn that a particular company's products are more likely to have bugs, as the parent describes.
The moral of the story is, the paper tries to be more broad than it can - by assuming that software acquisition decisions never happen, it fails to see the effect of vulnerability disclosure on these decisions. And these decisions, made well, do in fact make us more secure. The "software defect rate" in total might not decrease, but the defect rate in *used* software may well decrease.
|/usr/games/fortune
if the patch breaks an application and the machine goes unpatched there is a loss in security because of potential intrusion. If the patch is applied there is a potential loss of productivity.
Not all patches are security patches. Many patches fix problems, such as the spell check function doesn't work correctly. Or some other function doesn't work correctly. These won't compromise security, but they may interfere with other programs.
This is akin to Don Rumsfeld's claim that the media is at fault for the torture in U.S. run Iraqi prison camps. Just because you don't know about it doesn't mean it's not there.
I read this article just yesterday in network mag and I have to say I was astounded at it's conclusions.
.."
I have zero issues with the authors suggestion that vuln reporting may not be resulting in better or more secure software. All software is pretty much market driven. Whether for profit or free users want more and more features and they want them ever faster. Developers in all camps respond to that market pressure by churning out releases in attempt to just keep close to what the users are demanding. If they fail to do so they face irrelevancy. Is this good or acceptable? No but it's a reality. The only workable fix is to find some way to enable developers to produce better code with enhanced toolsets which have been put together with secure code in mind and perhaps with better testing methodologies and tools.
Part of the article however strays beyond looking at the state of software and what disclosure has brought to the table. In my opinion the author is suggesting that disclosure isn't bringing any benefit to the table and that's where we part company. The article is fraught with statements similar to 'As far as I know it wasn't independantly exploited.' That's meaningless. Totally. As far as he knows and we all know it may well have been exploited independantly and for a number of years just that the exploitation was kept secret for ill purpose and it wasn't used for the juvenile purpose of worm writing. The lack of knowledge about whether a security vuln is exploited is not proof or even suggestion that it's not. There have been any number of 0 day exploits and underground exploits over the years.
"It might be better if vendors applied fixes in the next release or
That certainly won't slow down those who do know about the exploit if they're so inclined. It also only protects me if and when the vendor gets around to fixing it. As the author used MS I will too in that recent patches have fixed holes known for 10 months, there are still over 20 unpatched IE vulns... The maybe we just be quiet and trust in the vendor comment just doesn't cut it in that scenario. And that's not to pick on MS. I wouldn't trust any vendor to have my company's best interests in mind before their own. Yes they consider their clients as a whole but only insofar as would something cause them to enough customers to be of a concern.
I'm hired to manage the IT operation in this organization and to just pass it off is a dereliction both to my employer and in turn our customers. In order to do what I was put in place for I need information and those who suggest keeping mum is a good way are, in my opinion out to lunch.
There is a fine line that could be tread in terms of the amount of detail to be released. I concede that. Working exploits or POC's may be too much. May not....
Anyway I'm beginning to ramble and it's time to get back to work.... But the author should have stuck with the basic premise of whether disclosure is improving quality. Bringing in disclosure is a topic which his measurements does not address. In rebuttal I'll argue that while his study indicates that there hasn't been a measurable drop in software issues so far that there will be a positive result in future as more choice becomes available to the consumer. Those companies who are plagued with security issue after issue will gradually find themselves losing market share to higher quality products as the public becomes more aware. And they are more aware. Each year I get more employees seeking alternatives to the problems they're having with their home systems and questioning why we're using certain products in a work environment (which I am so glad to see).
In an ideal world, the resources that go into developing means to attack and to defend would not be necessary.
Likewise, computer security.
You can let others find security holes, but if you don't at least keep up on the technology then over time you end up in a position of greater vulnerability to disruption from attack.
"Provided by the management for your protection."
Take a sinking boat. If you are bailing water out, and the boat isn't sinking any more, it does not follow that bailing water isn't a good idea. If you stop bailing water, you're sunk. If good guys stop finding and fixing vulnerabilities, you're sunk, too.
I know I'd feel much better if only the blackhats were looking for and exploiting security vulnerabilities. If the whitehats don't look for them, publish them and give the vendors/developers incentive to do something about it, then any response to an attack is purely reactive. Welcome to the world where every system is a zombie. In fact, it would soon be duelling zombies. Wouldn't that be great!
Nope, unfortunately Darwinian selection is now going to start applying to software and computers. Bandages aren't going to help at this point.
Comment removed based on user account deletion
Don't mention problem you don't know how to fix...
who conscientiously look for reports to protect their systems. I'm thinking sysadmins would rely on these heavily.
If reports aren't and patches aren't made the holes will be found and will be reported on in the black-hatter community. If reports aren't made but patches are, some (the smart) people will not install patches without knowing exactly what they are installing (especiallly important for Windows users).
Those who do not look after the security of their systems make that decision. Those who decide to look after their security shouldn't be hindered.
Security is a state of mind, and thus even the thought that software might be faulthy plainly violates your sense of security.
:-)
I sincerely suggest that you hire a security manager to your site and let him get an ulcer instead of you.
This has nothing to do with real security, of course. The best real security improvement would be to code it right the first time.
Anticipating the shitstorm of people lining up to say 'how stupid' without reading the FA, here's a nice little summary.
The paper is not quite as stupid as it sounded by the description, but it misses/ignores a critical flaw in the argument.
His basic premise is that patching is expensive and people don't do it anyway - probably true for the majority of systems. Therefore, he argues, black-hats are alerted to the security holes by the disclosure. He shows that it doesn't really matter whether holes are discovered by black-hats and are fixes are released after the exploit, or discovered by white-hats and exploited after the fix has been released but not applied.
However, his arguments are based on averages. Where he's wrong is that if you have some systems that are simply so valuable that they cannot be comprimised, proactive bug fixing coupled with a manic obsession for patching your system the moment a patch is released is still the best way to stay safe
foo mane padme hum
i've thought for a while that we're going to go full circly and go back to running apps off a server instead of client side
just look at the direction IBM is going with building their web based office suite
just one patch and everyones updated on the fly
Does anyone know if its
possible to make a valgrind skin
to search for security holes ??
You've misread the paper.
I'm measuring the rate at which bugs are found in single program/version pairs. I.e. are we finding an appreciable fraction of the bugs in Window NT 4.0? So, the rate at which (say) MS introduces new bugs in new versions of Windows doesn't affect this measurement.
so we can take advantage ...... ;)
These two items aren't the same thing. Hell, patching security holes doesn't always mean improved security. Of course, it's important to find the issues -- Windows users only patch when there is a worm released for a 6-month-old vulnerability. Take the adodb.stream issue for IE (or whatever it is) that has been a gaping hole for 10 months or so. No worm means no pressure on MSFT to fix it.
/rant off
There needs to be some pressure (monetary, legal, etc) put on developers and companies to quit writing crappy code. Microsoft has succeeded in creating a complex OS integrated web browser that has proved to be a pain in the ass to secure. Large companies need to file lawsuits against MSFT to recover damages related to fixing and securing Windows based operating systems. This is the only language that MSFT speaks. Of course, even if it made it very far in the legal system MSFT would just settle by giving the company reduced pricing for Office and Windows licenses.
Damn it all! Let's go back to paper.
oh its not the shitty software's fault, its those terrorist security researchers!!!
yeh right, i dont believe that, its just a bunch of FUD and nonsense. fact is, somebody would find them eventually, and if its a reputable researcher who finds it at least network/sysadmins like me have a potential heads-up before the first exploits hit. what we need is a combination of things
-longer QA process for OS and vital system software
-faster developement and notification about patches
-a set of established secure coding practices wouldnt hurt(sorta like SELinux+select setup options like encrypted disks and firewalls)
I think the earlier poster had it right that the whole science of computing is still very young, and these sorts of race conditions and reliability/stability problem should be expected at this point, but for us to have any expectation of improvement we mustestablish procedures for handling these sort of things that allow us to continue to improve stuff long-term, rather than always getting eaten up by the short term problems.
just an opinion, but i think this makes sense.
sometimes, i wonder if i'm the only conservative on teh intarweb. ah well, back to mah hogs and warmongerin'....
exceedingly so, in fact. It boils down to a single sentence: /them/ that it's not worth looking for it.)
It's better to find the security hole yourself and fix it than for someone with malicious intentions to do so and exploit it.
(And good luck convincing
Work is punishment for failing to procrastinate effectively.
I'd modded him funny.
I don't remember last time I heard this kind of bullshit. I think it was Carl Sagan filling in at the end of some documentary.
His basic theory is that he believes, given the current rates of discovery, poor patching rates and the large number of bugs that:
1) Due to massive information exchange and slow patching/fixing, post announcement explotitations are not significantly less than explotiation caused by un-announced bugs, so announcing does not help.
2) There are so many bugs out there that finding a bug and announcing it does not produce a singificant reduction in the number of "bugs unknown to white Hats" so it does not increase security significantly.
His major errors are ignoring the following: 1) Exploitation post announcement is almost entirely done against the "lesser" computers, i.e. either machines with un-important data/programs (home pc's) or important machines with incompetent sysadmin. As such the real cost of these explotations is either A) practically null, or b) high, but likely to get the incompetent sysadmin fired, resulting in i) better employment prospects for good sysadmin and ii)an over-all improvment in quality of security for that company. So while the # of explots may be higher for Post-announcement bugs, soceity has a REAL social and economic gain that is very significant.
2)A)The announcement of bugs allows people to judge how well written a program is and therefore make an informed decision to NOT buy inferior producs (say Windows).
B)That perhaps our problem is not that we are announcing the bugs but that we are not doing sufficient bug hunting. He seems to be implying that because bug hunts don't find enough bugs, the solution is not to bug hunt. But anyone with a brain should be able to see that if we are not depleating the unknown bugs fast enough than one possible solution is to tremoundously increase our bug hunting, not to stop the bug disclosures.
excitingthingstodo.blogspot.com
Explain how my post was even remotely "pro-Microsoft."
Even if only a small percentage of computer users apply security patches, there is still the benefit of building up a knowledge base about security vulnerabilities. The blackhats are building up such knowledge anyway, we can't prevent that. But the "good side" needs to also build up this knowledge, otherwise the blackhats would soon be so much more knowledgable and skilled than the whitehats that it becomes impossible to set up any machine in a reasonably secure manner.
Under construction: swpat politics overview article
This study akin to saying that we should not have the police because crime still exists or that we should not have fire departments because they don't prevent fires.
.NET and C#. Sticking with C or C++ just does not make any sense when there are viable alternatives on the market. If performance is important then at least use alternatives like cyclone.
People who report security holes are not the same people who code the program. They are like the firemen while the coders are like the home owners. It's up to the coders to make their house fire resistent.
Having said that I am glad people are finally moving away from C, C++ and other unmanaged code. That alone should cut down the secutiry holes by 70%.
I hope the linux programmers take the same kind of Initiative that MS has with
evil is as evil does
A pdf is not inherently worse than a static html page. In fact, a pdf is more server friendly than a static webpage because it inlines its images (i.e. less http requests).
Yes, I can imagine a scenario where the user tried using ps2pdf and got a bloated pdf because all of his text was transformed into bitmaps of the letters. A clueless user could also stick tons of graphics into his pdf or try to stick 100 documents worth of data into one pdf. However, it's possible to make those same mistakes in HTML, so any argument that PDFs are inherently worse on the server are just flamebait.
Crackers will dissect your patches to create exploits, but you'll at least have protection available when the exploits go wild. If they don't find vulnerabilities from the patches, they'll just spend more time trying to find them manually, and the more you leave unpatched, the better the odds they have of finding one. Your customers who care about security the most will install the patches on time, and get pissed if a cracker exploits something before you've patched it.
But it's even better to find them before the product ships, and design early on to avoid the common ones. I believe the author of qmail is still offering thousands of dollars to the first person who finds even a single vulnerability.
One of the key factors that has kept Mainframes secure for so long is the fact they were designed as a secure environment in the first place:
The society for a thought-free internet welcomes you.
In Soviet Russia, Security Holes find you! :)
new ones just keep coming along. What is the point. We cured polio and smallpox, but now we have HIV. We should have left well enough alone.
Maybe it is just me, but I think linking bubonic plague to flea infested rats was a beneficial advancement in progressing the human situation, for multiple reasons.
Although I agree with your points regarding the discovery of exploits and deployment of patches, I believe an issue is still left out. Patches may fix old vulnerabilities but who's to say they can't open up new ones?!? In fact, patches can even break things that used to work correctly!! A patch will never lead to perfect software because exploits are at the heart and essence of the original design.
Unless software is properly designed from the starting moment and implemented with great care in terms of security we still don't have much of a chance when it comes to patches. Sure they'll fix problems for a while, they may even buy us more time, but we can never expect the extra-ordinary from a patch -- by it's very definition ("A piece of code added to software in order to fix a bug, especially as a temporary correction between two releases." from Dictionary.com). Just like in clothing, if a patch doesn't work we can lose more than we were bargaining for -- if the patch on clothing gets ripped off some of the clothing it that connected together will go with it.
Certainly, this article is a total flamebait from michael.
I doubt an ostrich strategy to put head into sand is a winning one, when only benefit is you will not know what did a bite to you.
For every such a software security so-called experts, such as ekr is, I have a question: How much code did you write, actually?
There you are, staring at me again.
Is ekr a pseudonym for Ken Brown?
Finding problems which can be disclosed at the same time as a patch is very good.
All the major Linux distributors will release updates in a timely manner, and enable people to install them with minimum effort - much like Microsoft does. The only difference with Microsoft's patches is they can, rarely, break things. I've never seen this happen with a Linux update.
Personally I've never heard anybody say anything bad about the pro-active way which the OpenBSD team audit their codebase and this is one of the reasons why I started the Debian Security Audit.
Having a dedicated team of people auditing code, combined with the ability to release updates in a timely manner is definately a good thing.
(The results of my work show that even with only a small amount of effort security can be increased)
Did I mention that I'm available for hiring? ;)
Pfffft. Of course finding holes helps improves security.
There's no real evidence you stopped beating your wife is there?
I'm sure i'll catch flack, but i suspect this is a good idea. Of course, it would take legislation or money, or both, and those are two things slashdotters don't like. here it is any way:
Step One: say, CERT or someone else makes a task force whos only job is to constantly audit software for security issue like the OpenBSD people do. All commercial software venders, even Microsoft had to fork over the source to them for audits.
Step Two: said taskforce notifies vender A about security hole b. Vender a then has a certain number of days, say, two weeks, to release the patch. Penalties are dished out for companies who don't patch their software
Step Three: the people who USE the software are given the patch. They then MUST patch the system OR ELSE. Home deployment of Windows or something have to be auto updated. Corporations maybe not so, particularly due to network structures and whatnot. However, if they don't patch the system, then they can';t complaine when their network gets trashed. If another network gets hit after theirs, they are responsible for allowing the virus/worm to propagate.
Putting everything out there in public journals and whatnot and not having any force of law to make companies put patches out ASAP (such as MS who will say "it'll be in the next service pack..." in like, 3 months) makes it so there really is no point in saying anything, when little gets done. h4x0rz churn out exploits faster than companies put out patches because they can get away with the "don't blame us" bullshit in their EULAs. EULAs should also be outlawed.
"A lot of effort goes into funding law enforcement in society, but there's no real evidence that it actually reduces crime. I've been trying to study this problem and the results aren't very encouraging. It doesn't look like we're making much of a dent in the overall number of crimes in our society."
---
If you think security is bad now, just stop fixing security vulnerabilities and see how much worse things get. It's like a sump pump - it may not fix the leak, but it'll keep you from drowning.
It is ALWAYS easier to point out what is wrong than actually fix the problem. The only conclusion that can be drawn from this research is that most people who search/find software vulnerabilities will vote for John Kerry -- they both can identify what's wrong, but have no plan how to fix it. :)
Software security is, in a way, getting better. More holes are being patched and more ways of exploiting security are getting found and publisized (which is good if programmers and sys admins take note).
The real problems are the fact that software doesn't stick around too long. New versions are released with new bugs and holes. They get bigger and more complex which makes it harder and harder to get a good degree of security in any product or model. This would show that security is getting worse. I know I've contradicted what I said earlier but I think both are true. Security in software gets better with every hole fixed, but worse everytime it gets code changed or added.
Sticking your head in the sand and pretending that these problems don't exist because they are not published yet makes no sense. It doesn't make any system any more secure.
If a door on a building is unlocked but no-one know this yet does it make that door secure? No.
Silly rabbit
Most roads have some holes in them. Some would say it is a natural part of the road building process. Other argues roads can be made hole free. Generally roads are thought to be without holes when initially developed, but over time holes are found. While identifying and patching holes in roads is thought to be a good thing, numerical analysis shows otherwise.
Patching roads requires people to stop the flow of traffic, and puts workers at risk of being injured or killed by users of the roads. A road that is fully patched encourages users to drive faster, burning fossil fuels at a lower efficiency compared to the slow speed drivers use when they see holes. Driving slower will also save lives in the event of an accident and cause drivers to pay more attention to the road since they never know when a hole could be in their local path.
Many times the problem is not with the road, but the surface that it is built on. Patching the road can only be assumed to be a stop gap measure at best and will likely have to be patched again. Holes in the supporting structure will almost always show up in the things built on it.
Fixing pot holes slows innovation. Once it becomes accepted that roads have holes in them, consumers will demand vehicles able to deal with them. If hole patching was stopped right now, studies show we would all be flying to work in our personal jetson mobiles within 8 years. Space previously set aside for roads will be converted to trails for bikes, bladers and walkers. Butterflies will land on your outstretched hand while you stop to observe the wild flowers.
Fixing holes only maintains the status quo and dominance of local government and the corrupt DOT branches of the states. If you reduce their budget by even 1% they will go on strike and roads will quickly deteriorate. Some communities out there are leading the charge in not fixing pot holes to bring you a world of glass houses on stilts and talking dogs with jet packs.
In conclusion our findings indicate the DOT should be abolished. They have served their purpose but have no place in todays innovative world.
Not saying that ms has realy great software, but I think people do not give 'em credit where it's due... and realy bash 'em when there is a problem.
Granted that this artical is not talking about stability but never-the-less.....
Vendor Program Vulnerability Count
* Oracle Oracle9i Application Server 20
* Conectiva Linux 20
Microsoft Windows ME 20
* Ipswitch Imail 20
Microsoft Outlook 21
Microsoft OutlookExpress 22
Apple MacOSX 22
* Oracle Oracle9i 23
ISC BIND 25
MIT Kerberos 5 25
* SCO Unixware 26
Slackware Linux 27
KDE KDE 27
Netscape Communicator 27
* Check Point Software Firewall-1 29
Mozilla Bugzilla 29
* Oracle Oracle8i 29
Apache Group Apache 32
Caldera OpenLinux 35
Microsoft Windows XP 36
BSDI BSD/OS 37
* Cisco IOS 38
Microsoft SQL Server 42
Microsoft Windows 95 42
SCO OpenServer 46
Microsoft Windows 98 47
MandrakeSoft Linux 51
Linux Linuxkernel 54
S.u.S.E. Linux 65
OpenBSD OpenBSD 68
Sun SunOS 68
NetBSD NetBSD 70
Debian Linux 88
Microsoft IIS 100
* IBM AIX 122
SGI IRIX 133
Microsoft Windows 2000 134
Microsoft InternetExplorer 140
HP HP-UX 142
FreeBSD FreeBSD 152
Microsoft Windows NT 171
RedHat Linux 183
Sun Solaris 192
* indicates release data not available.
I agree. At the very least, removing the easiest to find exploits increases the difficulty of finding future exploits. The ease and number of exploits in the code give a good indicator of the code quality as well to consumers. Neither point is considered in the "value" proposed here.
Black Hats are dynamic actors -- if the world changes so that Figure 2 in Eric's paper is the norm rather than Figure 1, the Black Hat community will evolve to live in the new world. Their new goal will be to maximize area under the "Private Exploitation" part of Figure 2. We may be better off with the current state of affairs.
You're right. We shouldn't try to investigate murders either, the police don't have a 100% success rate... and even when they do succeed, it doesn't stop them from happening.
As far as I can see, the paper fails to consider liability issues resulting from failing to patch security-related flaws. If an ISP, for example, fails to actively work to protect its systems from intrusion, it would seem likely that they'd be found negligent in cases where harm comes to its customers as a result of such intrusion. If, on the other hand, the same ISP endeavors to keep abreast of security warnings and to do as much as it is able to lock out intruders, one would think they'd be protected to at least some degree from claims of negligence.
On a microscopic level, individual system administrators have a strong personal interest in avoiding having to tell a CIO something like: "I've heard rumors that attacks like the one that just devastated our system might be possible, but nobody ever discovered a particular hole, so I ignored the issue. But look, here's a paper which says that searching for security flaws is probably just a waste of time and money. See? Even though this attack will cost us millions, think of the money we saved in not having to look for holes!"
I'm not surprised that I only saw one person speak up about the language choice for operating systems software. It goes without saying that C is the only natural choice for operating systems software, because of its portability. But I've also noted in my travails that C/C++ leads to a set of problems that are nearly unavoidable--mostly related to memory management and pointers--even with the most careful programming. I'm not convinced it makes the most sense to write applications software in it, though. Sure, it's the fastest language out there, but if you eventually resort to what I describe below, it no longer is...
I have to wonder if it makes sense to seriously expect to find all the vulnerabilities when the language has such an unsafe run time library, and outdated weak type system. It seems that a more sensible approach is to write only a tiny kernel in C which has minimal, but functional, connectivity with the host machine; then have it execute virtual machines (using QEMU?) for all other programs, such that they are totally sandboxed, extremely sandboxed.
I'm talking each app being located in a virtual hard drive, essentially a more extreme chroot, and each app having its own IP address and memory space, so all network activity can be gated or inspected.
Something like QEMU would be a great starting point for a secure OS like this, plus since it does transcoding, it could even make binary distributions of applications portable. Going this way, C apps would run about 4x slower on the same hardware, without considering the process overhead of access management.
Any connection between your reality and mine is purely coincidental.
it will take many software generations to start seeing appreciable results in security.
one of the biggest difficulties is to increase security while simultaneously adding features. once products and operating systems reach a certain level of feature maturity, the ernest improvement of security can happen.
at the same time, the building blocks are getting safer. simply eliminating buffer overflow vulnerabilities greatly strengthens security.
give it time, and keep working toward smarter development practices. software is still young.
.sigs are for post^Hers.
Is that like turned off and locked in a closet secure?
A study of 35 programs is hardly a representative sample. You can't make broad policy conclusions for the entire industry based on this.
Furthermore, the study assumes that all intrusions are equally costly. Script kiddies, while massively prevalent and annoying, don't cost the biggest bucks. Black hats who are professional criminals, working in commercial or governmental espionage, or simply large scale petty theft, can be far more costly to affected parties. It's one thing if a script kiddie hacks your network, and sets all the machines on it to displaying "ALL YOUR BASE ARE BELONG TO US" messsages every 10 minutes; it's quite another when a black hat steals a million credit card numbers from one of your servers.
Given that the latter group has a deeper financial motive and resources to remunerate those with the needed talents, I would hypothesize that many of the exploits in "private exploitation" periods are used by the professionals rather than the kiddies-- which could inflate the costs associated with black hat disclosures substantially.
//Information does not want to be free; it wants to breed.
Is it me or does the article make allot of assumptions that don't really make sense? For instance on page 5 second column when he is talking about the models of vulnerability rediscovery. he says "If reliability does not increase, then the projected number of vulnerabilities is effectively infinite and the probability of rediscovery in any given time period must be very low." I don't think that given a constant increase of vulnerabilities over the lifespan of the software you can presume that the number of vulnerabilities will approach effective infinity. Plus if the vulnerability has been found once there is a greater possibility that it will be rediscovered. Not all vulnerabilities are equally easy to find. Another assumption was that Vulnerability finding is not interdependent. This was another notion that struck me as odd. I would imagine that Vulnerabilities are often interdependent in one way or another. There were many such assumptions I didnt necessarily agree with most are probably not very relevant to the final conclusion. That said I think it is exciting that people treat these questions with any rigor at all. PS did the author consider the effect of giving up trying to find vulnerabilities on the length of time that Bhats will take to let everyone know that they have discovered the vulnerability. IE If the Bhat doesnt expect M$ to self discover the vulnerability he will be cleverer and not blow his load as soon as he discovers a new exploit
Non-System foot or foot error. remove from mouth and strike any key when ready
It's quite hard to compare a status quo to an invisible alternative state -- this is a huge problem in business, politics, and especially economics. But at least I've determined that simply using vulnerability metrics -- i.e. "Finding bugs does not lead to less bugs being found" -- is ultimately not a representative metric for the actual risk mitigated.
To use a straightforward analogy -- possessing an immune system does not by a significant means reduce the pathogenic population, yet lacking one is death. The case is quite similar with vulnerabilities and virii -- it would be very simple for us to completely lack the infrastructure to manage an Internet-wide vulnerability. The low grade malware floating around -- though infuriating -- forces us to create a management infrastructure, on pain of losing connectivity. What the consistent stream of discovered vulnerabilities creates is not fewer vulnerabilities -- software simply isn't mature enough, nor would we really want it to be -- but more managable failures. Put simply, it doesn't matter what this way comes, because we've already been forced to deploy backups, create procedures, and implement recovery strategies.
The alternative state is far more terrifying: Bugs are not talked about, and the strategy is not to fix them but to silence their open researchers. A black market opens up -- it will always be in the benefit of some to have the means to exploit others. These means always work, because nobody defends. Are there fewer with these means? Yes, but one person can write an attack, and the motive to blackmail the entire Internet population (pay me, and I'll "protect" you from the next wave) is quite strong.
Bottom line -- and it's something that took me some time to realize myself, being an active member of the security community who doesn't deal in exploits heavily -- is that whatever the headaches are of full disclosure, the alternative is much worse.
--Dan
That's how I do it - I try to audit all possibly security critical software before beginning to use them. If it looks bad, I go look for another one. And if I can't make sure something is secure, I try to at least make it as safe as possible to use. For example if you crack into my anonymous CVS pserver, you're still not able to modify any of the existing files.
And here's some more old ranting..
... much better to go ahead and have someone else find them for you. That way you don't have to do so much work.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
This paper from 1979 says essentially the same thing - endlessly finding and fixing security holes will not improve the underlying security.
s /a ureview/1979/jan-feb/schell.html
Schell, R.R. Computer security: the Achilles' heel of the electronic Air Force? in Air University Review. January-February 1979, Vol. 30. p. 16-33.
http://www.airpower.maxwell.af.mil/airchronicle
don't say that, otherwise there will be no more IT security jobs!
var sig = function() { sig(); }
A lot of effort goes into finding vulnerabilities in software, but there's no real evidence that it actually improves security.
of course not. fixing vulnerabilities in software is what improves security.
but on a serious note...
i would not necessarily, as the study states, "expect to see noticeable results in terms of improved software quality" due to the discovery or remedy of existing vulnerabilities for the simple reason that technologies that are implemented by software evolve over time. new technologies == new potential for vulnerabilities.
(perhaps a better study would be to identify a static group of technologies and examine the effects of vulnerability disclosure over a finite period of time for those technologies)
also, in terms of publicly disclosed vulnerabilities, it does surprise me a bit that i don't see many resources geared towards preventative coding techniques (within a vulnerability disclosure context). in other words, there are resources that identify and describe vulnerabilities, and provide patches/workarounds for them; there are resources that discuss secure design/coding techniques. but i rarely see the two in a combined format. i think that would be really useful, a way to provide some concrete context (code snippets?) for an abstract description (the nature of some vulnerability).
imagine a resource that provided disclosure of and patches/workarounds for a vulnerability, and then supplmented that with a practical discussion of *why* such and such is a vulnerability, how it can be recognized, and how a developer can recognize symptoms and write code to avoid this kind of problem in the future - in other words, a sort of "design pattern" for how to recognize and/or avoid a vulnerability.
This question could be compared to, "Should we install warning lights and gates at railroad crossings? The alternative is to wait for someone to get killed when there aren't lights and a gate, and then install them... In other words, should we find and fix every vulnerability we can in the hopes of turning out higher quality software, or should we wait for each vulnerability to be used in compromising someone's system before we fix it?
I would say that finding and fixing vulnerabilities probably reduces the number of problems encountered with computers, and the cost associated with those problems. Otherwise, I think there would be so many security holes that all the software out there would be like swiss cheese, and it would take almost no effort at all to break into any system you liked. This is my gut feeling about the issue, but I'll back it up with this thought:
Programmers are at war with 1337 h4x0rz when it comes to security. The more the h4x0rz mess with systems, the more effort the programmers put into securing them. This, in turn, means the h4x0rz need to become more sophisticated, coming up with more involved, obscure, and imaginative ways to break into things. Which, in turn, means the programmers need to become more sophisticated in thwarting these attacks. It's a cycle that requires each side to become increasingly careful in the quality of their work.
You could compare this situation to the war on spam, where the filter software becomes more sophisticated as the spammers do the same; Or the war on viruses, where virus scanners and viruses are getting increasingly sophisticated (or, rather, Microsoft finds an innovative new way to attract viruses because of the secret business deals it probably has with the virus scanning companies), and so on.
The reason you don't see a dent is because as security holes are closed up, the h4x0rz are finding new ways to break into stuff. The idea is to be on the side that finds the vulnerabilities the fastest, and hopefully, that's on the honest side of things. Ooooooooooooooh well.
..would be, would you rather that vulnerability be fixed or exploited on a global scale?
If there are open holes, and someone finds it, if they keep it to themselves, they have nearly unlimited computing/networking potential. If that hole happens to be on the domainant operating system, that's just more machines available. Sell that access to a terrorist, and all of the sudden, all of the computers and networks connected to the internet are suddenly disabled.
I would think fixing security holes are a good thing. Sure, having lots of windows computers with open holes is a problem, but if you provide no way to fix those holes, there will not be a way to solve the impending problem. Imagine if Microsoft decided to not patch the hole the original winnuke exploited. You would still be able to send a packet to a windows machine and crash it.
Why read the article when I can just make up a snap judgement?
3) Data on where bugs are found and how they are found increases the knowledge base of those developing more secure programming techniques, such as preventing overflows (in the manner that e.g. Python and Java do), providing abstractions to do IPC/RPC that prevent exploitation by one of the endpoints, encrypting wire communications, etc.
Over time, these techniques will become more and more widespread and easier to use such that more software will use them. This is a much slower trend than the one the paper analyzes; it will take decades, but its effects will be permanent.
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
Better we should make the code writers and vendors liable when their crappy code fucks up. Better we should push the system beyond its limits until it crashes down and it becomes clear that no one at any point in recognizable history ever gave a shit about quality design with security built in.
We really don't need 432 different kinds of web servers all of which basically suck shit. We need maybe 10 that are reliable. We need the equivalent of a fucking comet to strike the IT Yucatan penninsula so we can kill off this evolutionary tree and start over.
This practice should be encouraged.
Since they enable my access to the information, I mod them informative.
In the most general abstract case, the security of computer systems is undecidable. This result can be proved by showing that deciding the security in the most general case is equivalent to solving the Halting Problem.
However, there are specific systems which can be shown to be secure. A well-known example of a security system that can be proved secure is the Bell-LaPadula multilevel security model.
SOMEBODY will find it.
Anyone that works in a bank or something with a 24x7 production server does not patch unless absolutely necessary.
It's not good business practice to risk your business critical systems to unknown patches except once every year or two.
end user desktops are different.
People's safety concerns for SUVs are not jealousy issues in which we are worried that SUV drivers are safer than us. In fact, SUVs are safer in collisions with other vehicles - but they cause more additional deaths in the other vehicles than the lives they save of SUV occupants. BUT, in terms of fatalities of occupants per mile driven, they are WORSE. Weighty, top-heavy, relatively narrow SUVs are more prone to go out of control on wet roads and especially likely to flip if the steering wheel is turned too quickly or if they hit a guardrail.
s sdisplay.cfm?year=2003&filename=pr32-03.html and http://www.suv.gs/suv-rollover/suv-rollover-fatali ty-risk-suv-controversy.html and http://www.smartmotorist.com/suv/suv.htm or just google for "SUVs accident statistics rollovers" for yourself.
See http://www.nhtsa.dot.gov/nhtsa/announce/press/pre
So, it sounds to me like a selfishness and cowardice issue on the part of the SUV driver - I would rather two other people die in a car to car collision than I die. And then of course you factor in the foolishness issue - in fact, my chances as an SUV driver of dying on the road are higher. It's only my chances of dying in a collision with another car that are lower.
I personally firmly believe SUVs have their place. If you have three kids and a frequent need to haul things, by all means drive an SUV. If you have rough dirt roads or offroading, again - go for it. However, I have serious issues with dealing with the externalized costs of higher pollution, higher risk of accident and higher risk of fatalities from accidents of people who use their giant SUV as a commuting vehicle in congested city driving.
What they're not saying is that funding provided by Microsoft.
For exploit usage in a slow, machine-by-machine fashion, the public exposure will lead to investion and the argument of the paper is sound. However what about black-hat usage in a way that is not visible, like in industrial espionage.
Furthermore, if an exploit is used in a fast worm, the graphs fail to show what happens. Most of the intrusions will happen within minutes, with little or no warning before. There is no private exploit interval.
Bottom line: The economic argumentation is badly flawed and we definitely need to find and patch vulnerabilities!
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
With each disclosure :
- V(found) approaches V(all).
- the time (t) in the vulnerability lifecycle between disclosure and fix release becomes a concrete value = t(fix).
- the cost C(pub) can become a quantifiable value.
As a security professional I am more accurately able to evaluate/assess and manage risk for each V(found), t(fix), and C(pub) given above. Furthermore, for every initial public lack of disclosure (or BHD) and large t(fix) value on critical/costly systems or information, I am able to make more meaningful vendor/product recommendations.
While the paper is well written, contains valid analysis, and provides insight into the disclosure issue, I find section 3.3 to be lacking. The author's conclusions and the security industry itself would be strengthened by further work in modeling the range of cost issues due to disclosure for various commercial industries, educational institutions, and government establishments.
In my professional experience, the sum of knowledge I gain from disclosure details provides defensive strength.
=jombee
Processors/systems need to be made less vulnerable, so that common software mistakes can't let users run their own code.
The No-Execute bit is a start. Moving all return and function pointers to a separate stack would be another improvement. Still ways to hack around that, but it's a lot harder.
HEY ... the MOD-DOWN into oblivion was a bit harsh - all I was doing was correcting the parent who included a link to the N-U contest. I agree that N-U is off-topic for the article subject, but the comment I made (with URL to slashdot itself) was was an on-topic correction to the off-topic comment! ;-)
Hulk SMASH Celiac Disease
*sound like Wakko* /."
"Time for another good idea, bad idea.
good idea: post PDF online to save time
bad idea: have the PDF get
"good idea: finding security holes and patching them before the word goes out to the public
bad idea: finding security holes and let script kiddies cause billions of $$ of damage before patching them"
Oh, and another thought regarding auto-patches... First, you can ALWAYS give user a choice to turn the damn feature off instead of incessantly debating on it's usefulness. Second, at big corporate sites, updates are examed by IT first, then issued, so plenty of problems will still be there even if auto-patch is implemented.
The study is about the costs to society as a whole.
There are vulnerabilities in programs. That's a fact. Finding them has costs. Fixing them has costs. Disclosing them has costs.
The question is whether these costs are higher than the costs for vulnerabilities that are found by blackhats and only examined and fixed after exploitation by them.
The study showed that because the number of vulnerabilities does at best decline very slowly, there are no measurable benefits of investing resources into finding an fixing them.
The major problem is that from the data in the vulnerability database used for the study, it is apparent that the security of software as a whole does not improve with time.
The study essentially proved conventional wisdom among programmers:"Every non-trivial piece of code contains at least one bug."
This means that 2 years ago there were critical vulnerabilities in the software on your computer, today there are critical vulnerabilities in the software on your computer. In 2 years there will be critical vulnerabilities in the software on your computer. In 20 years there will be critical vulnerabilities in the software on your computer.
We will never reach a point in time at which your computer is safer from intrusion than it is today or was 2 years ago.
That's actually quite intuitive. Software is not static. It gets new features or is replaced in whole or in part. The Linux 2.6 kernel has little in common with Linux 1.0. Linux 2.6 IS NOT a bugfixed version of Linux 1.0. There is no reason why it should have fewer vulnerabilities than 1.0. Likewise Linux 3.0 will not be a bugfixed version of 2.6, but a mostly different piece of software and again there is no reason to expect Linux 3.0 will have fewer vulnerabilities than 2.6. The vulnerabilities will be different (e.g. in drivers for hardware that doesn't even exist today), but there won't be fewer of them.
Because of this, all the resources you invest in finding and fixing vulnerabilities are basically wasted, because they will never result in a system without critical vulnerabilities. This means your system will always be open to exploitation.
The study suggests that if you have X resources to spend on security, you should spend NONE of these resources on white hat finding, disclosing or fixing of vulnerabilities that are not being actively exploited. Instead you should spend the money on other things such as
a) fixing systems fast after exploitation has started
b) improving overall security through user education (better passwords, surfing with ActiveScripting disabled,...)
Now compare the following scenarios:
Reality) Lots of Windows vulnerabilities found and disclosed by whitehats. Patches released slowly. People do not apply patches, do not use restrictive browser settings and act generally ignorant of any danger.
Alternative) No whitehat search for or disclosure or fixing of Windows vulnerabilities until exploitation of a vulnerability is detected. If active exploitation occurs, patch is released very quickly. People are educated about security, apply patches quickly and use restrictive browser settings.
Which scenario do you think has the lower costs for society?
Of course we would like to have the best of both scenarios, but as always we have only X resources to spend and X<infinity.
Of course this in no way defends Microsoft. The problem with Microsoft is that for them X=0. They spend resources on neither whitehat discovery/fixing/patching of vulnerabilities nor on other security improvements. If they had a reasonable value X of resources spent on security, they could say "We prefer to spend all of our X on user education, safer software defaults, etc. and none of our X on finding/disclosing/fixing vulnerabilities that are not already being exploited." and the study would confirm they'd be doing the right thing. But unfortunately Microsoft does not allocate a reasonable amount X of resources for security, so they are not in the position of claiming that they're setting their priorities about spending X correctly.
I think I speak for everybody when I say WHO THE FUCK CARES? Out of curiousity, I went to her website. She is not attractive and all the "content" is so retarded that it could be created by 1 monkey at 1 typewriter. If it were between her and a cow, I'd fuck the cow. Now, please shut the fuck up and stop writing shit about her. Nobody fucking cares, so you are wasting your time. In fact, a better use of your time would be to slit your wrists so that nobody ever has to read your shit again. Please fuck off and die, preferably painfully, in a deep pit of sorrow and despair. KTHXBYE!
A real architecture security hole - who designed this place?
I like your analogy. My thoughts were much the same as yours. Aparently this joker wants us to use the Homer Simpson/Microsoft security system. 'If I cover my eyes, and plug my ears, then there is no problem because someone would have told me.'
First of all, paper makes an assumption that a vulnerability found by black hats will soon become known to white hats because white hats have "connections" and because of the intrusion analysis. However if "connections" played any significant role in it, white hats would only become aware of the vulnerabilities after a large percentage of black hats will -- at this point the vulnerability exploitation rate (as a percentage of vulnerable targets exploited per time) may be just as bad as if it was disclosed to the general public, however the percentage of potential targets being vulnerable would remain at 100%, so overall exploitation rate of _potential_ targets can be higher than at any time after the disclosure.
I doubt that this is what happens often, or we would have much higher intrusion rate than what is observed, and many detected intrusions would have unexplained cause until the moment of disclosure. What is observed now, overwhelming majority of intrusions are immediately attributed to a known vulnerability.
Another cause mentioned is the intrusion analysis. This kinda makes sense -- an intrusion taking place in a conditions of a monitored system is likely to be discovered and analyzed. The problem is, the information that can be taken from this, may require more effort to analyze than the proactive analysis of the target software itself, and the probability of security researcher being at the right place at right time is low. One exception is worms and viruses -- after the release they quickly multiply, and likely reach all white hats almost at once, giving plenty of information for analysis, and many opportunities for repeated observations. However viruses and worms do not behave in a manner that is described in the article, they often create a huge outbreak that lasts a very short time when most of the damage is made, and the rate of exploitation only declines some time after the disclosure. In some cases, such as the Witty worm, all exploitation lasts a short amount of time because exploitation destroys the targets. Then when the white hat gets enough information to determine the vulnerability being exploited, likely the epidemy is nearing its peak. Another interesting thing about worms is that most of them are made against _disclosed_ and _patched_ vulnerabilities, and they still cause large amounts of damage. If there will be a large number of undisclosed vulnerabilities, it's likely that worms would take even longer time from the moment of release to the patching of the large percentage of the boxes, thus multiplying the amount of damage done over that time.
So even though post-intrusion analysis does give white hats and the vendor the opportunity to release disclosure and fix, relying on this model would give black hats, and especially worms and viruses, huge opportunities to exploit larger numbers of targets.
What usually happens, is a combination of post-intrusion analysis and proactive search for vulnerabilities. If it is known (or rumored) that a particular incident involved some software, but the information for analysis is limited, it may make sense to leave the incident alone, and focus on studying a particular piece of software (or multiple candidates for the exploited piece of software), and look for vulnerabilities there. Of course, the article lists "pieces of software" as giant lumps such as "Red Hat Vx.x" or "NT 4.0" mixed with small things like BIND, completely ignoring the fact that Red Hat consists of hundreds of identifiable pieces, each with separate sets of bugs, their severity, and those pieces are identifiable in the post-intrusion analysis, and BIND is merely a widely used notoriously bug-ridden program.
Abandoning the proactive search for vulnerabilities would also reduce the possibilities of this kind of analysis, both involve the same techniques, and require the same skills.
Second, the paper assumes that the cost of patching is high, and cost of producing patch is ignored. While cost of patching may be high in some configurations an
Contrary to the popular belief, there indeed is no God.
It's a fantastic idea, ;P
If it wasn't done by Security Experts / Security Groups then only the 'Blackhats' (cringe) would be doing it.
Like we've just seen with the recent '0hday' IE exploit, if you don't someone else will, and they'll use it for evil
I apologize for not reading the entire paper, but I felt that the simplifications of the probability of rediscovery weren't valid. Up to that point, the analysis was impeccable.
As I understand it, the assumption was that the probability of rediscovery of a discovered vulnerability (by a WH) could not exceed the probability that it be discovered, which is defined as the ratio of holes that will ever be found to the total number of holes in the system. This is a valid assumption if you are assuming that each attempt to discover a vulnerability is a coin flip and that all of the coins are equally weighted. The catch here is that the probability of discovery of this particular hole *that you just discovered* is one. (Strictly speaking, it's not even a probability anymore, it's a certainty.) Therefore, using the first part of the assumption, the upper limit of the probability of rediscovery of a discovered vulnerability is always one.
At this point in the analysis, if the probability of rediscovery is assumed to approximate the probability (certainty) of discovery of this particular vulnerability, the equation would favor WHD for all holes where the cost of private exploitation exceeeds zero. Note that the author did not suggest that the probability of rediscovery would approximate that of discovery, only that it was limited by it.
Going beyond the simple raw analysis and trudging hopelessly into the land of my opinion, the overwhelmingly likely situation is that some holes are easier to find than others. Therefore, the likelihood of rediscovery of a discovered hole is likely much higher than the ratio of holes that will be found to the total number of holes. Unless you've managed to discover a hole that was extremely unlikely to discover in the first place, the likelihood of rediscovery is very likely close enough to one to approximate as one.
As I said, I didn't continue the article after the discussion of the upper limit of the probability of rediscovery. My apologies if this was amply accounted for later in the article.
emerge -UD world
And yes, I am a Gentoo zealot...
There is an assumption that appears to be raison d'etre for this article, and I think that it is a flawed one. Patching security holes in software is not done for the welfare of its users -- it merely keeps the software alive so that we can continue to use it (and it is a losing battle). Most security problems are remedied with quick patches rather than the rearchitecture necessary to make certain kinds of flaws impossible instead of improbable. This statement should not be interpreted as an attack on the maintainers of software, rather, I would prefer that it be viewed as a lament over the software creator-user dynamic that exists today. Users are riding leaky boats at sea -- they can't very well leap into the water while we make proper repairs, so we merely patch the holes. The sad fact is that, eventually, the boat sinks into the waves. Until user expectations change, software creators will use the practices that encourage these sorts of defects. Assurance of quality begins with the management of expectations.
Can you prove a negative? That's whay this guy is asking in a way. The real question is "What is the cost of NOT finding security holes?" Lots of evidence for that!
ever do their own work anymore? geez.
The vast majority of security holes are buffer overflows, format string vulnerabilities, and cross site scripting vulnerabilities. All of these are language "features". Using better languages would solve a large part of the problem.
Please correct me if I got my facts wrong.
In the nicest possible way, this study is useless. People will *never* stop finding security holes, therefore there is no option for discussion. Just like biological viruses will never decide to stop infecting. We should concentrate our efforts on solutions, not re-iterating the problem.
I think that the thing he's missing is that some black hats are more dangerous than others. Some of them craft the tools, while others just know how to run Uberhack 2.1.
In particular, any black hat competent enough to discover a serious vulneurability is likely to know how to exploit it properly. He'll know that you don't want to crash or mirror your pr0n v1d30z onto the compromised box--you want to be patient, sniff network traffic, grab encryption keys and passwords, hold the machine in reserve for DDoS attacks or for masking your identity when trying to crack other targets. The friends they disclose the vulneurability to will likely be the same way.
A black hat discovery is much, much, much more dangerous than a white-hat discovery, because the sort of black hats who would find out about a vulneurability before it went public are exactly the sort that you don't want having a back door into every box on the Internet.
Hey, you try to find an open nick these days!
you could even assert that pdf is better due to less people being willing to click a linx to a pdf which would lower http requests even further.
P
Humans are slow, innaccurate, and brilliant; computers are fast, acurrate, and dumb; together they are unbeatable
The author is naive enough to not have considered the Grey Hat Discovery (GHD) of vulnerabilities where the hackers (not being a black hat) do not go on a private exploitation spree, because most people don't want to violate laws and end up in prison, but definitely want to make a big name for themselves, so publish the vulnerability without giving the chance to the Vendor to fix the problem before public disclosure. The percentage of grey hats is enormous compared to both white and black hats, so most of the arguments in this paper are based on a WEAK Foundation of practical reality. This changes many mathematical equations in the article, and lead to significantly different final conclusions. Contact me if you need more specific details.
I've been expecting someone to compromise the update distribution system for years. The moment that happens, every single auto-patch system is toast.
This applies to all operating system with automated update systems, but I'm really been expecting to see a problem with the MS system. It's just too tempting.
plus-good, double-plus-good
Is that a joke?
"I read the paper..." ;-)
And what if someone find a security hole in the automated installation system and exploits it to install backdoors or trojans?
Ok. Face it. The script kiddies are going to find security holes eventually. Do the math. They have virtually unlimited time. For legitimate security researchers, its ALWAYS a race against the clock.
Some of the kiddies will release exploits publicly, some won't. Its quite possible with any exploit that someone has known about it for a signifigant amount of time. Depending on how inteligantly they make use of that knowledge, its possible to abuse an undisclosed exploit for a long, long time.
Face it, most systems aren't monitored by an IDS. Most users aren't logging traffic. Most users don't have to forensics knowledge to determine how they got compromised, hell most of them don't even bother to patch. They just reformat and start over, or worse, keep using the compromised system because they can't stand losing their mp3s or their email from aunt sally, are too incompetent to know how to back up the data they care about, and are too lazy to learn.
Until a scriptkiddie attacks someone who cares, or someone independantly discovers the same thing, they can keep using their exploit on as many systems as they like, for purposes such as building larger and larger DDoS armies.
I will gladly loose all of life's battles.. in order to win the war..
At the .edu level, it's more disadvantageous to find security holes and report them. The main reasons for this are simple:
A) the tech department is unlikely to do anything of substance in fixing whatever security hole has been exposed;
B) if the tech department is really adamant about people not exploring for holes in the first place, an individual who discovers a security hole can get in more trouble for reporting it than letting it go.
don't care if it's better to publicize flaws that need fixing or not...I support corporate reputations in the crapper for releasing the flawed software in the first place...especially if they're going to sell me the repairs as part of an "upgrade"...it's been said before but it's still true: if software were cars, the world would be nearly a ghosttown by now...
When all of your wishes have been granted, many of your dreams will be destroyed - Marilyn Manson
In that sense, maybe a comparison of NT 3.51 vs Solaris 2.51 would be more fair, or NT 4 vs Solaris 2.6? But that's a digression.
After those 4 years, we have no data for the the F/OSS OS's chosen. So there's not "open/closed" info available here.
What we do have, is info about 2 8yr-old OSes, and 2 4yr-old OSes. What they all have in common is a little bit of BSD code; they're far more diverse in most aspects, though.
What can we expect to learn from such a comparison?
Author, Shell Scripting : Expert Re
And don't give me any of this crap about being fair and balanced--nobody's buying it. You're clearly upset by people who bash Microsoft.
so it's good to hear there is something like that. But then again, if we were FORCED to download patches, it wouldn't be possible. As for living in 1995, let's see: * Programs crash regularly (anything from office to mozilla) * Its programs are resource hogs * In 2 months I have had my entire harddrive crash completely thanks to Microsoft. I think Microsoft criticizing is warranted. Bashing is the act of immediately saying how bad something is without proof. Criticizing is thought out judgements on something based on facts.
I was very surprised that even a suggestion of not attacking security holes in software is even being considered. Yes we must as software developers seek to design and write better software without security holes. But for those vendors that have known and identified security holes that take a lack luster attitude towards fixing them are aiding in injuring the customer and user base's confidence and creditability towards ecommerce. That would be a very bad thing. Regardsp
Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" -
At some point this may become a legal question. If you make OSes (etc), and you don't make them so they *must* be updated to continue to function, and therefore more secure, and to do so is both feasible and responsible/prudent, do you not then become liable for all the preventable damages caused by others exploiting old loopholes?
Of course, it can be argued that we aren't there yet, that patches break applications too often as yet to be mandated - but time may fix that.
"do not worry about your weaknesses, your enemies are always more than willing to show them to you."
my analysis is not ment to be a trolling, but lets face it; virii, worms, and rootkits are nothing to ignore. i believe your findings require further reasearch.