Jumping the Gun on Vulnerability Disclosure

Subject: Security UPDATE, April 2, 2003

********************

Windows & .NET Magazine Security UPDATE--brought to you by Security Administrator, a print newsletter bringing you practical, how-to articles about securing your Windows Server 2003, Windows 2000, and Windows NT systems. http://www.secadministrator.com

1.

IN FOCUS

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

* JUMPING THE GUN ON VULNERABILITY DISCLOSURE

Last week, in my Security UPDATE commentary "Security Research: A Double-Edged Sword," [http://www.secadministrator.com/articles/index.cfm?articleid=38448] I discussed how researchers discover security problems and work with vendors to coordinate information and patch release--to minimize networks' exposure to a given discovery. A recent case in point illustrates how jumping the gun on information disclosure can occur when well-intentioned researchers become impatient.

This past Saturday, while most working people on the planet were enjoying their weekends, a researcher posted a message to the BugTraq mailing list about a vulnerability in Sendmail. As you know, Sendmail is one of the most widely used SMTP mail systems, and although Sendmail was written to run primarily on UNIX systems, various vendors port the code to Windows platforms. The researcher had discovered a problem in Sendmail stemming from insufficient bounds checking during character-to-integer conversions that might lead to a buffer overflow and subsequent compromise of a given Sendmail system.

The researcher had contacted Sendmail.org [http://www.sendmail.org/8.12.9.html] on March 18 about his discovery, and the group replied the following day acknowledging the problem and stating that it would release an updated version of the product. However, if I understand the situation correctly, the updated release was not posted immediately for reasons internal to Sendmail.org, which I assume involve coordinating efforts with third-party vendors and Sendmail software users. When after 11 days (March 29) the new version wasn't posted, the researcher decided to post a notice about the problem to BugTraq, basically stating that he was "forced" to release details of the problem. Again, I assume the researcher's intent was to put pressure on the Sendmail vendor.

With the bug now exposed to the public, Sendmail immediately--on March 29--released its updated product version (8.12.9) and posted a brief comment: "We apologize for releasing this information today (2003-03-29) but we were forced to do so by an e-mail on a public mailing list which contains information about the security flaw." Sendmail wasn't entirely ready to release its updated version, but apparently Sendmail had corrected the problem in the code and had a new version it could release. I don't know the exact reasons for the 11-day delay, but again, I suspect Sendmail needed the time for testing and coordination--because Sendmail is bundled with various OSs.

Jumping the gun in this way is unfortunate. This instance seems to have been the result of a communication breakdown. Could the researcher have exercised more responsibility, patience, and restraint before forcing the vendor's release of updated code by posting information about the bug to the public? Did the researcher consider the potential ramifications of the disclosure--how many others it might affect? Could Sendmail have kept in better touch as time passed, letting the researcher know a projected date of release?

Although this set of events might seem minor to some people, it could lead to severe problems across the Internet for millions of people. What if attackers used the bug to crash mail systems or to take over servers? Such events cost time, money, and frustration, and a discloser might face legal ramifications. Right now, given the state of world affairs, one act--tossing a particular pebble of information into the sea of technology--could potentially cause a tsunami.

On another note, 2 weeks ago in the Security UPDATE commentary "Audit Your Windows Shares" [http://www.secadministrator.com/articles/index.cfm?articleid=38387] I mentioned CERT's notice about several Denial of Service (DoS) programs plaguing Windows systems. What I didn't tell you is that many such DoS programs have incorporated a perfectly legitimate network administration tool, PsExec, which Sysinternals created.

According to the Sysinternals Web site, [http://www.sysinternals.com/ntw2k/freeware/psexec.shtml] "PsExec is a light-weight telnet-replacement that lets you execute processes on other systems, complete with full interactivity for console applications, without having to manually install client software. PsExec's most powerful uses include launching interactive command-prompts on remote systems and remote-enabling tools like IpConfig that otherwise do not have the ability to show information about remote systems." Essentially, you can use PsExec instead of tools such as Telnet or Symantec's pcAnywhere.

Mark Russinovich, cofounder of Sysinternals and author for Windows & .NET Magazine, wrote to remind me about another Sysinternals tool. Although system attackers use PsExec to exploit Windows systems, Sysinternals' ShareEnum program [http://www.sysinternals.com/ntw2k/source/shareenum.shtml] can help users audit their shared resources and tighten security. Doing so can help administrators ensure that intruders will have a hard time inserting DoS programs into users' systems. Be sure to check out ShareEnum, which is available for free (the complete source code is also available).

Corrections to this Article: