Laptops Desktops Monitors & LCDs Graphics Cards Handhelds Phones Software Networks Printers More »
search
advertisement
Click Here
AnchorDesk

Robert Vamosi
My plan for fixing software flaws

Robert Vamosi
Senior Editor, Reviews
Wednesday, October 2, 2002
TalkBack!Add your opinion
One of the mantras from the government's new National Strategy for Securing Cyberspace is "responsible vulnerability disclosure." To me, this phrase is a call for a new set of standards for discovering and patching software vulnerabilities.

Right now, software vendors and security groups are responsible for tackling these security problems. But security researchers who discover flaws don't always give software makers enough time to create patches before disclosing those flaws in public. And can we really expect businesses that compete against each other to solve security problems cooperatively? These groups have yet to reach consensus on the best ways to fix security holes.

What we really need is an independent third party to administer an impartial system of checks and balances.

ABOUT A YEAR AGO, a committee of five software vendors and security researchers put forth their suggestions for vulnerability disclosure in a document drafted by Steve Christey of MITRE and Chris Wysopal of @stake, Inc. Among their proposals: Vendors should acknowledge vulnerabilities sent by security researchers. Vendors should follow up with researchers within 10 days. Vendors should provide updates every seven days. And vendors should resolve the problem within 30 days. This draft was submitted to the Internet Engineering Task Force (IETF), but the organization declined to act, arguing that the proposal was outside its purview.

Now, a new group of vendors, the Organization for Internet Safety (OIS), is taking another stab at the problem. This group is made up of security companies such as @stake, BindView, Foundstone, Guardent, ISS, NAI, and Symantec, as well as software makers such as Caldera International, Microsoft, Oracle, and SGI.

Generally, software vendors want to fix vulnerabilities in their products--but they want to do it quietly. They frequently say that going public with a vulnerability only gives virus writers and hackers an edge. I won't dispute that viruses and worms are often the product of a juicy flaw in Outlook or Internet Explorer. But for Microsoft (or some other software provider) to lecture the security community on "helping the viruses writers" is like President Bush saying any criticism of his Department of Homeland Security is "aiding the terrorists." The distracting rhetoric does nothing to bring the vendors and security researchers into agreement.

FURTHERMORE, security researchers say the software vendors dismiss their claims. Scott Culp of Microsoft admits that his team will check out reported flaws, but if there's no security risk, will not create a patch. That makes sense. One wouldn't want to be patching every little piece of suspect code.

However, vendors often dismiss the vulnerabilities researchers find. The vendor's lack of acknowledgement may cause a researcher to go public out of frustration. And sometimes, long after the vendor has quietly dismissed the flaw, the public will find a very real security risk from it. Within days, an exploit is published on a newsgroup. Within a week, a virus or a worm is created.

A situation like this occurred on June 17, when Internet Security Systems (ISS) went public with a vulnerability in the Apache server software. ISS says it notified Apache of the flaw--but it did so only a few hours before sending out a press release. In justifying its immediate public disclosure, ISS said that only win32 and certain 64-bit platforms were vulnerable.

Yet two days after ISS went public with the Apache vulnerability, another security company, Gobbles Security, took issue with ISS's risk assessment. Gobbles said the vulnerability also affected systems running FreeBSD and OpenBSD, and even provided the source code to Apache-scalp.c, an exploit that works on OpenBSD. Within 11 days of the original ISS vulnerability announcement, a malicious virus author used the Apache-scalp.c exploit to write the Internet worm FreeBSD.Scalper.Worm. Apache has since provided a patch for this flaw.

THIS SITUATION shows why OIS's idea that software vendors and security researchers can produce workable security standards cooperatively is flawed: Both sides have shown in the past they don't work well together.

Instead, researchers and vendors should fund an independent third party to protect the interests of both sides. Security researchers would submit vulnerabilities to the third party, which would test the flaws and report on their results in a timely fashion. This new third party would acknowledge each of the security researchers' contributions and quietly inform the vendor of the possible security risks when necessary. This third party would also keep the vendor honest by requiring a fix within a set amount of time, based on the severity of the vulnerability.

There is an independent security body already: Carnegie-Mellon's CERT Coordination Center. But critics complain that CERT it is too slow to respond. Ideally, a new third party would have enough funding and staff to respond promptly to all inquires.

Of course, the long-term solution is to teach software engineers how to design secure code. OIS is addressing this education issue. But in the meantime, we need someone to mediate disputes between vendors and researchers.

Do you think a third party could help mediate disputes between software makers and security researchers? Do you have any other ideas for how to make software more secure? TalkBack to me!

Previous Story  Next Story 

Special sponsor stores

Virtualization

advertisement
Click Here