Free Technology Newsletters
» All 33 InfoWorld Newsletters
Technology & Business Daily
 
InfoWorld
 
   

Censoring Security Information

By Ed Foster, Section The Gripelog
Posted on Tue Apr 05, 2005 at 12:12:29 AM PDT

An interesting tech morality play was enacted last week over Sybase security bugs and the censorship clause in its EULA. Some customers have publicly sided with Sybase on the need to keep detailed information about the flaws secret, but where does the interest of Sybase customers really lie?


In case you missed the story, a British security research firm was prevented by Sybase legal threats last week from releasing details about Sybase security vulnerabilities. NGS Software Ltd. had discovered the flaws in Sybase's ASE database software last year but had delayed going public to give Sybase time to fix the problems. After Sybase released its patched version, however, it turned around and threatened legal action if NGS revealed the bugs. The basis of the threat is a censorship clause in the Sybase license agreement:

"Results of benchmark or other performance tests run on the Program may not be disclosed to any third party without Sybase's prior written consent."

While many have expressed outrage that Sybase would try to muzzle security information this way, some customers have actually sided with Sybase's argument that having details of the vulnerabilities revealed is not in their interest. Security researchers should, they argue, go public with this kind of information only if the software company refuses to fix the problems. Besides, NGS sells a Sybase vulnerability assessment tool, so doesn't that make their motives for all this bug-hunting suspect?

Well, it's certainly understandable why harried IT managers, faced with the endless need to install security patch after security patch, might sometimes wish the security researchers would just keep quiet. But NGS didn't create these bugs - it just found them. And it's a good thing NGS was motivated to do so, because there are also a lot of bad guys out there who are definitely motivated to ferret out security vulnerabilities as well, and next time they might get there first.

Speaking of motivations, I don't buy Sybase's claim that it only started brandishing its censorship clause to protect its customers. Trying to protect itself from a little embarrassment, and discouraging NGS from hunting for more bugs, were both probably higher on the Sybase legal department's agenda. Perhaps there was even a desire as to keep customers from checking whether Sybase's patches really did the trick?

And what other motivations might other software companies find in the future for invoking a censorship clause like this? After all, if reporting security bugs qualifies as "other performance tests" that can only be discussed with company permission, then all forms of criticism about a product's performance could be banned. The right to speak your mind cold ultimately just get lost in the sneakwrap. That's where the interests of Sybase customers, and the interests of customers of all software companies, really lie. So, while you still can, exercise your right to criticize the performance of your vendor of choice by writing me at Foster@gripe2ed.com or posting your comments below.

< Pre-Ordering TaxCut Cuts Off Rebate | Norton's Knockout Punch >


