Why Is Free Vuln Disclosure so Damn Difficult?

Xyberpix described how difficult it is to disclose vulnerabilities to ZDI and iDefense. But even after you sold it, the process is just beginning. Sure, the researcher gets paid and he is free to resume his work, but the work us, the vulnerability coordinator, just begins.

We recently received 2 disclosures to our SecuriTeam Secure Disclosure program for Sonicwall and google vulnerabilities. We received sponsors for both vulnerabilities which means there is a commercial organization out there that was willing to pay the researcher for their efforts. That part ended well for the researchers.

Now both organizations want the vendors to patch up. Sounds easy, right? We are giving Sonicwall and google free information about security holes in their products, and want nothing in return except for them to fix it.

Well, it’s damn difficult.

Google is always difficult when it comes to security. When I reported an information disclosure vulnerability in google calendar they ignored me, then sent their PR person to say “it’s a feature”, then silently fixed it claiming it was never there. Dealing with google on security issues is like talking to a girl that speaks a foreign language. But more on that later – lets start with Sonicwall.

Wouldn’t you be expect security vendors to be more aware of security problems in their products? Well, for the last few weeks we’ve tried to bang every door, calling in personal favors to tell Sonicwall (for free, let me remind you) about a security hole in their product.
Why bang every door? Because they won’t talk to us since “we’re not Sonicwall customers”. We can’t open a support ticket and they won’t give “us” support. security@sonicwall? yeah, right. Even good friends couldn’t help. The system will not accept a report from non-customers.

I guess our only course of action is to pay Sonicwall money to let them know about their vulnerabilities. I wonder if that’s Sonicwall’s long term strategy for profit? BTW, if you work for Sonicwall and can help, please contact me – but keep in mind paying Sonicwall for telling them about their own security issues is not a part of our plan.

Back to google. The story there is simple and boring. It’s not a bug, it’s a feature. In fact, every browser has this problem, errm I mean feature. In fact, it’s been proven you can execute javascript on the chrome user’s browser so we’ll leave this open as well. If the stupid web app developers can’t solve this we certainly aren’t going to help them.
But why am I boring you with the broad strokes, go read the discussion:
http://code.google.com/p/chromium/issues/detail?id=46795. Nothing we haven’t seen with previous google security bug handling, just ask this guy.

Yes, it is 2010, and we are still talking about Vulnerability Disclosure to vendors. I guess next we’ll be arguing if heap overflows are exploitable.

Update: We were contacted by Sonicwall and the bug will be looked at. Hopefully security@sonicwall will start accepting submissions from non-customers.

Share
  • me

    I’ve escalated it to 3 people I know at SonicWALL BE, for what it’s worth. In case they get back to me can you provide me contact details through e-mail ?

  • http://www.BeyondSecurity.com Aviram

    @me – thanks, and my contact details are aviram at beyondsecurity.com

  • http://www.xyberpix.com xyberpix

    Aviram, have you tried posting to Full Disclosure asking if there’s any Sonicwall contacts on there mate?

  • claudio

    Well, the full disclosure movement started some fifteen years ago exactly because vendors etc. were not responsive to “free and responsible” notifications, which were prevailing at that time. There is no reason to doubt that, whenever given a chance, vendors will still consider security as a PR issue.
    Here you can find an interesting piece of history:
    http://www.greatcircle.com/firewalls/mhonarc/firewalls.199311/msg00070.html
    http://www.greatcircle.com/firewalls/mhonarc/firewalls.199311/msg00083.html
    The exploit code was published mostly because vendors were not clear about which (modified) versions of sendmail were vulnerable.

  • http://www.BeyondSecurity.com Aviram

    @xyberpix: no need to post in FD, I have plenty of Sonicwall contacts. The problem is, until this post they couldn’t help since internal policy was to only accept bug reports “from customers”.

  • http://www.sonicwall.com Cristiano

    Sounds strange that no one was giving you the opportunity to talk and explain the bug or the vulnerability …..
    I would like to know (if you have time and want) what was and especially i would like to provide you one more contact that is me :-)
    feel free to write me directly or phone call me if needed
    thanks for your help and activity

  • http://www.sonicwall.com Cristiano

    Problem Definition:

    A vulnerability was disclosed publicly to SonicWALL in the most responsible way possible, which allowed us to create a release of firmware with a fix before the vulnerability was publicly announced. The nature of the issue is “A cross site request forgery (CSRF) vulnerability exists which can allow a specifically constructed string to be executed in the context of a Web browser.” The conditions under which the issue occurs: This can occur when certain input is entered into the Web or SSH interface of the device.

    This vulnerability was identified and submitted through the SecuriTeam Secure Disclosure program working with Nikolas Sotiriu.

    Thanks Nikolas !!!

  • http://www.BeyondSecurity.com Aviram

    Thanks Cristiano!