Security Researchers Vulnerable to Buffer Underflow Attack?

It's inevitable: Someone posts proof-of-concept code, and almost immediately someone goes to work developing a malicious exploit. Do these exploiters have nothing better to do, nothing better to think about?

Anyway, as you probably know by this time, a series of new Windows vulnerabilities was recently published in the usual places. And now at least one exploit, the Phel worm, is on the loose. The worm installs code on penetrated systems to open back doors and make those systems part of a Distributed Denial of Service (DDoS) network. The worm infects systems by using inroads through Microsoft Internet Explorer (IE), often without the user's knowledge.

On the surface, these vulnerabilities and exploits might seem to come from opposing forces: On one side are "researchers" who release proof-of-concept code for their discoveries. On the other side are people who turn the proven concept into something malicious for their own nefarious purposes.

The side that puzzles me is the alleged "researchers." Are they suffering some sort of mental buffer underflow attack (i.e., not clearly thinking things through)? They're very adept at finding security vulnerabilities, yet some of them fail to recognize one of the most obvious security problems of all--their own premature public revelations of explicit details of security weaknesses. It's possible that some researchers do see the problem and they simply don't care, which could mean that those particular researchers and the malicious coders are, for all intents and purposes, cohorts playing a dastardly game.

Other researchers make a half-hearted effort to contact a vendor. In one relatively recent case of vulnerability reporting, a researcher claimed that he tried to contact a vendor but couldn't, so he thought it reasonable to release his detailed findings to the public. I happen to use the product in question, so I decided to try to contact the vendor myself. After about 60 seconds of clicking around on the vendor Web site, I found several contacts and emailed them the researcher's findings. Within 24 hours, the vendor emailed me back a solution. I then forwarded the vendor-provided solution to the researcher, who didn't bother to publish it! In this case, a so-called "researcher" could scour code for vulnerabilities, yet couldn't find any contact info for the vendor! Obviously, such researchers aren't really researchers at all. They too play a dastardly game.

On another note, last week I wrote about an incident that involved Microsoft's release of a critical update for Windows Firewall that improves the way in which the firewall handles local subnet restrictions. The update wasn't part of Microsoft's monthly security bulletins. If you missed last week's newsletter, then you can read about the reasons why this happened in the December 29, 2004 Security UPDATE commentary (first URL below) and in the related news story "Critical Update for Windows Firewall Flies Under the Radar" (second URL below).

A reader wrote in response to the commentary that, "The \[Microsoft Baseline Security Analyzer (MBSA)\] for use with SMS 2003 doesn't report the firewall update patch." The reader did add that, in his situation, the lack isn't an issue because he doesn't rely on local subnet restrictions for defining firewall exceptions. Nevertheless, the reader does point out another aspect of notifying users about critical updates that needs better attention from Microsoft.

We posted an Instant Poll question last week that asks, "Do you think Microsoft should improve its security alerting process?" The possible answers are "Yes, it should send alerts about all security updates" and "No, the process works fine for me the way it is." So far, we haven't had a huge flood of people answer the question, but most of those who have answered have said "Yes." If you haven't taken 30 seconds to visit our Web site and answer the question, please do--the poll results will undoubtedly be read by Microsoft and could make a difference in how the company handles its security update alerting process in the future.

That said, I hope you all had pleasant holidays. Best wishes to all of you for the new year, and until next time, have a great week!

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.