Sybase Practices Dumb Security

A threat by Sybase Inc. to sue a U.K.-based security research firm if it publicly discloses the details of eight holes it found in Sybase’s database software last year is evoking sharp criticism from some IT managers but sympathetic comments from others.

I can see why Sybase would prefer it if people didn’t know about vulnerabilities in their software—it’s bad for business—but disclosure is the reason companies are fixing them. If researchers are prohibited from publishing, then software developers are free to ignore security problems.

Tags: computer security, databases, disclosure, secrecy, vulnerabilities

Posted on April 1, 2005 at 1:24 PM • 12 Comments

Comments

Israel Torres • April 1, 2005 1:34 PM

“Kim Milford … In such cases, “hackers tend to benefit the most from the release of technical details” about security vulnerabilities, she said.”

Oh no Kim… everyone benefits. Disclosure is like exposure to the elements. If it doesn’t kill you it only makes you stronger. Only by keeping it quiet does it becomes a malicious cancer that will only prove regret in the future.

Israel Torres

Craig Stuntz • April 1, 2005 1:44 PM

Makes sense to me. This way nobody will find out about them. Because all this publicity is bound to prevent people from diffing disassemblies of the pre and post fix versions….

Chirayu • April 1, 2005 2:02 PM

What if a hacker finds it before anyone fixes it? I dont think its fair to say that nobody will find out about them.

Polyanna • April 1, 2005 2:29 PM

This is a scary “security” stance. If I am a security professional who would openly post an exploit I found online where do I turn with the exploits I find now? The words Metasploit framework come to mind…let’s see now…where did I put that open proxy server again?

Fortunately the “gray-hat” community is small….but they can also be quite dangerous. So let’s ask some pertinant questions: How many databases need to be compromised before Sybase changes their mind? How many unscrupulous hackers does it take to do this? Anyone out there with Sarbanes-Oxley or GrammLeach regulations going to take a chance on using Sybase products now? The answer to all three questions may just be “one”.

Davi Ottenheimer • April 1, 2005 2:57 PM

Shame, it is as though Sybase wants to lose market share…what’s next, an “unbreakable” marketing campaign?

Thanks for the link.

Here’s another take on the situation by Frank Hayes, fittingly called “dumb security”:
“http://cio.co.nz/cio.nsf/0/4B96DB88AD94AEE8CC256FD2007F524A?OpenDocument&More=Special+Feature

Thomas Sprinkmeier • April 2, 2005 7:16 AM

Vulnerability disclosure in the Ideal World(tm)

1) Tell the vendor with all details so they can fix it (X is broken, and this is how to break it: …..)
2) Optionally, tell the world with no details so they can take mitigating steps (X is broken, there’s no fix yet. You might want to turn it of until it’s fixed, or keep a close eye on your logs)
3) If a fix arrives in a timely manner, wait for it to be evaluated applied, then release technical details.
4) If no fix arrives, release details to put pressure on the vendor.

What’s so hard to understand about that?
Why are there people still advocating secrecy? Why do others still listen to them?

If we handled automotive security this way we’d still be driving Pintos and the nightly news would be censored by GM.

Javier Kohen • April 2, 2005 9:32 PM

@Thomas

Once you start working with vendors about vulnerability releases you find out that what’s timely becomes subjective and there’s always the “a couple of weeks more.” Sometimes the vendor has a way to put pressure on you (for instance, if you work for a company that provides services to said vendor) and there isn’t much you can do.

On the other hand, your ideal world assumes that services can be turned off without repercusions, or be replaced by other functionally similar systems. Also by the time you read the logs it might be too late, especially if you don’t know what you’re looking for.

If you don’t cry out when the wolves come they might devour the lambs before somebody else notices. Even if it’s the early afternoon, thus everybody in town is taking a nap and don’t want to be disturbed.

Thomas Sprinkmeier • April 3, 2005 8:50 AM

Javier,

Hence the “Ideal World” disclaimer.

