15 March 2005

CA exposure provokes disclosure debate

Cath Everett

The discovery of multiple serious vulnerabilities in Computer Associates’ enterprise license management software has re-ignited the debate over the ethics of disclosure.

The holes, which were made public by security companies, eEye Digital Security and iDefense, at the start of March, are found in versions 1.53 to 1.61.8 of CA’s License Client and Server applications that run on most widely available operating systems, ranging from Windows to Unix.

This software enables customers to register, manage and track their licenses over the network and is installed by default in most of the vendor’s products. While the server element is generally disabled, the same is not true of the client portion, so as Firas Raouf, chief operating officer of eEye, points out: “It’s a big deal from an enterprise standpoint.”

In fact, Simon Perry, CA’s vice president of security strategy, gives the vulnerability a seven out of ten rating in terms of seriousness and recommends that customers patch their applications as soon as possible. This is especially crucial because as many as six exploits are now available, appearing only days after the vulnerability was announced.

Such exploits enable malicious individuals to gain control of an affected system remotely, which means that they can install a back door or attack it using malware such as worms, although no such incidents have been reported to date.

The first of this exploit code was released by an organisation called the Hat Squad, which describes itself on its web site as providing digital security services such as penetration testing, technical training and consultancy.

But it is the release of this exploit code that generates the most fevered debate over the ethics of disclosure, although most commentators agree that there are many grey areas along the spectrum of partial to full information-sharing.

For example, Raouf takes the view that organisations such as his own are performing a service to the industry by undertaking partial disclosure. Because they alert vendors to any holes in their software before announcing them publicly to give suppliers time to come up with patches, they are the good guys.

"On the exploit side, however, it’s a bit of a different story,” Raouf says. “Full disclosure purists say you need to know about exploits because it helps security companies develop better protection and helps administrators to better detect whether their systems are safe or not.”

But in his opinion, this is “nonsense” as there are currently enough tools and products available on the market to enable administrators to test for vulnerabilities without needing exploit code.

Perry agrees. “To put exploits up as a public service, I don’t think is a legitimate business model. It increases the danger and I don’t see any positive side. To stand up and say you’re providing a public service, you’re either kidding yourself or being hypocritical,” he says.

But Jay Heiser, vice president and director of research at Gartner, takes the argument a step further.

"The mere fact that a vulnerability is known to exist, even if the details are not published, represents a significant piece of information. It provides a significant clue to the hacker community that if they put some reverse-engineering efforts into the code, they will probably be able to exploit it,” he says.

Moreover, he adds, when a patch is published, it provides even more details about the hole. So in his view, “vulnerability disclosure by these so-called researchers has resulted in more harm than good”.

Not so, says Gerhard Eschelbeck, chief technology officer and vice president of engineering at vulnerability management company, Qualys. “You have to make the assumption that the bad guys have the information anyway so releasing information levels the playing field between the good and bad guys. What’s not appropriate, however, is to release exploit code before patches are available,” he says.

As to what organizations can do to protect themselves more effectively, there are various options. The first thing is to establish exactly what software inventory is on the network and how well or not it is patched, before even attempting to undertake regular vulnerability assessment and remediation using one of the many tools on the market.

According to Perry, standardizing on a smaller number of vendors can also be useful because “if you’ve got a very splintered environment, it can be very difficult to understand what you’ve got where. If you’ve got 30 vendors, you’ve probably got 20 to 25 too many,” he advises.

The next stage after vulnerability assessment is to ensure that patching activities are automated as much as possible and are up-to-date and verified. While Eschelbeck acknowledges that patching everything constantly is impossible, he says that Mitre’s new universal scoring system, which was released to vendors a few weeks ago at the RSA conference, should make prioritisation easier.

The aim of the Open Vulnerability Assessment Language initiative, as it was formerly known, was to provide a standardised way for the industry to define vulnerabilities and their seriousness and widespread industry adoption is expected to follow over the coming year.

As for applications that can help, intrusion prevention systems are useful, but a number of start-ups in the US are also developing virtual patching offerings. According to Eschelback, while such software is at least three years away from commercial release, it works by virtualising a patch as soon as it becomes aware of a hole.

"The box is aware of vulnerabilities so it can catch any potential exploits that are targeting the server. It prevents them hitting vulnerable systems by modifying the sequence of attacks so they don’t have any impact. It doesn’t completely eliminate the need for patching, but it’s a good stop gap,” he concludes.

Back to news index