full-disclosure - How to Report a Security Vulnerability to Microsoft

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20050413172348.GA14901@linux.unixwiz.net>
Date: Wed Apr 13 18:24:03 2005
From: steve at unixwiz.net (Steve Friedl)
Subject: How to Report a Security Vulnerability to
	Microsoft

On Wed, Apr 13, 2005 at 01:01:19PM -0400, bkfsec wrote:
> I agree with you.  I wasn't implying that people shouldn't work with 
> MSFT on disclosures, rather that their attitude had not changed nearly 
> as much as some people seem to think it has.

Microsoft has interests that are not entirely in line with their users,
and certainly not even mostly in line with security researchers, so it's
no surprise that these come into conflict, sometimes painfully.

> There's also a big difference between should and must.  Security 
> researchers should work with vendors to get solutions out responsibly, 
> including Microsoft, but they should not be restricted from publishing 
> their findings if a vendor just wants to sweep things under a rug.

I guess I'm not sure what you mean by this.

If you mean that a vendor is blowing somebody off (not replying, "we don't
think it's an issue", etc.), then I don't have any trouble burning them:
"Not a bug? Oh yah?"

When I got totally blown off by Standard & Poors a coupla years ago,
the only thing that got them off their asses was full, embarrassing
disclosure.  http://www.securityfocus.com/guest/2137  I'd do the same
thing today given the same circumstances.

But if the vendor does get out a patch (even if not timely), releasing
the full details of the vuln on the same day *does* put users at risk, so
we're left with a balance between user interests and researcher interests.

My personal resolution: write two advisories. The first one is released
with the patch, but it doesn't contain a roadmap for how to create an
exploit. This gives the researcher the credit for the initial discovery.

The second advisory has all the details, and I'd hold it until either some
time period (90 days?) or until an active exploit was circulating. This
lets me publish the technical details sooner or later but at least gives
a head-fake to "caring about the users".

And I'm not sure this is entirely a supportable position: if I find some
vuln, I assume others have it too and are actively - but privately -
using it, so my withholding the details might not make any meaningful
difference in actually helping the users.

But - for me - the perception of caring -vs- not caring about the users
is enough to get me to hold off. Others clearly resolve this differently.

Steve

-- 
Stephen J Friedl | Security Consultant |  UNIX Wizard  |   +1 714 544-6561
www.unixwiz.net  | Tustin, Calif. USA  | Microsoft MVP | steve@...xwiz.net