Slashdot Mirror
Microsoft To Pay Up To $15K For Bugs In Two Visual Studio Tools (microsoft.com)
itwbennett writes: Yesterday, Microsoft started a three-month bug bounty program for two open source tools that are part of Visual Studio 2015. The program applies to the beta versions of Core CLR, which is the execution engine for .NET Core, and ASP.NET, Microsoft's framework for building websites and web applications. Bounties range from $500 to $15,000, although Microsoft will reward more 'depending on the entry quality and complexity.' The highest reward will go to researchers who've found a remote code execution bug with a functioning exploit and an accompanying, high-quality white paper. On the low end, cross-site scripting or cross-site request forgery bugs with a low-quality report will get $500.
Whoever is working on building this code, we can split any bug bounty money 50/50...
>> Core CLR...and ASP.NET
Those are kind of a big deal in corporate America. If you find a good zero-day in either of those, the market might pay more than that just to exploit it at a single company, let alone a universal exploit. I'm thinking Microsoft may need to put some real money into this program to keep researchers on the light side of the force.
If I knew for sure that I'd win the bounty, and that they'd pay the full $15k, and that it wouldn't take me too long to get it, I'd happily burn a little vacation time.
But otherwise, the mathematical expectation is way too low.
What is interesting however is the thought that developer, documentation and test contributions to open source are unpaid, but security contributions are paid for. Possibly this reflects a lesson of the past 30 years that pretty much nobody in the world is capable of shipping fully secure software for general purpose computers.
"In the quest for truth we must train ourselves to view our favourite ideas just as critically as those we oppose"
I don't think the intent is to motivate full time bug hunting but rather allow those who suspect a bug to have the motivation to dig deeper. This is especially true of those in the enterprise level security consulting where they have a responsibility of testing for vulnerabilities or understanding the source of a security failure at their customer's.
I know people who have monetized exploitation of a bug. The reward is often limited unless you are willing to go the next level of exploitation which has higher rewards but is also riskier and out of range for most (intellectual property theft, email spamming, and general financial theft). Legitimate money for the same findings will deter some from exploiting quietly.
I'm not in any way involved with this specific program, but I do work on VisualStudio.
It's pretty common for all kinds of software projects to take bug reports - even very detailed and thorough ones - from people who ultimately don't end up fixing the bug.
The interesting thing about finding a security bug - especially with the constraints described here - a working exploit and a white paper - it's pretty unambiguous that you've found one. You either have or you haven't.
Now, how to actually fix that bug might be a lot more nuanced.
This statement isn't made to in any way imply that a researcher who could find such a bug _couldn't_ also fix it.
Rather, some bug fixes may be preferable to others, from Microsoft's point of view. And so, my impression is - we're not looking for patches that we'd end up re-writing. We're looking for the really nasty bugs, and then we'll go off and come up with fixes that satisfy the big pile of requirements that we have [for example, performance impact]
A valid observation would be, "if these were really open source projects, anyone in the community would be able to run the same regression and performance tests that Microsoft would run, and thus be able to make perfectly valid fixes themselves"
Well, to a point. Long long ago, I found an IDE driver bug in OpenBSD and submitted a fix for it. The fix was substantially re-written by the maintainer, and, ultimately the whole subsystem was replaced in the next version anyhow.
My fix met the functional requirements, so near as I can tell. But there are things like coding style, or maybe even the personal preferences by the project maintainer(s), that can still impact how a particular patch gets rejected or modified prior to being committed.
Furthermore, I think we would hate for there to be a vuln out there that somebody knows about, but is sitting on until they can come up with a fix that they like.
So, yes, I think we really just want the vulnerability reports, well substantiated and with demonstrated exploits. Finding those things is still very much a niche skill.
Fixing them, once they are understood, and balancing those fixes with the other requirements in the system, is more bread-and-butter Microsoft engineer stuff.
fwiw, I've been at Microsoft 15 years, much of it in VisualStudio. Before that, I worked only with UNIX systems, and I've stayed up to date as a hobby.
The way we are trying to engage with Apple, Linux, and F/OSS in general is completely unlike anything we did up until just the last year or so. People I've worked with for years are suddenly diving headlong into Linux development. Arguments that I tried to make a decade ago are now being made by other people.
It's a really interesting time at the company.
My opinions are my own, and do not necessarily represent those of my employer.