Notes and updates: -Proof of concept code was sent on 17/09/2016, no confirmations or real updates were received since then.- 28/09/2016: Issue confirmed by MSRC, they are planning on releasing a patch on each affected platform.- MSRC informed the bug submitter that they are planning to release a patch on November 8, 2016, that is a full month in advance of the 3 months deadline.

Bug Title: SMBv2 Remote Memory Corruption.

Affected software: Microsoft SMBv2.

Type: Memory Corruption.

Submitted: 25/09/2016.

Coordinated disclosure agreement expiration: 25/12/2016.

Notes and updates: - MSRC is currently investigating the issue.- Microsoft confirmed the issue on 28/09/2016. - Bug submitter extended his coordinated disclosure agreement to 1 more month, due to certain circumstances around this issue.

Bug Title: Microsoft Active Directory PDC Remote Code Execution.

Affected software: Microsoft Active Directory

Type: Protocol Abuse

Submitted: 09/12/2016

Bug status: Implemented in Responder v2.3.2.2

Notes and updates: - Proof of concept code was sent on 12/09/2016, Microsoft is planning to release a security fix "over the next few months".- Additional proof of concept provided on 02/10/2016 leading to privilege escalation.

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.