I know that in the real world, vendors exist to make money (imagene that!) and that, therefore, a fix is only required if the vulnerability is threatening to loose them money (which sometimes means it has to be actively exploited and talked about on the news).

From your comment I assume you favour early and full disclosure? I favour delaying detailed disclosure to give the vendor a chance to ‘do the right thing’. Of course, if they have a track record of not doing so, cry wolf as loud and as early as you can (or, as loud as your legal budget allows 🙂

I know you can’t always turn stuff off, but you might be able to mitigate. Dependin on the threat, tighten account lockout policies, change default port numbers, turning off some features etc…

One mail server I use regularly suspends delivery of emails until a virus signature for the LatestAndGreatest virus is available. This scenario is slightly differnet, but the same idea applies: use advance warnings as a trigger to reduce services in order to mitigate risk.

While I understand that vendors may never agree to a disclosure policy such as the above, I can’t understand why customers don’t insist on it. Why do we let vendors lie to us, claiming to have our security in mind while hiding their flaws?

Francis K • April 4, 2005 8:16 AM

Thomas,

While I agree that vendors exist to make money, they also have a responsibility to protect their customers. Vendors should definitely provide fixes for security exposures. However, providing the details can put customers at risk. Some customers will not be able to ugrade their software to the fixed version for various reasons:
1) Timing – it could be the company’s busy season and no major changes are allowed.
2) 3rd Party Support – if the customer is running a 3rd party app, they often cannot upgrade the DBMS without certification from the 3rd party vendor, or they risk losing support of the 3rd party product.
There are other reasons why a quick upgrade may not be feasible.

As a customer, or in this case as a DBA, I would not want people to know how to exploit the holes in the DBMS. In my opinion the company in the wrong is the one planning to release the details. It is fair game to announce that they found a problem, and then work with the vendor to get it resolved. The vendor has the responsibility of providing a fix.

I am reminded of Greek mythology. If Apollo hadn’t known about Achilles’ weakness, Paris would not have defeated him. Do we want everyone to know the “Achilles heel” of Sybase software, or any other software?

xyz • April 4, 2005 11:48 AM

@Frances

“In my opinion the company in the wrong is the one planning to release the details. It is fair game to announce that they found a problem, and then work with the vendor to get it resolved. The vendor has the responsibility of providing a fix.”

But that’s what they did! Sybase has released fixes for the problems. The company who reported the flaws generally witholds the details for three months (from time of a patch being available).

They worked with Sybase, they witheld details (after the patch was available), and then Sybase made their legal threat(s). Ironically, Sybase has probably generated even more awareness of these flaws by doing this!

Perhaps Sybase could have spent some of the money they allocated to the legal department on security / code reviews instead?

Besides, anyone with a disassembler already knows what these flaws are by examining the patches. Considering what’s happened, it’s a rather odd move by Sybase (my guess is internal politics)

Disclosure isn’t perfect, but it’s probably the best way we’ve found so far that actually forces the vendors to act on security issues. Without it, vendors either 1. deny there’s a problem / classify it unreproducible, 2. declare it a “non real-world” scenario, 3. profess some commitment(s) (to unnamed customers) that prevent them from releasing a patch, 4. claim to be working on a fix but make it so low priority they might as well not be.

Of course, occasionally a vendor would do the right thing, but there was no incentive for them to do so, and especially little if it had no effect on their bottom-line (indeed, it takes resources away from other things, and security isn’t a particularly visible selling point for most things is it?).

Ralph Broom • April 4, 2005 12:57 PM

It seems that the benefit has already been gained. Sybase apparently has flaws that it won’t subject to independent review, and thus may not fix. The solution is to use another product until the situation changes.

Jayh • April 6, 2005 5:02 AM

Criminals have a vested interest in secrecy too. It is often the case that these flaws are not found just one time, and the less users and vendors know about the flaws, the more soft targets are available.

There are quite likely many more weaknesses known in the underground that have not found their way into public knowledge.

Sybase Practices Dumb Security

Comments

Leave a comment Cancel reply