Display: Sort:
Censoring Security Information | 15 comments (15 topical) | Post A Comment
"Easy" solution[ Reply to This ] (none / 0) (#1)
by Jarulf on Tue Apr 05, 2005 at 04:37:44 AM PDT

Do your security research, terminate your license, release details about security vulnerabilities. Problem solved.

[ Reply to This ]


I agree, but...[ Parent | Reply to This ] (none / 0) (#11)
by Anonymous User on Wed Apr 06, 2005 at 01:13:54 PM PDT

I'd really like to see some company challenge this type of EULA clause in court. If we could get the courts to rule these clauses as unenforcable, them maybe we could be done with them once and for all.

[ Parent | Reply to This ]


Why publish the exploit?[ Reply to This ] (none / 0) (#2)
by Garminski on Tue Apr 05, 2005 at 06:58:10 AM PDT

I have never understood the need for companies or people to publish the exploits they find to make it easier for the bad guys to write malicious code. If you find a bug, report it to the vendor. If they do not take care of it, I can understand publishing some information to light a fire under their butt. Nothing like angry/scared customers to make a company responsive. But to bug hunt and then give details on the exploit after a fix is published seems more like bragging then doing the public any good.

[ Reply to This ]


It's called "peer review".[ Parent | Reply to This ] (none / 0) (#3)
by Anonymous User on Tue Apr 05, 2005 at 10:14:03 AM PDT

It's called "peer review". It means that the problem can be independently verified by others with the unfixed version -- and that its absence can be verified in the "fixed" version without merely taking the vendor's (or someone else's) word for it that it's fixed.

[ Parent | Reply to This ]


Re: Why publish the exploit?[ Parent | Reply to This ] (none / 0) (#5)
by Anonymous User on Tue Apr 05, 2005 at 10:54:37 AM PDT

There is a hope that we can learn from the mistakes of others. If details are not published, others will repeat the same mistakes.

[ Parent | Reply to This ]


Good point[ Parent | Reply to This ] (none / 0) (#13)
by Garminski on Thu Apr 07, 2005 at 01:24:00 PM PDT

Excellent point. I had not considered that.

[ Parent | Reply to This ]


Other way arround[ Parent | Reply to This ] (none / 0) (#9)
by Jarulf on Wed Apr 06, 2005 at 03:14:21 AM PDT

So? Must everything one do be of any "public good" (other posters have allready pointed out some good with it though)? I would put it the other way arround, why NOT publish it? What is the problem with that? if everything anyone says, publish or put out to the public must have a general godness for the public and not be bad for anyone, there is a LOT of things that we have to remove from the public.

[ Parent | Reply to This ]


No...[ Parent | Reply to This ] (none / 0) (#14)
by Garminski on Thu Apr 07, 2005 at 01:36:32 PM PDT

Of course not EVERYTHING must be done for the public good. Only a complete fool would think or argue that. My point was that often you hear the "it's for the public/community/etc good" as an excuse to do something. Censorship in general is bad, after all whose "rules" are you going to follow? However, with that said some responsiblity must then fall to the person or organization that is going to publish information to evaluate that information. Doing (publishing) something because you can but the result is that it puts people at risk would not seem to make much sense. As other posters have pointed out very well however, there is a good reason to publish this information to prevent others from making the same mistakes. I did not understand the specifics of what was being published and thought that more information was given then apparently is. I stand corrected (and better informed).

[ Parent | Reply to This ]


People at risk...[ Parent | Reply to This ] (none / 0) (#15)
by Mason on Thu Apr 07, 2005 at 07:37:14 PM PDT

I know you've kind of seen the light on this.... but to add:  People are already at risk.  If I can evaluate a published report, I can actually judge the risk level and take action (or not) as warranted.

[ Parent | Reply to This ]


Publishing vulnerability information[ Parent | Reply to This ] (none / 0) (#10)
by Anonymous User on Wed Apr 06, 2005 at 06:32:02 AM PDT

I personally have read several dozen discoveries NGSSoftware have found in Windows, Oracle, DB2 and other widespread, enterprise software packages. They sometimes wait half a year or more until the vendor releases a patch as long as the vendor is responding positively to the issue. It's my understanding NGS lends their technical knowledge to vendors in repairing these products. Their announcements are sometimes over-detailed, but never completely explicit - they generalize descriptions adequately so only the very knowledgeable could use it to create an exploit.

So what if publishing the discovery adds to their bottom line by selling their products - it's advertising. In essence, though, it's a regressive tactic in that they are minimizing the need to own their product by helping fix the problems it would discover. And, considering the time, money and effort put into educating themselves in complex software programming techniques, I don't slight them in the least for bragging a little.



[ Parent | Reply to This ]


performance tests[ Reply to This ] (none / 0) (#4)
by Anonymous User on Tue Apr 05, 2005 at 10:47:08 AM PDT

Is there any indication of how Sybase connects the dots from "benchmark or other performance tests" to a ban on publishing details of a security vulnerability? This seems like a huge expansion of the definition of a performance test.

[ Reply to This ]


Of course it is...[ Parent | Reply to This ] (none / 0) (#6)
by CowboyinBRLA on Tue Apr 05, 2005 at 01:01:01 PM PDT

Of course it's a huge expansion of the definition of the term "performance test". One of the hallmarks of a bad EULA, I think, is the use of slippery words like this without defining them in the agreement. That way, the terms can be redefined at any point that is advantageous to the company. In theory, of course, a court can rule on whether the definition being applied is reasonable. But how many end users are going to sue when a company terminates their EULA for a violation like this? Not many. The old adage is "Give them an inch, and they'll take a yard". I think it's pretty clear that's what Sybase is doing with its EULA, in order to protect its reputation.

[ Parent | Reply to This ]


I found that confusing as well[ Parent | Reply to This ] (none / 0) (#7)
by auctionhugh on Tue Apr 05, 2005 at 01:19:40 PM PDT

Since when is a security vulnerability the same as the result of a performance test?

-----
Get help with your website from AuctionHugh's wife Kathleen.
Professional, artistic, and EASY for you!
Kallen Web Design of Grand Rapids



[ Parent | Reply to This ]



And hence the beauty of open source software[ Reply to This ] (none / 0) (#8)
by Anonymous User on Tue Apr 05, 2005 at 02:24:43 PM PDT


Where the worst you have to worry about is the GPL and not some secret security hole in your software you can't talk about for years at a time - if ever.

Guaranteed it will spread like wild fire through the script kiddies grapevine though.

[ Reply to This ]



McAfee[ Reply to This ] (none / 0) (#12)
by Anonymous User on Thu Apr 07, 2005 at 09:27:11 AM PDT

Isn't this clause the same as the one from Mcafee that was ruled against in court? See this Inquirer story.

[ Reply to This ]


Censoring Security Information | 15 comments (15 topical) | Post A Comment
Display: Sort:
Recent Entries
Bill Gates and PC history
17 comments

Borderline searches and seizures
15 comments

Reader voices: Angry at eBay
11 comments

Teleblend's terrible terms
2 comments

Spyware bill cloaks a mini-UCITA
9 comments

Reader Voices: Autorenewal Defenses
21 comments

More The Gripelog...

Submit a gripe
About the Author
Email Ed Foster

Help Ed and his readers build these projects:
The Gripewiki
The EULA Library

Login
Make a new account
Username:
Password:

Live Gripes
Has AOL Changed Their Ways?
12 comments

A Nestle SweeTarts Conspiracy
13 comments

AT&T Kills "Bad" Username
26 comments

DESPERATE! AOL HAS TAKEN OVER MY COMPUTER
47 comments

parkingticket.com SCAM on refunds
22 comments

Don't let Net Enforcers Ruin Your Day.
14 comments

More Live Gripes...

Sign up for my newsletter

To have my column automatically e-mailed to you, submit your email address in the form below. Of course, I will not turn your address over to any other party or send you any unrequested e-mail.

Infoworld Blogs

Recomended Sites
The AFFECT Coalition
Electronic Frontier Foundation
Electronic Privacy Information Center
Free Software Foundation
HearUsNow.org
Public Knowledge
StopBadware.org

Jeff Angus
Ben Edelman
Dan Gillmor
Bob Lewis
Brian Livingston
Freedom to Tinker
Lawmeme
PC World's Techlog
SunBeltSoftware Blog
Troubleshootsers.com

Rss Feeds
How this works
 Top News 
 Columnists 
 Tech Watch 
 Test Center Reviews 
 Applications 
 App Development 
 E-Business Solutions & Strategies 
 End-user Hardware 
 Networking 
 Operating Systems 
 Platforms 
 Security 
 Standards & Protocols 
 Storage 
 Telecommunications 
 Wireless 
 Web Services 

 

create account | faq | search