January 11, 2010

January promises to be a busy month for Web server and database administrators alike: A security research firm in Russia says it plans to release information about a slew of previously undocumented vulnerabilities in several widely-used commercial software products.

Evgeny Legerov, founder of Moscow based Intevydis, said he intends to publish the information between Jan 11 and Feb 1. The final list of vulnerabilities to be released is still in flux, Legerov said, but it is likely to include vulnerabilities (and in some cases working exploits) in:

-Web servers such as Zeus Web Server, Sun Web Server (pre-authentication buffer overflows);
-Databases, including Mysql (buffer overflows), IBM DB2 (local root vulnerability), Lotus Domino and Informix
-Directory servers, such as Novell eDirectory, Sun Directory and Tivoli Directory.

In an interview with krebsonsecurity.com, Legerov said his position on vulnerability disclosure has evolved over the years.

“After working with the vendors long enough, we’ve come to conclusion that, to put it simply, it is a waste of time. Now, we do not contact with vendors and do not support so-called ‘responsible disclosure’ policy,” Legerov said. For example, he said, “there will be published two years old Realplayer vulnerability soon, which we handled in a responsible way [and] contacted with a vendor.”

At issue is the pesky ethical and practical question of whether airing a software vendor’s dirty laundry (the unpatched security flaws that they know about but haven’t fixed yet) forces the affected vendor to fix the problem faster than it would have had the problem remained a relative secret. There are plenty of examples that show this so-called “full disclosure” approach does in fact prompt vendors to issue patches faster than when privately notified by the researcher and permitted to research and fix the problem on their own schedule. But in this case, Legerov said he has had no contact with the vendors, save for Zeus.com, which he said is likely to ship an update to fix the bug on the day he details the flaw.

Intevydis is among several vulnerability research firms that sell “exploit packs” — or snippets of code that exploit vulnerabilities in widely-used software (others include Gleg, Enable Security, and D2). The company’s exploit packs are designed for users of CANVAS, a commercial software penetration testing tool sold by Miami Beach, Fla. based Immunity, Inc.

While organizations that purchase CANVAS along with exploit packs from these companies may have better protection from newly-discovered security vulnerabilities while waiting for affected vendors to fix the flaws, Immunity does not report the vulnerabilities to the affected vendors (unless the vendors also are customers, in which case they would have access to the information at the same time as all other customers).

That approach stands apart from the likes of TippingPoint‘s Zero-Day Initiative and Verisign‘s iDefense Vulnerability Contributor Program, which pay researchers in exchange for the rights to their vulnerability research. Both ZDI and iDefense also manage the communication with the affected vendors, ship stopgap protection for the vulnerabilities to their customers, and otherwise keep mum on the flaws until the vendor ships an update to fix the bugs.

Legerov said he’s been an anonymous contributor to both programs over the years, and that it is not difficult for good researchers to make between $5,000 and $10,000 a month selling vulnerabilities and exploits to those companies. But he added that he prefers the full disclosure route because “it allows people to publish what they think without being moderated.”

Dmitri Alperovitch, vice president of threat research at McAfee, called Legerov’s planned disclosure “irresponsible,” given the sheer number of businesses that rely on the affected products. Alperovitch said the responsible way to disclose a vulnerability is to send information to the vendor and let them know you plan to release in a reasonable time (usually 60-90 days).

“If they ask for more time  — again, reasonably – not a year out — you try to accommodate. If the vendor doesn’t respond, you release and move on,” he said. “But to give them no advance notice just because some vendors don’t take security seriously is irresponsible.”

Charlie Miller, a former security researcher for the National Security Agency who now heads up the Baltimore based Independent Security Evaluators (and is co-founder of the No More Free Bugs meme) , also has earned tens of thousands of dollars from vulnerability management firms — most famously by competing in ZDI’s Pwn to Own contests, which carry a $10,000 First Prize.

“These programs are good because they allow researchers to get something for their effort, and you don’t have to deal with the back-and-forth with the vendor, which is not fun,” Miller said.

Still, Miller said he’s sympathetic to researchers who react to vendor apathy with full disclosure.

