Ethical Research Face-off.

Publicated on : 1211641668
Bruce Schneier[3] and Marcus Ranum[2] had a face-off concerning ethical vulnerability research and talking about their opposing views[1]. Since I do not agree with Ranum on this one, I am going to write my arguments under Ranum's text:



COUNTERPOINT by Marcus Ranum



One of the vulnerabilities that was exploited by the Morris worm was a buffer overflow in BSD fingerd(8). Bruce argues that searching out vulnerabilities and exposing them is going to help improve the quality of software, but it obviously has not--the last 20 years of software development (don't call it "engineering," please!) absolutely refutes this position.



Buffer overflows are due to mistakes by programmers by either not knowing how computers work and interact, or by a plain mistake. From a OS vendor standpoint is is very hard -and probably not yet possible on heaps instead of buffers regarding the stated 20 years- to provide protection for the programmers who make the mistake, since they are doing the programming of the buffers in the first place. So you are talking about incapable programmers actually, that are people. People only learn by actually doing it, so programmers learn by programming. You generalize it by taking the worst example of all: buffer overflows.



Not only do we still have buffer overflows, I think it's safe to say there has not been a single category of vulnerabilities definitively eradicated. That's where proponents of vulnerability "research" make a basic mistake: if you want to improve things, you need to search for cures against categories of problems, not individual instances. In general, the state of vulnerability "research" has remained stuck at "look for one more bug in an important piece of software so I can collect my 15 seconds of fame, a 'thank you' note extorted from a vendor, and my cash bounty from the vulnerability market." That's not "research," that's just plain "search."



A lot of hard work has been done to protect browsers, servers, and OS software. You can't say that was useless research because it made you and me safer. As a result, hacking browsers consistently has become very difficult whereas hacking a browser 7 years ago was pretty easy. And how about overflow protection in XP? Sure, can be beaten with heap spraying. But it has become a lot harder. Isn't that progress? The criminals often know as much as the good guys, and maybe more. So the importance of "vulnerability re-search" can not be overstated, since what we all find is probably already known by the bad guys, and that is the whole point. Search or research it creates a safer product for all of us, and in the progress while doing it I think it can be fair to compensate the researcher who spent all of his time into it. He delivers it on a silver platter to your kind of people for free. OK, how about keeping it for ourselves and exploit it on your account? better idea? Still I think it is a great swap: incrementing the researchers ego in return for a safer product, naturally with in mind that not every researcher is in for the fame.



The economics of the vulnerability game don't include "making software better" as one of the options. They do, however, include "making software more expensive." When I started in the software business, 10 percent annual maintenance was considered egregious, but now companies are demanding 20 percent and sometimes 25 percent.



Well, better bitter secure, than sweet insecure I guess.



Why?



The vulnerability game has given vendors a fantastic new way to lock in customers--if you stop buying maintenance and get off the upgrade hamster wheel, you're guaranteed to get reamed by some hack-robot within six months of your software getting out of date.



Depends who the vendor is, free software doesn't have this problem. So it's a useless argument.



One place where Bruce and I agree is on the theory that you need to think in terms of failure modes in order to build something failure-resistant. Or, as Bruce puts it, "think like an attacker." But, really, it's just a matter of understanding failure modes--whether it's an error from a hacking attempt or just a fumble-fingered user, software needs to be able to do the correct thing. That's Program-ming 101: check inputs, fail safely, don't expect the user to read the manual, etc.



agreed.



But we don't need thousands of people who know how to think like bad guys--we need dozens of them at most. New categories of errors don't come along very often--the last big one I remember was Paul Kocher's paper on CPU/timing attacks against public-key exponents. Once he published that, in 1996, the cryptography community added that category of problem to its list of things to worry about and moved on. Why is it that software development doesn't react similarly? Rather than trying to solve, for example, buffer overflows as a category of problem, we've got software giants like Microsoft spending millions trying to track down individual buffer overflows in code to eradicate them.



New categories of problems don't come often, because it takes researchers to come up with them. The same kind of people you seem to despise. And there are a lot of new categories found over the last years, unless you didn't pay attention or did the research yourself. And that's why we cannot coil up into denial.



The biggest mistake people make about the vulnerability game is falling for the ideology that "exposing the problem will help." I can prove to you how wrong that is, simply by pointing to Web 2.0 as an example.



Why do you call it "the vulnerability game" ? I don't because for me it isn't a game. It is dead serious because it affects many people. Exposing a problem always works for the better because you give people the power to protect themselves. It is knowledge that creates freedom and choice, not ignorance.



Has what we've learned about writing software the last 20 years been expressed in the design of Web 2.0? Of course not! It can't even be said to have a "design." If showing people what vulnerabilities can do were going to somehow encourage software developers to be more careful about programming, Web 2.0 would not be happening.



Which design of the Web 2.0? we still work with the same insecure protocols as 30 years ago. Only the appearance changed, the design is still the same. Here you layout the problem correctly because it is a people problem, and a uneducated problem, exactly the message researchers are trying to get across through their research.



Trust model? What's that? The so-called vulnerability "researchers" are already sharpening their knives for the coming feast. If we were really interested in making software more secure, we'd be trying to get the software development environments to facilitate the development of safer code--fix entire categories of bugs at the point of maximum leverage.



isn't that what the bug fixers -programmers- are doing? But it seems to me they do not learn from their mistakes, and make the same mistake over-and-over again in other parts of the software that was affected. It is not up to researchers to define programming guidelines that are already set and ignored by programmers. You said yourself: never trust user input and the likes.



If Bruce's argument is that vulnerability "research" helps teach us how to make better software, it would carry some weight if software were getting better rather than more expensive and complex. In fact, the latter is happening--and it scares me.



Correct, for me it implies hiring better programmers and better software testers before shipping software with gaping holes in them. But that doesn't mean we can't research new vulnerabilities and so I don't see any point it denying it's use then either. It is the choice of the vendor in making it more expensive while it is not mandatory in the first place if programmers are better educated on the subject, for one that can be obtained by reading research white papers. And so my personal conclusion about vulnerability research being ethical or not, I think it is ethical and certainly undervalued. Which probably goes without saying for many who read and understand this.



[1] Face-Off: Is vulnerability research ethical?

[2] http://www.ranum.com/

[3] http://www.schneier.com/blog/