How Should Researchers Handle Exploit Code?

By Larry Seltzer  |  Posted 2004-04-29 Print this article Print

While good reasons really do exist for releasing exploit code for security vulnerabilities, there are also good reasons not to. One prominent researcher has given up on publicly releasing exploit code. Perhaps the answer is just to make it harder to get.

Nobody really knows where worm authors go shopping for exploits to develop, but its widely assumed that they are greatly assisted by exploit code released by legitimate researchers. Go look at most vulnerability reports, and youll see references to where exploit code may be obtained. Why would a "legitimate" researcher do such a thing?

If you think about how youd want to run security management at a large organization with some time and budget behind it, its not hard to see how exploit code is valuable. We—meaning vendors and researchers and media—tell you to test patches before installing them on the production network.

Of course, a lot of you would get laughed at by your bosses if you proposed creating a test network, but assume you were testing a patch before deploying it. You would want to test your software with the patch installed to make sure it still worked correctly, but youd also want to test the patch to make sure it worked correctly.
For this, you need exploit code. You could also use it to test workarounds in case you dont want to deploy the patch immediately. Finally, you cant just trust your perimeter defenses, so you need exploit code to run penetration tests, also known as "pentests."

Of course, if youre a malicious "script kiddie" looking to impress your fellow vandals, canned exploit code makes your "job" a lot easier. This was the conclusion of Johnny Cyberpunk, a researcher at The Hackers Choice. Mr. Cyberpunk recently announced that he will "personally not publish any further exploits to the public."

The basic story for Mr. C was that the legitimate uses "didnt work." He doesnt explain how they failed, although he does say many users didnt know how to do the customization necessary to make exploit code work correctly. And he saw too much risk of it being used for untoward purposes.

Next Page: What if a trend develops and exploit code becomes harder for legit people to get?

Larry Seltzer has been writing software for and English about computers ever since—,much to his own amazement—,he graduated from the University of Pennsylvania in 1983.

He was one of the authors of NPL and NPL-R, fourth-generation languages for microcomputers by the now-defunct DeskTop Software Corporation. (Larry is sad to find absolutely no hits on any of these +products on Google.) His work at Desktop Software included programming the UCSD p-System, a virtual machine-based operating system with portable binaries that pre-dated Java by more than 10 years.

For several years, he wrote corporate software for Mathematica Policy Research (they're still in business!) and Chase Econometrics (not so lucky) before being forcibly thrown into the consulting market. He bummed around the Philadelphia consulting and contract-programming scenes for a year or two before taking a job at NSTL (National Software Testing Labs) developing product tests and managing contract testing for the computer industry, governments and publication.

In 1991 Larry moved to Massachusetts to become Technical Director of PC Week Labs (now eWeek Labs). He moved within Ziff Davis to New York in 1994 to run testing at Windows Sources. In 1995, he became Technical Director for Internet product testing at PC Magazine and stayed there till 1998.

Since then, he has been writing for numerous other publications, including Fortune Small Business, Windows 2000 Magazine (now Windows and .NET Magazine), ZDNet and Sam Whitmore's Media Survey.

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel