An Open Letter to Software Vendors
On the 28th September 2011, we notified a vendor about multiple security vulnerabilities in one of their products, and requested contact details of who to send the details on to.
The initial response from the vendor support team took 6 days.
The complete details of the vulnerabilities were disclosed to the vendor on the 5th October. These included screen shots, HTTP requests and responses, and Proof of Concept code for the vulnerabilities. After that no response was received.
We then sent another e-mail to the vendor on the 11th October, asking for an update on these issues, or if they had even received our original e-mail with the details of the vulnerabilities.
We received no response from the vendor.
On the 8th November, we finally received a response stating “These have been replicated by R&D and they will fix in a later release.” No “Thanks for your help guys”, no dates that these will be patched, no responses to our other queries.
We followed this e-mail up with a response to the vendor, asking to work together on a timed release, and to agree on some reasonable dates. The vendor response was “I have asked for timescales for the fixes and will update you when these are released.”
Now just to be clear, we are not getting paid to disclose these vulnerabilities to any vendors. We are doing this to help make the Internet and networks in general a safer place for all.
We don’t ask for much, just credit for the disclosure of the vulnerability, and a timely patch to mitigate the vulnerabilities. It really doesn’t need to be this difficult to report vulnerabilities, and a little bit of thanks and courtesy never hurt anyone.
To all software and hardware vendors out there, can you please take a few moments to read the Wikipedia article on Responsible Disclosure, which can be found here. Then please try to work with your relevant teams, to make it easier to report vulnerabilities in your code, and work with you.
We understand that not all vendors can afford to hire fully fledged security teams, and most security professionals are willing to help you secure your applications and devices just for the credit of finding the vulnerability in your product. That’s got to be the cheapest application security assessment that you’ve ever had!
Little things, like an e-mail address, or a form on your website to contact your product security team, or even your developers would make the world of difference. This would also help to make sure that we as security researchers, contact the relevant teams within your organisation right off the bat (and don’t get sent around the houses, trying to do you a favour). This way, we can always deal with the same person (or team) within your organisation, and get any vulnerabilities mitigated in a timely manner.
Please guys and girls, help us to help you. We’re giving you free security advice, educating your developers and strengthening your products, all this for a one liner in your security patch disclosure notification.
Think about it…
+1 , Like, I will re-tweet this soon, I will Google+ this too… I totally agree with you!
I started working as a pentest about 6 years ago… the first time I found a vuln in a widely-known product I tried to contact the vendor. It was so depressing to interact with people asking me “perhaps is a configuration problem?” “I’m sorry, don’t you see the code? It’s here, right here, it can’t depend on how they deployed it…!”
Disclosure to vendors takes you time and attention, and answers are never kind. I really think [Secure] Development lifecycle/processes are old and slow for nowaday software security needs.
sc0p,
Really appreciate the support on this one, thank you.
[…] AN OPEN LETTER TO SOFTWARE VENDORS […]
It almost seems like you have not worked in A) A large/medium sized company or B) Have not worked with software development at all.
It’s funny how most of the ‘Security industry’ seems to be mostly like that.
I would assume most developers are busy developing the product, doing bug fixes affecting high priority customers or such.
It takes a few days for things to trickle down and shake the box around for priorities to change.
Sometimes, a lot of times – security vulnerabilities aren’t that severe as you think they are. Sometimes they are.
But I do have to agree that yes, it’s a bit meak to not even receive a “thank you for taking your time, we really do appreciate it”. Even if they’re inexperienced handling external input (Like R&D usually are, there’s filters for that stuff you know!)
Hi Greg,
Thanks for taking the time comment on this one, we really appreciate it.
You have raised a couple of good points, we have worked for large corporations, and also done a fair amount of work with software development companies.We also understand that developers will have other priorities to work on, especially when it comes to their larger clients. To be honest, this is expected in the software development industry as you are well aware, and I don’t necessarily see too much wrong with that, after all we’re all out to make money at the end of the day.
However we do see security vulnerabilities that can compromise the relevant software, (or hardware that it is running on) as severe as well. I’m also sure that the software development companies customers would feel the same way. This is the main reason why it’s so hard to fathom that companies don’t take these things seriously, especially when there’s not cost to them for the discovery of the vulnerabilities.
I do agree though, if we’re talking about a software vulnerabilities that only 1% of the population is likely to be able to exploit, then these can realistly wait a while. However when we’re talking about script kiddies rooting a box quite easily, we feel that this deserves somewhat more attention from the developers/internal security teams.
You raised another good point though about R&D types being inexperienced in handling external input, and this is why there should be security contact information on their web sites. This way researchers can disclose vulnerabilities to the relevant people, then these people can in turn speak to the R&D teams. The security contact doesn’t have to be a security person per se, but they should be able to hold a decent conversation with the developers or R&D teams to handle it responsibly, and understand the level of risk that they are placing on their customers.