Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Why Responsible Vulnerability Disclosure Is Painful and Inefficient

Soulskill posted more than 4 years ago | from the cost-benefit-annoyances dept.

Bug 182

A recent rant up at Attrition.org highlights problems with the responsible disclosure of security issues. While some vendors are happy to do their own research and patch reported problems, others drag their feet and make unreasonable demands on a researcher's time and effort, making anonymous public disclosure an ever-more-tempting option. Quoting: "After a couple hours of poking, I found a huge unauthenticated confidentiality hole. Once the euphoria wore off, I realized I had a big problem on my hands. I had to tell my employer's app owners and we had to assess risk and make a decision on what to do about it. After some quick meetings with stakeholders, we decided to severely limit access to the thing while we worked with the vendor. The vendor refused to acknowledge it was a security issue. Odd, considering most everyone who sees the issue unmistakably agrees that it is not acceptable. Now I'm forced to play hardball, yet nobody wants to fully-disclose and destroy relations with this vendor, whose software is somewhat relied on. Meanwhile, I know there are hundreds of institutions, small and large, using this software who have no idea that it has flawed security and who would probably not find the risk acceptable. What can I do? Nothing. Oh well, sucks to be them. ... I've had a vendor tell me to put a webapp firewall in front of their software. Did they offer to pay for it? No. That would be like Toyota telling its customers to buy ejector seats (unsubsidized ejector seats, that is) to resolve the accelerator problem in their vehicles. I've had other vendors demand I spend time helping them understand the issue, basically consulting for free for them. Have you ever knocked on a neighbor's door to tell them they left their headlights on? Did they then require you to cook them dinner? Exactly..."

cancel ×

182 comments

I'd just like to report (5, Funny)