“The thing is, finding critical security bugs in widely used software should be rare if vendors are doing their job. But the sad part is, finding a serious bug in something like Adobe Reader is not a very rare event, and it seems to happen every month almost now,” Miller said. “The conclusion we can draw is that some vendors aren’t doing enough to make their software secure. It should be rare enough that vendors should be so surprised and concerned that they’re willing to do what they need to do to get it fixed.”

Setting the full disclosure debate aside for the moment, it has been fascinating to watch the development of the vulnerability management industry. I can recall a heated panel discussion back in 2006 at the CANSEC West conference in Vancouver, B.C. Canada, in which ZDI and several supporters of that effort took some heat for the program from a number of folks in the security industry.

These days, ZDI and iDefense are responsible for pushing software makers to fix an impressive number of software flaws.  Take Microsoft, for example: By my count, Microsoft fixed approximately 175 security vulnerabilities in its Windows operating systems and other software last year. Of those, the ZDI program is responsible for reporting 32, while iDefense’s program contributed 30 flaw reports. Put together, the two programs accounted for more than a third of all vulnerabilities Microsoft fixed in 2009.

Got strong feelings about this article, or about the issue of vendor responsibility or vulnerability disclosure? Please drop a note in the comments section below.

63 thoughts on “Firm to Release Database & Web Server 0days

  1. Ben Yarbrough

    Does anyone know of any vendors that have been sued for civil (financial) liability by hacked victims with respect to products or software with known security bugs? Brian has highlighted the recent bank litigation in Texas and Maine that hold considerable interest. The right vendor claim would be even more powerful to reshape the disclosure debate and landscape overnight.

    As a practicing lawyer and recent entrant into the industry (Calyptix where we focus on IT security for SMB customers), the imposition of liability becomes a very powerful motivator to fix code. Just look to the auto industry. Uncapped liability ultimately drove the manufacturers to favor seek regulation as a liability shield rather than a burden – because everyone faces the same costs. As long as the status quo is less expensive than the proposed alternative, the vendors will resist change (e.g. regulation, disclsoure, etc.) and any regulation is likely to offer limited value. Civil litigation is a wild card and hard to calculate the cost thus can become a game changer. All you need is the right victim, right facts and right jurisdiction.

  2. OS guy

    I used to work for a company that developed software-intensive consumer electronics products. When I questioned some security issues in a joint project we were contemplating with a competitor (the market leader), I was told that the competitor’s official position on security was that “security is a market disabler”. They would rather ship a known-insecure product to get a capability into the market quicker and make revenue, even if they had to use a portion of the profits to fix the bugs later, than to delay getting to market (risking having a competitor beat them) and make it more secure. There were people in our company who thought that their position was “enlightened”, and wondered out loud why we didn’t emulate them.

    Does anyone doubt that this is common in for-profit companies? There are only a few things that will cause companies to change were they draw the line between spending time and effort enhancing security vs. time-to-market + profits: 1) Bad press. Bad for business, bad for stock price. 2) Regulation. Most companies, if reluctantly, obey the law at least partly because failing to do so violates #1. 3) Customers and sales. If customers told companies they wanted better security in their products, they might get it, or if lots of people tell companies that they aren’t buying a product because it’s not secure, then it might have an effect. But people ask for product features and ASSume that it’s secure, so this virtually doesn’t happen in practice.

    In the early days of cellphones, cloning was quoted as causing billions of dollars of lost revenue. The dirty little secret was that most of that “lost revenue” was calls that wouldn’t have ever been made if the caller had had to pay for them, and until the “real losses” caused by denying access to paying customers got big enough, the carriers really didn’t care enough to pay for fixing it. Fast-forward to the credit card industry now: As long as they can charge people 30% annual interest, why worry about a few percent of that being spent on fraud? Or to the Microsoft’s of the world: as long as people buy their software, and have to pay for upgrades to get higher security going forward, then full-steam-ahead on features, and minimum spending on improving security. As long as companies are making a profit, and especially if they can make their customers pay for the fixes to their mistakes, they have little incentive to fix their problems.

    I don’t particularly like the idea of being hit by a 0day because my daily-use software is buggy, but my guess is that, statistically, early disclosure is likely to reduce the long-term damage caused by a 0day exploit more than it increases it (though it will do both) because it gets it out in front of the software vendor and the detection vendors without back-room rigamarole.

Comments are closed.