Monday, September 26, 2016

Reporting Vulnerability Policy

After several years of actively reporting security bugs to various vendors I came to the following conclusion:
  • A vendor will usually sit on a critical bug as long as he can. Response teams like MSRC, are particularly good at it. I've seen cases where a critical RCE took more than a year before a patch came out.
  • While they usually pretend to care about end-users, most of the time a security patch is released when timing is opportunistic. For example, Server side bugs (RDP, AD/SMB, Lync) month is usually June at MSRC:
  • We only see how long a vendor took to fix a vulnerability when there's an actual advisory with a timeline. Usually the average time is 7-9 months.
  • Taking even 6 months to fix a simple length check is simply not acceptable. It doesn't show in any way a commitment for the security of their users.
Although I must say that I had the opportunity to work with productive vendors in the past for the same kind of bugs I submitted to MSRC. For example, with Samba's Security team, a technical answer was usually sent within 2 hours after submitting a security bug and was fixed across all their branches within 1 week at most.

After some constructive discussions with MSRC lately I decided that I don't want to somehow contribute to this scheme and that things need to change.

Starting today, vulnerabilities already submitted to MSRC will be announced publicly (vuln title, criticity, vuln type) on this blog, but no technical details will be provided to the general public until a patch is out or until my vulnerability disclosure policy agreement has been breached (taking more than x months, for example). Users will be able to track the time it takes them to patch a critical issue and will pressure them if they feel the timeline is unfair. Communities are great for that.

NAC, IDS, IPS vendors might receive ready to go signature for a fairly low price on a case by case review, I don't want any of this ending in any gov's hands before a patch is out. Therefore, selected security vendors will be able to protect their users from critical 0day attacks several months before Microsoft finally decide to protect them by releasing the actual patch.

I invite any frequent MSRC submitter to join me, if they feel like MSFT or any other high profile vendor is sitting on their bugs, it can also be hosted here or published in the same way on their websites.

Users win, you win, I win.

GPG public key: AD0D 60A7 FDAE 1443 F439 D6B1 8DA2 BA12 402E 6A77


Post a Comment