Security Research: A Double-Edged Sword

Rogue researchers undermine security efforts.

Security UPDATE, Web exclusive, March 26, 2003



(contributed by Mark Joseph Edwards, News Editor, [email protected])


Many people work to discover security risks in software and also to ensure that users aren't unnecessarily exposed to those risks. In the past, researchers often released complete details about security problems and simultaneously notified the public at large about the problems--while everyone awaited the vendor's response, including the production of a patch.

Over the past couple of years, most researchers have changed how they handle the security risks they discover. Currently, most researchers report their findings to the appropriate vendor and give the vendor enough information to create an adequate patch. Researchers typically try to work within vendors' time frames for patch production and customer notification. When vendors aren't responsive enough or completely fail to acknowledge and repair security problems in their products, researchers usually release details about the discovered problems, sometimes accompanied by scathing remarks about the vendors' lackadaisical attitude.

Some time ago, several companies (including but not limited to Microsoft, @stake, Foundstone, Oracle, Internet Security Systems--ISS, Guardent, BindView) teamed together to form the Organization for Internet Safety (OIS). One of OIS's first projects was to draft a specification that includes guidelines to help security researchers and product vendors interact to achieve vulnerability remedies and reporting procedures for public notification.

From what I understand, the specification is close to completion, and it should help researchers--whether independent or not--fine-tune how they handle their discoveries. Security forum operators might also use the guidelines to support a sense of diplomacy and responsibility among today's security researchers.

One team of researchers, CERT, already has a process in place that defines the way the organization handles problems reported to it. CERT works to ensure that vendors know about discovered security problems and coordinates with vendors to release information to the public. CERT and various vendors pass information back and forth and prepare bulletins for public notification.

However, at least one rogue researcher has been undermining CERT's efforts to protect the public at large. Over the past couple of weeks, someone has posted four messages to public discussion forums that leaked sensitive information before CERT had a chance to finish its coordinated process. During the CERT process, someone gained unpublished vulnerability information and anonymously exposed it to potential intruders before vendors had time to finish their coordinated efforts to protect users. You can read about the problem in the "eWeek" story "More CERT Documents Leaked." \[,3959,962679,00.asp\]

I think you'll agree that this behavior is irresponsible, self-centered, and manipulative. The anonymous person who posted the stolen vulnerability information has pledged to continue leaking CERT bulletin data--that is, until CERT finds out who's leaking the information and changes its process to prevent the exploitation. The anonymous person thinks that vulnerability information should be available to potential intruders before administrators have time to patch or modify their systems for better protection.

Such irresponsible activity might eventually place a heavy burden on mailing list operators to better research messages sent to their lists for publication. Right now, security mailing list moderators basically ensure messages are relevant to list topics, and they guide conversation to limit inordinate amounts of fruitless discussion. However, posting on-topic information that any user wants to submit can be a problem, as we see in this matter of publishing vulnerability information leeched from CERT. Such actions place list moderators in a difficult situation because moderators can't always know where or how users obtain their submitted information.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.