2.7182 (819680) | more than 4 years ago | (#31808144)

that there is an exploit that allows a user to bump their post up to first.

Re:I'd just like to report (0)

Anonymous Coward | more than 4 years ago | (#31808424)

Yeah, it's really a simple one too. All you gotta do is post first..

Re:I'd just like to report (1)

spazdor (902907) | more than 4 years ago | (#31808722)

We call that a "race condition." It happens on every /. article.

And? (-1, Flamebait)

Anonymous Coward | more than 4 years ago | (#31808146)

I fail to see the relevance of this article.

Goatse (-1, Troll)

Anonymous Coward | more than 4 years ago | (#31808148)

http://goatse.fr/ [goatse.fr]

Blow the Whistle (2, Insightful)

Anonymous Coward | more than 4 years ago | (#31808156)

What can you morally do otherwise but blow the whistle?
If you keep playing ball with these people, they will continue to act in the fashion that they do. Nothing will change. They are basically getting away with it.

Give them some pain now and let this be a lesson both to them and to others.

Re:Blow the Whistle (4, Interesting)

TheLink (130905) | more than 4 years ago | (#31808398)

And they do get away with it.

Maybe things are different now with more hackers looking for holes, but back then you could find bugs, disclose them responsibly and privately, have the vendor/site still not fix them for years, and nobody notices - not even the hackers.

They eventually might fix it in some future release (not even the next major release :) ). Or they replace it with something totally different.

So nobody's hurt. At least that I knew of, which is the other problem: who knows right? Maybe a hacker did find it and was very discreet. Ignorance is bliss or not ;)...

It's just like leaving your car unlocked somewhere with the key in the ignition. In certain areas it's a sure thing that the car will be gone the next day, but not everywhere.

For the more obscure areas, if you do disclose it publicly, the risks to the users go up more than if you had kept it quiet.

In the long term maybe the users would be better off using something else, but who is to say the other stuff isn't as crappy? It's not like everyone has so much time to try to exploit everything. Even the security researchers don't look at "everything".

Re:Blow the Whistle (1)

postbigbang (761081) | more than 4 years ago | (#31808724)

I think that there is hurt. First lack of acknowledgement itself is a hurt on the trustworthyness of the vendor. If you can't patch it yourselves, or find a way to diminish the threat represented by the problem, than you have a fiduciay and legal responsibility to your organization.

I'd send information higher in the food chain than you're dealing with. Tenacity may be necessary to get people to understand the gravity of the situation.

Re:Blow the Whistle (4, Insightful)

TheLink (130905) | more than 4 years ago | (#31809144)

My point is the situation often isn't as grave as many security researchers like to think.

Yes there is a hole. But there are zillions of holes. If the hacker wants in, they've probably already got in via some PHP exploit or some malware infected PC.

If you've found an exploit in IE or firefox or Windows or OSX or ssh, sure go kick up a big fuss. Or just wait till the next pwn2own competition ;).

Whereas if you've found an exploit in some ADSL modem router made by some Korean company, and they're not fixing it after you've reported it. Big deal. Hardly any of the routers will still be working 3 years from now. How many of you got pwned because of those infamous bugs that were present for years without anyone knowing? How many hackers would make a lot of $$$$ from exploiting some non-"vastly deployed" software in your company, and get away with it? Would they be better off concentrating on building windows botnets?

If it's a problem with some vendor supplied app that your company uses, disclose the problem to the bosses. If the vendor doesn't want to fix it, and you're not the boss, it's between the boss and the vendor. You provide info and advice. Of course you don't play down the risks - that's not your job - that's the vendor's job ;).

Re:Blow the Whistle (4, Interesting)

commodore64_love (1445365) | more than 4 years ago | (#31809154)

It's the year 2005. You know that Toyota cars have a programming bug that causes cars to accelerate, and ignore any other inputs (ignores the brakes or switching gear to neutral). What do you do?

It's the year 1970. You know that Ford cars have a design flaw that makes them the gas tank explode in an accident. What do you do?

In the 1970 instance, a book author wrote a tell-all called "Unsafe At Any Speed" which revealed Ford's design flaw. In the 2005 case, I'd simply post what I discovered to Toyota-oriented websites and also call the U.S. Government Product Safety Commission. Otherwise Ford/Toyota would never have fixed the problems with their cars.

I'd also report this software bug, since the vendor seems inclinded to pretend it does not exist. Better to be a whistle-blower and save lives than wait until damage is done. You can't resurrect corpses, but you can warn people while they're still alive, so they can act to protect themselves.

IMHO.

Please don't mod me down just 'cause you disagree.

Re:Blow the Whistle (4, Informative)

germansausage (682057) | more than 4 years ago | (#31809704)

Your thinking of the the Ford Pinto which was prone to fires and explosions when hit in rear end collisions. It was first produced in 1971. Unsafe at any Speed was written by Ralph Nader in 1965 about the American Auto industries reluctance to fix safety problems. The car it talked about (among other things) was the Chevrolet Corvair.

Re:Blow the Whistle (2, Insightful)

Z00L00K (682162) | more than 4 years ago | (#31808728)

There is no need to play security issues nice anymore, just tell them in general terms that you have acquired knowledge of a bug, not that you found the bug yourself and then provide that info to a suitable magazine or publish it on Wikileaks.

Re:Blow the Whistle (4, Insightful)

u38cg (607297) | more than 4 years ago | (#31809000)

I don't see a problem with this. The vendor has replied that it doesn't consider this to be a security issue, so surely a public notification isn't going to hurt anyone, right? Right? Oh, your customers are cancelling? I thought it wasn't an issue? What can I say, silly me.

company policies vary wildly (1, Interesting)

Anonymous Coward | more than 4 years ago | (#31808160)

Digital Equipment Corporation (DEC) used to thoroughly investigate all bugs in their operating systems like RSX. Microsoft wanted you to pay them so much per hour to review suspected bugs. Needless to say, DEC got our full cooperation and we didn't bother reporting anything to Microsoft.

Re:company policies vary wildly (1)

theshowmecanuck (703852) | more than 4 years ago | (#31808352)

Microsoft is still in business. Sad... but true.

Re:company policies vary wildly (0)

Anonymous Coward | more than 4 years ago | (#31809040)

Microsoft is still in business. Sad... but true.

Which is fine. That's why there is full disclosure. Oddly enough, Microsoft is on the forefront to call that "irresponsible." Funny how business works like that.

Disclosing Exploitz (3, Interesting)

poena.dare (306891) | more than 4 years ago | (#31808176)

FTA:

I've even been accused of being a spy for a company's competition (true... ask Jericho)...

ME: "Hi, you left your headlights on."
NEIGHBOR: "WHO SENT YOU? DID MY EX-WIFE SEND YOU? ARE YOU SLEEPING WITH HER?"

WTF? Seriously?

---

Compare how companies badly deal with vuln disclosure compared to how game companies deal with cheats and exploits. Well, MOST game companies...

Re:Disclosing Exploitz (0)

Anonymous Coward | more than 4 years ago | (#31808418)

Actually they don't deal with it. They outsource to another company, like EvenBalance, who produce crap like PunkBuster (aka PinkMustard), which not only doesn't work, but also makes it impossible to record a video, have an fps overlay and so on...

Did they then require you to cook them dinner? (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#31808178)

"Have you ever knocked on a neighbor's door to tell them they left their headlights on? Did they then require you to cook them dinner?"

Yeah... my buxom neighbour has her "headlights" on all the time. I proceeded to knock on her door to ask for a date, and she indeed required me to provision a dinner.

Dont sweat it. When you find them, just slip it (3, Insightful)

unity100 (970058) | more than 4 years ago | (#31808184)

To the net. Current dominant dog eat dog capitalist corporate culture makes corporations suppress and hush hush stuff rather than sparing the effort to fix.

Re:Dont sweat it. When you find them, just slip it (2, Insightful)

thePowerOfGrayskull (905905) | more than 4 years ago | (#31808816)

There are two problems I see with that. First, no matter how well-intentioned your actions, it's not the company that pays - it's the people and companies who have the software installed; in essence making the person who publishes this directly responsible (though not legally) for damages caused by the exploit. The company will just say, "oops", shrug, and move on.

The second one is the fact that for large software packages, there is no such thing as "quick fix". When you have a few million lines of a code, a regression test is non-trivial. And when you have thousands or millions of customers, you have to regression test before you can release. This process can take weeks or even months.

And unfortunately, even in the case where the company is being a complete jackass and simply ignoring you (or asking to to consult for free) , the first issue still applies. Say what you will about "security through obscurity" -- the fact remains that it is one of many valid and valuable tools in security. (Lest someone interpret that as an anti-OSS comment let me also add that "many eyes" is another such valid and valuable tool. Not all tools are available to all people/products.)

Re:Dont sweat it. When you find them, just slip it (1)

cbreak (1575875) | more than 4 years ago | (#31809128)

The vendor himself said it's not a security hole, so what could possibly happen? :)

Leak it (4, Interesting)

Aurisor (932566) | more than 4 years ago | (#31808202)

Leak a working exploit anonymously. If a vendor isn't concerned with the security of their users, let them pay the price.

Re:Leak it (5, Insightful)

egcagrac0 (1410377) | more than 4 years ago | (#31808276)

Interesting, but...

You're then basically telling anyone who might employ such an exploit how to compromise your system.

My responsibility is to protect my system first, and then to help other people protect their systems.

I'm not saying that a leak of an exploit isn't good, I'm saying you need to make sure that something is protecting your system from that exploit before you leak it.

Re:Leak it (4, Insightful)

schon (31600) | more than 4 years ago | (#31808334)

You're then basically telling anyone who might employ such an exploit how to compromise your system.

And you're assuming that someone who wants to exploit your system doesn't already know how.

Re:Leak it (1, Insightful)

Tim C (15259) | more than 4 years ago | (#31808580)

And you're assuming that someone who wants to exploit your system doesn't already know how.

If the exploit is secret, maybe they do know, maybe they don't.

If the exploit is publicly disclosed, they almost certainly do.

Given the stated situation (of having a vulnerable system) the former is preferable to the latter.

Re:Leak it (3, Insightful)

Todd Knarr (15451) | more than 4 years ago | (#31808678)

If the exploit is secret, maybe they do know, maybe they don't.
If the exploit is publicly disclosed, they almost certainly do.

If the exploit is secret and maybe the bad guys know about it and maybe they don't, the only safe course is to assume they do know about it and act accordingly. It's like a door: maybe a burglar will come around trying it and maybe he won't, but you still don't go on vacation leaving the front door to your house unlocked because it's not worth the risk if he does come around.

Re:Leak it (1)

NicknamesAreStupid (1040118) | more than 4 years ago | (#31809118)

A classic case of "no good deed goes unpunished" such as this often leads to the logical conclusion - use the crack to pillage the vendor. The vendor is destroyed, the "do-gooder" is handsomely rewarded, and somebody writes a book about it and gets royalties from the movie staring Sandra Bullock, who is aptly cast (see "The Net" & "Demolition Man") and could use the diversion.

Re:Leak it (1)

yariv (1107831) | more than 4 years ago | (#31809324)

If the exploit is secret and maybe the bad guys know about it and maybe they don't, the only safe course is to assume they do know about it and act accordingly.

This is a false dichotomy. There is no "safe" and "unsafe" systems, there are only more or less safe systems. So it depends on the cost of handling the exploit. I could extend your metaphor by pointing to the fact a locked door won't give you complete protection. Do you go on vacation without installing an alarm? Barring the windows? Hiring a security company? The list of possible measures is endless, if you're willing to get extreme enough, and for each one you could use the same argument, so something is wrong. If the exploit is secret you estimate the probability it's known and the cost to fix it and decide according to both of these. It is reasonable the outcome will different for vendor/client (the vendor should fix, the client shouldn't), since the vendor has a lot more systems with the exploit...

Re:Leak it (2, Insightful)

schon (31600) | more than 4 years ago | (#31808794)

Given the stated situation (of having a vulnerable system) the former is preferable to the latter.

*sigh* Logic. You fail it.

Given that an adversary *might* be able to exploit a vulnerability, the "preferability" of any given scenario is completely irrelevant - you take steps to make sure they can't. Seriously, saying "oh, if I wish hard enough, maybe nobody will exploit it" is FUCKING BRAINDEAD.

If a vendor refuses to fix a vulnerability, then you must (by necessity) make the problem as widely known, so that as many of the vendor's customers (both current and future) can apply pressure to get them to fix it.

Re:Leak it (0)

Anonymous Coward | more than 4 years ago | (#31808586)

And you're assuming that they do, etc etc etc.

Re:Leak it (1)

egcagrac0 (1410377) | more than 4 years ago | (#31809102)

Just because the thieves know how to smash my windows and pick my locks doesn't mean I give them keys to my house.

Re:Leak it (0)

Anonymous Coward | more than 4 years ago | (#31808430)

I'm saying you need to make sure that something is protecting your system from that exploit before you leak it.

If the vendor doesn't fix it, you have to do that anyway. Chances are, you aren't the only one to find the exploit.

Might as well leak it afterwards. From an ethical point of view this warns other users of the software. From a business point of view, this might be your best bet to force the vendor to fix it.

Re:Leak it (0)

Anonymous Coward | more than 4 years ago | (#31808944)

Don't release it because then I'll lose access to your system!

Re:Leak it (1)

phantomfive (622387) | more than 4 years ago | (#31808302)

That could be illegal, depending how you do it. Be careful with this advice.

Re:Leak it (2)

countertrolling (1585477) | more than 4 years ago | (#31808984)

That could be illegal...

The law is irrelevant..

Re:Leak it (1, Insightful)

Anonymous Coward | more than 4 years ago | (#31808454)

Lol. It won't be so anonymous to the vendor if you were talking to them about it the day before.

Ok they won't be able to prove that it was you who leaked it because someone else could have found the exact same problem at the exact same time, but you'll be the first suspect on the list and then the police might be able to prove it was you.

Re:Leak it (1)

Aurisor (932566) | more than 4 years ago | (#31808858)

So leak it first, wait for it to show up somewhere, and *then* contact the vendor and point to the leaked exploit.

Maybe I'm just cynical, having been blown off many times in the past. Generally speaking, the only way to get technical attention is to make non-technical people freak out.

Re:Leak it (0)

Anonymous Coward | more than 4 years ago | (#31808954)

Uh, how do you decide whether to leak first if you find just one vulnerability per vendor? Or are you suggesting to leak all the time, even if some vendors would have been happy to do their own research and patch reported problems if given the chance?

Hushmail and full disclosure (3, Interesting)

Anonymous Coward | more than 4 years ago | (#31808222)

Use hushmail and full disclosure mailinglist to report stuff like this.

There's no sense wasting time, do it anonymously, use tor.

Also while you do it, be sure to post personal information about other full disclosure users so that your email is removed from the official archives.

Re:Hushmail and full disclosure (0)

Anonymous Coward | more than 4 years ago | (#31808286)

I concur, they fix it for everybody using their sw or you leak, simple as that. They have a moral obligation to their customers and to the customers of their customers using their sw to provide a secure product, and failing that, fix said product if found to be faulty.

I'd give them a month.

Re:Hushmail and full disclosure (3, Insightful)

theshowmecanuck (703852) | more than 4 years ago | (#31808434)

Or do they have a moral obligation to their shareholders to not spend money if they don't have to (keep up the bottom line)? Or do they have an ethical obligation? Just playing devils advocate since I think the idea of profitability IS a big part of this, and trading shareholders concerns over the customers or the employees seems to be the new morality for companies and corporations. If it is, then what they are doing probably seems just fine to them, and what the OP is complaining about probably seems strange.

Re:Hushmail and full disclosure (1)

nextekcarl (1402899) | more than 4 years ago | (#31808652)

How much damage would be done to them financially if it was discovered they were warned of a massive vulnerability and they did nothing? From lost sales to possible actual financial losses stemming from lawsuits from the affected parties.

Re:Hushmail and full disclosure (0, Flamebait)

NicknamesAreStupid (1040118) | more than 4 years ago | (#31809296)

What does this mean - "a moral obligation to their shareholders"? And what the hell is this - "do they have an ethical obligation"? I thought we were talking about companies. The part the makes perfect sense -- "devil's advocate." The biggest laugh - "new morality for companies and corporations." The reality -- Corporation, "if you cut me, do I not bleed?" Uh, no. Corporation, "what if I lay down my employees like cannon fodder? Do I not bleed?" Uh, no, but those people you sacrificed do. Corporation, "well, have you no sympathy for an soulless entity that is designed only for its own perpetuation with no regard for anything that it might perceive as an obstacle?" Uh, no.

Re:Hushmail and full disclosure (1)

gd2shoe (747932) | more than 4 years ago | (#31809690)

Or do they have a moral obligation to their shareholders to not spend money if they don't have to (keep up the bottom line)? Or do they have an ethical obligation?

Neither. They have a legal obligation to look after that bottom line. That means working to keep the company healthy in the long term. They could also hire bank robbers and cat-burglars to prop up the bottom line, but the long term effects on the company will be quite negative.

Anytime a company decides to make short term cuts at the cost of long term gains (to spare the bottom line) they "can't see the forest through the trees."

Are those really problems with res. desclosure? (4, Insightful)

YesIAmAScript (886271) | more than 4 years ago | (#31808232)

None of those problems listed seem to be with responsible disclosure. It's your job to responsibly disclose. And you should protect their secret for a while. After that, it's not really your problem if they won't or can't act.

I agree there are also issues here with relying on code that you now know has security issues. But those aren't anything to do with responsible disclosure either. If you posted it to the internet you'd still have issues relying on them. Same as if you didn't tell anyone.

Look at it this way, when you tell a vendor what's wrong and try to help them fix it, you're really doing it to help yourself. Your doing it because you believe it will be less work than changing your entire system to not rely on their code.

As an aside, I don't get a big rush when I find a problem in someone else's code. Maybe I'm just old and jaded now, but I'm just trying to get everything to work well, finding that someone else didn't do their job doesn't usually make my situation any better (as you indicate here), so I don't relish it.

Re:Are those really problems with res. desclosure? (0)

Anonymous Coward | more than 4 years ago | (#31808258)

Another thing. Why would your company be so keen to maintain relationships with this vendor when it's obvious that they don't really value you? If I were your company, this incident would make me re-evaluate whether there aren't other options as far as relationships go. Unless these folks have a monopoly on functionality, there are probably other vendors who would be happy to work with you to make an economic transition. Anyone with half a brain would make it worth your while to have relationships with them instead of their competition.

Re:Are those really problems with res. desclosure? (1, Insightful)

Anonymous Coward | more than 4 years ago | (#31808386)

Because you might have to change business practices or requisition more software, think of the VP who chose the vendor losing face, that can't happen now. Oh and it would cost the company more time and money, retraining and learning things are so unproductive - the board won't be impressed! At least with a security hole you can blame it on outside forces, and if it is a confidentiality hole, the customers have already paid you .. just hope it doesn't get exploited .. let the customers bear the cost of restitution.

Re:Are those really problems with res. desclosure? (0)

Anonymous Coward | more than 4 years ago | (#31808538)

Your main responsibility is to report to your employer both the technical issue *AND* the lack of responsiveness on the part of the vendor. If you make your point well, the vendor's lack of sensitivity to security issues will be brought up at a higher level, where it matter$ more. Going public with your findings will likely hurt your own company's products and is likely to get you fired. (If there is no response within your own organisation, I'd say you want to leave ASAP.)

Re:Are those really problems with res. desclosure? (0)

Anonymous Coward | more than 4 years ago | (#31809320)

...It's your job to responsibly disclose...

No. It is his job to make sure he isn't knowingly letting his system remain insecure.
Disclosing the issue isn't his job, but is just so he doesn't have to work around the issue. He might back it up with some morality of protecting other users, although that should be the responsibility of the vendor.
If they don't even acknowledge it is an issue, then they are saying that public disclosure should be fine. That is how I'm jaded, but not because of age.

Re:Are those really problems with res. desclosure? (3, Interesting)

dissy (172727) | more than 4 years ago | (#31809462)

As an aside, I don't get a big rush when I find a problem in someone else's code. Maybe I'm just old and jaded now, but I'm just trying to get everything to work well, finding that someone else didn't do their job doesn't usually make my situation any better (as you indicate here), so I don't relish it.

Additionally this guy has the added burden of relying on this company for what sounds like a major part of their IT infrastructure.

If the software is extremely specialized then it is possible there might only be a couple hundred customers.
An anonymous leak soon (Say within 5 years) if this guy mentioning that he found it would be a simple conclusion to jump to to place blame for an anonymous leak.

Remember, a company is not a court, so evidence and logic are not a requirement in producing an outcome.

I would probably hand the info over to a big whitehat group (anonymously if need be, thou an explanation of the situation will probably get the same response) and have THEM claim discovery and report it to the vendor using responsible disclosure.

This way the group can say "You have ___ weeks to release a fix if you like, but on ____ date we will release this exploit to the public."

It helps in the emotional/illogical areas too, as someone at the vendor whom did correctly suspect the customer, will have a much harder time convincing others of that when such a large face is actively and directly taking the blame.
Additionally the vendors other customers will have no reason to have negative thoughts against this one, if there is an active community in any shape around this software.

Where I work, we have a similar situation with the software package that runs our enterprise.
There is still a couple yahoo message groups where customers can post and talk with each other for ways of solving problems. The vendors staff even monitor the group, and official bug fixes have resulted simply from a single IT guy posting a complaint.

It is a wise idea to remain in good standing with such a community, whom might not realize their soon to be public knowledge security problems are the fault of the vendor for not fixing them, and not this customer for being the messenger of bad news.

Re:Are those really problems with res. desclosure? (0)

Anonymous Coward | more than 4 years ago | (#31809634)

I agree with you.

Even more so, it seems like this guy wants to justify the need to put together enough information for others to exploit the security hole, but it's too much effort to do the EXACT same thing for the company. After all, if you have to put forth the effort to explain how the exploit works (or how to replicate it at least), then you've already done exactly what the company asked for, but now you're releasing it to the public instead of the company so they can fix it.

The problem is, for any large software product, an extremely vast majority (90-98%) of all reported bugs or security issues just simply aren't. They either turn out to be user error, or a setting that the user set that is causing the problem, nonexistant, or you aren't able to replicate it. An enormous amount of resources are spent trying to track down issues because the people submitting them haven't a clue. Of course, how many people would be willing to agree to pay for the time the company spends researching your issue if it turns out to be not the software's fault? Not many. Asking the person reporting the problem to provide enough information to replicate the problem, or explain it in detail would/should cut out a large portion of the false-reports, and allow the company to really focus on the problems that can be fixed. Unfortunately, many of these types of issues simply can't be handed off to some junior level programmer to research and requires a more senior level guy that is familiar with the internal workings of the product, and it get extremely expensive.

That's not an excuse, and I'm definately not condoning not fixing stuff that is broken, but at least try and understand that while you may know what you are talking about, these guys probably had to deal with 99 other bafoons that had no clue, and they all claim a major ground breaking bug/security issue that has to be FIXED NOW.

A misunderstanding of responsible disclosure ... (4, Insightful)

Wrath0fb0b (302444) | more than 4 years ago | (#31808262)

IMO, RD is supposed to entail a good-faith effort to notify the vendor and delay public disclosure for a reasonable amount of time (i.e. not dragging their feet) while they push a patch. If you notify the vendor, preferably including a test case, and they refuse to acknowledge that it is a security issue or suggest ridiculous fixes, that's the end of your RD duties. Ethically speaking, you are in the clear. RD requires you to give them a chance to fix the problem before publicizing it, nothing more.

Now, vendor/rube relations are another matter entirely that are distinct from your duty of responsible disclosure. I don't envy being in the situation where you fear their wrath for disclosure but want to do the right thing.

Re:A misunderstanding of responsible disclosure .. (1)

pdwalker (113292) | more than 4 years ago | (#31808394)

Unfortunately, the vendor could take it out on the company.

"Oh, our software maintenance fees have increased by 100% (for you only)"

No, since their company was so dependent on Vendors software, they couldn't realistically do that without paying the consequences later.

Two suggestions:

1/ find some kind of fix, then post the exploit anonymously

2/ report the bug to a third party who will then approach the vendor with a "fix in x days or else we post to the world" proposal. This way, the original party can avoid the potential backlash from Vendor

Re:A misunderstanding of responsible disclosure .. (1)

amorsen (7485) | more than 4 years ago | (#31809140)

The problem is that if you do the responsible thing, the vendor ignores it, and it gets posted to bugtraq, it can be pretty bad for you. Doesn't matter if it was you who posted there or not, or if it was morally right to post it.

You have to make the choice beforehand: either go via the vendor or go via bugtraq, you can't do one and then switch to the other.

This is modern "Capitalism" (-1, Offtopic)

Artifakt (700173) | more than 4 years ago | (#31808266)

A frightening portion of people with good paying jobs got there by getting less well paid people to know more and do more for free, and think it always works. The same goes for the investors at the top. They are the same crowd that demands the government step in and help them keep their positions, and yet tithes regularly to various think tanks and pundits that preach the virtues of 'unfettered capitalism'. Anything approaching a free market would result in them being kicked into the gutters, often literally.
      I'm not sure why this counts as news for nerds, without at least revealing the oh-so-useful details of what vendor and software we are discussing. The type of abuse of business partners, governments and the public at large as described happens just about equally in non-tech areas. It does much more damage than this vulnerability has even the slightest potential to do in areas such as the chemical industries. (To avoid being as unspecific as the writer, I'll suggest anyone who wants to can google for "Canton" or "Little Pidgeon River" plus "Papermill" for just one example).

did you post this in the wrong place? (2, Funny)

YesIAmAScript (886271) | more than 4 years ago | (#31808298)

Or perhaps this is some kind of steganographic secret message you are passing onto one of your field agents?

Your response has nothing at all to do with the situation here.

Re:did you post this in the wrong place? (1)

medcalf (68293) | more than 4 years ago | (#31808474)

Plus, his response is so wrong as to be not worth rebutting. It has the intellectual depth of a 5 year old's crayon drawings, and about as much relationship to reality. Maybe not quite as much relationship to reality.

wow (4, Funny)

phantomfive (622387) | more than 4 years ago | (#31808290)

No. That would be like Toyota telling its customers to buy ejector seats (unsubsidized ejector seats, that is) to resolve the accelerator problem in their vehicles.

Where can I sign the petition to make that happen?? O_O

Re:wow (2, Funny)

magus_melchior (262681) | more than 4 years ago | (#31808582)

You could ask M5 [discovery.com] to mod your car.

The roof mod is extra, though.

Re:wow (2, Funny)

nextekcarl (1402899) | more than 4 years ago | (#31808686)

If they amp the power enough, the roof mod will come free with the first use.

Re:wow (1)

blackraven14250 (902843) | more than 4 years ago | (#31808894)

I don't know how free your skull will consider it.

Not the same thing at all... (4, Insightful)

SwashbucklingCowboy (727629) | more than 4 years ago | (#31808338)

"I've had other vendors demand I spend time helping them understand the issue, basically consulting for free for them. Have you ever knocked on a neighbor's door to tell them they left their headlights on? Did they then require you to cook them dinner? Exactly..."

You say it happens, they can't reproduce it. Thus, you have to help them understand what it is you're doing. It's not unusual for people to think they've found a bug when they in fact have not.

Re:Not the same thing at all... (1)

drdrgivemethenews (1525877) | more than 4 years ago | (#31808410)

Mod parent up. The original poster is either clue deprived or not describing the situation accurately.

Re:Not the same thing at all... (4, Insightful)

Aladrin (926209) | more than 4 years ago | (#31808506)

I agree, too. There is a certain amount of working together that is expected when you report a bug. Even once the bug is identified and reproduced, you should still be willing to help them verify that the bug is fixed as well.

It's even in -your- best interest to do so, so that the bug gets fixed properly and quickly.

I've done this before with thirdparty libraries that had issues with my code. I'll even admit that about 1/4 of the time, it was actually my fault and not a bug in their code after all. And sometimes, the bug fix was extremely simple and I had to jump through hoops to prove that it existed... That's just life.

Re:Not the same thing at all... (2, Insightful)

Anonymous Coward | more than 4 years ago | (#31808542)

not understanding != not reproducible

For all you know, he submitted a 2-page e-mail detailing the problem.

Re:Not the same thing at all... (1)

mjensen (118105) | more than 4 years ago | (#31809340)

I guess the flaw is only important enough for submitter to complain about, not to actually do something about. Most likely bad phrasing/understanding by submitter or developer.

When in IT, weekly I'd get a "My document won't print", when it sometimes gets traced back to "Actually, you can't open your document".

I've had problems with some open source projects, and between my explanation or the developer understanding, it was "can't reproduce". Then I submit a test case that repeats it all the time, and developer goes "Oh, that way. Yup, broken", and the fix comes in soon.

Educational instituion? (2, Insightful)

The Second Horseman (121958) | more than 4 years ago | (#31808348)

I'm betting this is software being used in an educational or other not-for-profit environment. If so, one thing you have going for you is that employees in that sector actually talk to people from other institutions. If disclosing your work-around wouldn't just give away the entire problem, I'd actually publish what you did to protect the application. That way, your peers can decide if they want to do it and get a head start. It puts the vendor on notice that someone is going to notice this problem eventually.

If your workaround gives away the entire problem, that's more difficult. Assuming education / not-for-profit, I'd start by talking (verbally) to peers at schools using the application, and see if you can get some traction that way. A group of pissed-off customers might be more effective. Your CIO may be participating in regional or national organizations, and may be able to talk to his or her peers about the issue as well.

If you just release it on your own in an "in-your-face" way without your bosses signing on, they could decide to take it out on you if the vendor gets pissed or tries to go after you for violating some gag clause in the licensing agreement (some have them) or damaging their business. They shouldn't, but I can think of a couple of really stupid, obnoxious vendors that might.

Large corporate vendor products (0)

Anonymous Coward | more than 4 years ago | (#31808356)

RMS, SAS whatever vendor your working with understand all these programs are filled to the brim with security holes that never go mentioned or patched. EVER. and never will.

As a company your only method security is to 100% limit who has access to 3'rd party vendor programs that contain your data.

Just pretend (its not really pretending is it?) that you are sharing admin user access to every single user of your system and work from there...

try the press (1, Insightful)

Anonymous Coward | more than 4 years ago | (#31808366)

Send you information to the press and ask for anonymity. Watch them jump to solve your problem. Try dgoodin@theregister.com.

That's what *CERT is for (1, Insightful)

Anonymous Coward | more than 4 years ago | (#31808390)

US CERT, or your local version. They can wield the clue-bat on your behalf.

Is it an issue or not? (4, Insightful)

S77IM (1371931) | more than 4 years ago | (#31808402)

The vendor refused to acknowledge it was a security issue.

Then it's either a feature or a regular old non-security-related bug, and I don't see the problem with announcing it to everybody. Right?

  -- 77IM

Re:Is it an issue or not? (2, Insightful)

jkroll (32063) | more than 4 years ago | (#31809142)

The vendor refused to acknowledge it was a security issue.

Then it's either a feature or a regular old non-security-related bug, and I don't see the problem with announcing it to everybody. Right?

If you are really certain it is a valid issue, take a look at their marketing page and find out who their reference customers are. If you can get some of their important customers to raise this issue as well, you may have better luck getting some action on it without disclosing the vulnerability to the world at large.

Is your vendor under any obligation to you? (0)

Anonymous Coward | more than 4 years ago | (#31808406)

If the vendor's software is defective and fails to acknowledge (and thus fix) the vulnerability, then sue them. The legal system is not just for scumbags who try to get rich through frivolous lawsuits. It's actually meant to help people in your situation. Discovery may even give you an opportunity to warn other users of the software without breaking the law yourself.

Sue Them (3, Interesting)

Herkum01 (592704) | more than 4 years ago | (#31808416)

Sue them, take them to court where bad publicity, will scare the hell out them into settling.

As long as they view it as a technical issue, they are not interested. If they view it as a sales/marketing nightmare they will come to the table in a hurry. As for further cooperation, they will suck it up because other customers will see how they react as to how they will treat the company.

Like spousal abuse, as long as a bad working relationship can be hidden they will get away with it other individuals/companies. They only way to address the issue is to make their dirty laundry public.

not a real help. anyway (4, Insightful)

Anonymous Coward | more than 4 years ago | (#31808488)

I had this kind of problem about 15 years ago. It was a real pain. My problem was that I wasn't able to publish my findings as the vendor made pretty clear he'd sue me over that. So I reviewed my requirements on software and found a solution I haven't heard of before - Open Source. Since then I use Open Source and though it has some minor drawbacks I don't regret this step.

cb

There is a great forum for fixing such bugs (5, Interesting)

medcalf (68293) | more than 4 years ago | (#31808496)

The shareholder meeting. Simply note that you reported bug # XXXX some months ago, and it has not been acted on. You wouldn't mention it except that it's a security vulnerability that, if disclosed, would tank the share price for the company. So in that light, when will this vulnerability be addressed? Let everyone else take it from there.

Re:There is a great forum for fixing such bugs (2, Insightful)

Anonymous Coward | more than 4 years ago | (#31808658)

Sure, but how many shares of the company did you need to buy in order to get a seat at their shareholder's meeting? Then the plane ticket to get to the meeting, etc. Not really something most people are going to do - especially the submitter who couldn't even be bothered to help them reproduce the problem.

Re:There is a great forum for fixing such bugs (1)

49152 (690909) | more than 4 years ago | (#31808898)

I do not know the law in his jurisdiction, but here (and almost everywhere else) it would be enough with one (1) share.

Of course you have to foot the bill yourself to travel there.

Dump the vendor (0)

Anonymous Coward | more than 4 years ago | (#31808510)

If the vendor does not respond...
1) Do not install update, notify all that it does not pass the QA requirements. (Think SOX)
2) Send vendor a bill for services rendered.
3) Get on vendor's forum and post the issue.
4) File a breach of contract suit with the vendor.
5) Find new vendor.

And WHY do not have good firewall installed first? That is your responsibility.

Patch it first (1)

junglebeast (1497399) | more than 4 years ago | (#31808560)

If your company sold them security software with a bug, your company should first fix the bug and then give them a patch for it (free of charge).

Not tell them that it's bugged and ask them to pay you to fix it. If they don't want to accept the patched version, that's their problem, but most of your other customers will.

Are you kidding me? (-1)

Anonymous Coward | more than 4 years ago | (#31808578)

If you can exploit the hole and make millions go ahead and do it then retire. Then it will never be your problem.

Using your reasoning, if somebody dropped a gold bar and you kindly inform him and he ignores you, go ahead and pick it up. I do not see anything wrong.

Responsbl disclosure is Security Through Obscurity (2, Insightful)

dragisha (788) | more than 4 years ago | (#31808668)

And we all know what it really is.

Protect your system as good as you can, firewalls, backups, whatever, or just rely on your own obscurity, and publish!

Act surprised, act I-told-you-so, be outraged with whatever happens, and then - in few days - install a patch.

Buy good WAF then blow the whistle (1)

mother_reincarnated (1099781) | more than 4 years ago | (#31808680)

Frankly the web app firewall idea is the most appropriate solution to this entire category of problem for your organization. You should want one, and this is just one more datapoint as to why.

Secondly, if they won't fix the problem (and I don't mean won't do it quickly, I mean won't do it at all) then I'm sure someone else will discover it and anonymously disclose it. ...Cough... Right? ...Cough...

Re:Buy good WAF then blow the whistle (1)

mother_reincarnated (1099781) | more than 4 years ago | (#31808700)

Full disclosure: I work for a company that, among other things, makes a commercial Layer 7 firewall...

Is it profitable to exploit the bug? (-1)

Anonymous Coward | more than 4 years ago | (#31808688)

Go ahead and do it. Use the money to do something people actually care about, like world hunger or human rights.

You told someone they drop gold bars and they ignore you, go ahead and pick it up.

If its not worth the effort to exploit it probably its not worth the effort to patch it.

Suck it up (1)

Vladus2000 (1363929) | more than 4 years ago | (#31808736)

At this point, I wouldn't do anything. If this security vulnerability becomes public from an anonymous source, the vendor will blame you. That is the issue with disclosing it to the vendor, once you have done so, your choices are bend to their will if they won't play ball, or ruin the relationship. I would recommend working towards getting rid of the vendor, as they are leaving your system insecure and not willing to fix the issue. Until that point, suck it up.

Responsible vulnerability disclosure rules (0)

Anonymous Coward | more than 4 years ago | (#31808802)

If they think this is not a security issue, then nothing stops you into going public.
This is how responsible vulnerability disclosure rules are, and will be.

Expose it (1)

shentino (1139071) | more than 4 years ago | (#31808846)

...anonymously.

It's only a matter of time before the black hats find it, so by publicizing it and forcing it in the vendor's face they'll see it for what it is.

Lawsuit? (2, Interesting)

RoFLKOPTr (1294290) | more than 4 years ago | (#31808888)

I don't know what kind of terms are written in your contract with these people (or how big your company is compared to the software company), but maybe your company can sue them for failing to properly maintain their software. Right now, find other companies that use this software and tell their administrators about the vulnerability and let the pressure build on the software company. Give them a little more time to either get their shit together or blow you off and then threaten lawsuit. It would be irresponsible of you for the sake of your own security to publicly disclose the vulnerability, so you should be doing all you possibly can to not have to do that.

Limit responsible disclosure. (4, Insightful)

ErikTheRed (162431) | more than 4 years ago | (#31808892)

Simple answer:

Responsible Disclosure should be limited to vendors that publicly pledge (or, preferably, contractually agree to via their licensing terms) to Responsibly Fix issues that are disclosed to them. If a company doesn't abide by their own Responsibly Fix policy, it should be disclosed so that others realize that it's null and void.

Missing the point. (1)

dwmw2 (82) | more than 4 years ago | (#31808916)

I like the analogy with the neighbour's headlights, but it's kind of missing the point. Why do you *care* whether your neighbour leaves his headlights on? By all means be helpful and let him know, but it's no skin off your nose if he's going to be an idiot about it and his car won't start in the morning.

Which brings us back to the original situation. Why do you care? It's because you have *chosen* to make a mission-critical service depend on a piece of software which you cannot just fix for yourself, so you're beholden to a third party for fixes. A third party who, in your case as in many similar cases, is too incompetent and/or unwilling to help you.

Getting into that situation in the first place does not strike me as being particularly responsible.

Re:Missing the point. (0)

Anonymous Coward | more than 4 years ago | (#31809098)

Though now, if you mention to your neighbor that their headlights are on they are more likely to snap at you yelling 'THEY GO OFF THEMSELVES, NOW GTFO AND STOP WORRYING ABOUT WHAT I'M DOING'

gentlemen (2, Insightful)

headonfire (160408) | more than 4 years ago | (#31809030)

Well, I think it works like this. If vendors as a group want to encourage more "responsible disclosure", they need to operate in such a way that they take potential vulnerabilities seriously, and I don't just mean in a "we're taking this very seriously" kind of way, but more of a "we have a dedicated, knowledgable staff member/team to look into situations like this" sort of thing. If they decide it's not an issue after all, then any responsibility you have to the vendor is over regarding that issue. If they're not willing to even consider it as an issue after you've made a good faith effort to let them know how much of a problem you think it is, any responsibility you have to the vendor is over regarding that issue.

In short, a gentleman's agreement only works if both parties are gentlemen.

Getting their attention (4, Interesting)

Animats (122034) | more than 4 years ago | (#31809058)

It's hard getting the attention of some vendors. I see vulnerabilities in a slightly different context - hacked web sites hosting phishing pages. We distribute a list of major domains being exploited by active phishing scams. [sitetruth.com] This is obtained by processing PhishTank data, and we do this because we want to reduce the collateral damage from a tough blacklist system. At any given time, there are about 30 to 80 domains on the list.

Some sites get themselves off the list quickly. By now, most of the better free hosting services and short-URL services are automatically checking PhishTank and the APWG blacklist to see when they've been hit. Today, if you run a service where anybody can put up a page that could be used for phishing (i.e. it's not full of your own headers and banners), you need automation to deal with attacks. I've been in contact with the abuse guy at "t35.com", which is a free hosting service. They've recently been hit by a flood of phishing attacks, with several hundred new reports in PhishTank per day. The attacks were coming in faster than the abuse guy could clean them out. They're now gaining on the problem, but haven't squashed it yet. Take-away lesson: automate this.

The ones near the top of the list have been there for a while. Note the dates, which are the date that the oldest phishing report still online and active appeared in PhishTank. Some just need help. Typically, these are small organizations like churches and nonprofits that have had a break-in and were partially taken over by a phishing site. I send them the Anti-Phishing Working Group's "What To Do if your Site Has Been Hacked". [antiphishing.org] Sometimes I give them a phone call. They deserve sympathy.

Then there are the hard cases. These are sites with no visible contact address, or a clueless abuse department. At the moment, Google Sites and Google Spreadsheets are being used for phishing. Google is new to the free hosting business, and the phishers have discovered some tricks that Google can't yet handle. While Google puts a "report abuse" link on their site pages, it's possible to set up a file for downloading on Google Sites, and an HTML page can be served that way [phishtank.com] , without Google's abuse checking. There's also an exploit of Google Spreadsheets [phishtank.com] . That one is an example of Habbo Hotel phishing. [bbc.co.uk] We've reported these to Google several times, but they haven't been fixed yet.

We've been seeing a new type of attack recently - a phishing operation breaks into a shared hosting server and plants phishing pages on multiple domains on a single server. One of these hit one of the mysterious "*.websitewelcome.com" servers, which has "cloaked domain registration" and no useful default web page. These seem to be associated with "ThePlanet.com", but whether ThePlanet operates them, is providing wholesale hosting, is providing colocation, or is just the upstream connectivity provider is not clear.

Hiding the contact information of a hosting provider is legally unwise. The hosting provider may lose the "safe harbor" protection of the the DMCA. [cornell.edu] The "safe harbor" provision for "Information Residing on Systems or Networks At Direction of Users" only applies if "the service provider has designated an agent to receive notifications of claimed infringement... by making available through its service, including on its website in a location accessible to the public, and by providing to the Copyright Office, substantially the following information: the name, address, phone number, and electronic mail address of the agent." So when the RIAA or the MPAA come calling, a likely event for a hosting service, they get to go after the hosting provider.

So that's vulnerability reporting in phishing land. Our experience is that occasional nagging will keep that list down in the 25 to 50 domain range. If we stop nagging, it creeps up to around 100. When we first started, there were about 175 domains on the list. Reporting vulnerabilities does measurably help.

The real painful and inefficient thing? (2, Funny)

wampus (1932) | more than 4 years ago | (#31809068)

That analogy. Stop it.

Inform your corporate attorney of all the facts (4, Interesting)

pem (1013437) | more than 4 years ago | (#31809170)

This is not a programming problem any more. Much as we all hate lawyers, this is one case where they are useful. VERY useful. You put him on notice, it's not your problem any more. He puts the vendors lawyer on ACTUAL notice (which has a specific legal meaning). He might even need to tell the other lawyer that he's going to have to report this issue in the next required SEC filing. IMO, if you already have the thing deployed, which it seems may be the case from your post, your FIRST stop should have been the attorney.

Re:Inform your corporate attorney of all the facts (2, Interesting)

Skapare (16644) | more than 4 years ago | (#31809326)

If the OP's company is a publicly traded corporation, and if this exploit represents any kind of risk to investors in any form, they are already required to include it in the next filing.

Where are your (company's) priorities? (1)

Skapare (16644) | more than 4 years ago | (#31809298)

As long as having a good working relationship with a vendor that you and your company knows is incompetent and unethical is more important than your security and the principle of doing things right, then you get what you deserve.

You know what the exploit is. But what makes you think you are the only one? What makes you think no unethical hackers know about and won't find out about it for the life of this exploit (which seems from the vendor attitude that it could be very long)?

You (your company) needs to take steps to protect yourself, now, immediately. Do whatever it takes to make the exploit unusable from within your network and from outside. Send the bill to the vendor ... on your law firm's letterhead. Mention the names of several sleazebag debt collectors for extra points. If you are afraid of ruining your relationship for that, then, again, you deserve what you get.

I also suggest updating your resume and your LinkedIn [linkedin.com] profile, and keep an idea on the Indeed [indeed.com] listings.

Ejector seat? (0)

Anonymous Coward | more than 4 years ago | (#31809376)

James Bond: Ejector seat? You're joking!
Q: I never joke about my work, 007.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...