Not that this is a major bug, but it makes me wonder why a bug report of this detailed nature (basically doing the debugging for Microsoft engineers) shouldn't be eligible for a bounty, just as exposed security flaws are.
For this bug, it would be a very small or non-existent bounty since this use case affects almost no one, but what if someone found a major bug that was not a security issue, and worked out the cause and fix, as was done in this case? Is that so much less valuable than a security issue?
Bounties exist for security bugs to make it more profitable to report the bug than it is to exploit it, or to sell knowledge of it to those who would. A buy about opening 70 copies of Visual Studio is unlikely to be very profitable to exploit.
Please tell me, what do I need to do to sell to nation states? I've found lots of remotely-exploitable (as in root or direct financial gain) in open source and commercial software. Vendors have poor responses[1] so I've stopped disclosing but if I could legally convert them into cash I'd be very interested in knowing how. For now I'm just keeping them because I might decide to open an auditing company some day and they'd be good marketing.
1: Once a company got angry and blamed me for delaying their shipping cycle. Another time they laughed when I suggested their memory corruption might be leveraged for escalation. And another vendor told me "buffer overflows would only happen maybe if you had a very fast network IO".
I wonder what pricing is like for industry-specific systems. Places where a operational leak can easily cost $$$$$ a month and go rather undetected and certainly not prosecuted.
I suppose that's only valuable to criminals. Sorta like saying knowing someone's bank info can let you steal money - no one legit will pay for it.
And what if instead of $10 and $9, it's $75,000 and $1,000? And you live in an Eastern European country, where the former will feed your family for years.
Do we have the numbers on what percentage of disclosed bugs are from Eastern Europe/"poor" countries? My guess is that gray-hat researchers take into consideration their likelihood of being caught when considering the bounty.
It would be interesting to know the percentage of people from less-developed countries who choose to claim bounties rather than exploit the bug vs. that of people in more-developed countries. I think you would probably find that fewer bug bounties are claimed by researchers in countries with less computer crime enforcement. I think you would also find that raising the payout for bug bounties would affect that likelihood.
You're right. I shouldn't have said "more profitable"- obviously you're going to get more money immediately by exploiting a bug that gives you direct access to everyone's bank account. What I should have said was "more attractive".
If I have to choose between 5 year's wages with a 90% chance of going to jail for a very long time vs. a month's wages as a bounty and a 0% chance of going to jail, I'm going to pick the bounty every time. I think a lot of people would agree with me.
As discussed further down in this thread, raising the value of the payout or lowering the possibility of being caught makes the other side more attractive.
(of course, I would choose to disclose every time, because I'm just a good person.)
I don't think the bounty is all that significant in deterring any would-be exploiter. Instead, it incentivizes the honest person who enjoys the puzzle of finding the exploit but would never actually try to profit from it illegally. It might allow some of those "hobbyists" to justify a little more time at the task, or attract them to one project over another.
The risk of getting caught isn't constant, it's highly dependant on the circumstances and the perpetrator.
Also, besides the crime itself, spending a large sum of ill gotten money without getting caught is a lot easier if you already move in an environment geared for that - few things you can do in a middle class lifestyle that won't arouse suspicion.
Realistically companies including Microsoft will pay as little as they can to anybody and if they get such nicely detailed bug reports for free why would they ever pay.
Bug bounties also pay for the work an individual puts in on x-random company's product. The time taken to figure out and fully demo a POC isn't inconsequential.
Just general observations from things like the rate of pay differences between the army and blackwater.
I'm imagining that if you phoned up the CIA/NSA to sell them a vulnerability that they would not pay you and instead would send some lawyers to seize the info under a flimsy pretext.
For the most part the gov't acts like working for the gov't is some noble thing worthy of losing pay over, as if it was some special honor to die being paid $40K per year instead of $400K per year.
That said if you can contract something out to the gov't through official channels they'll pay the stupidest rates imaginable. So I guess if there was an FBO contract for vulnerabilities you'd probably do quite well.
> The bounty "prize" is you will eventually have a working product to use.
While an IDE running under Windows is hardly what I would like to work with, a bug that manifests itself only on such extreme circumstances cannot be called a showstopper.
I would worry more about other instances where this Peek() method is being misused like this, perhaps on other situations that happen more frequently than Visual Studio 2013 starts.
As a prize, a Microsoft T-Shirt, a gift card and some public recognition wouldn't hurt. The person who reported this bug did a great job of pinpointing its cause.
I sent a package of branded stuff to someone once - stuff I bought out of my own pocket at the company store - and got upbraided for sending such shitty gifts. Won't make that mistake again.
I also worked for a startup where we had a handful of users that really went above and beyond reporting bugs. We sent them $25 amazon gift cards as thanks - the feedback was we were being cheap. One of those gift cards has yet to be spent, years later.
It's not strictly rational but when you are giving extrinsic rewards, like a gift card, they are not perceived as an added reward but as a replacement. What did they replace? The intrinsic motivation/justification that prompted them to perform the action in the first place.
When the motivation switches from intrinsic (I'm doing this because I'm a good person) to extrinsic (I'm doing this for money) we use a different value of judgment which in this case appears to not have worked as well for you as you would have liked. Instead it may have been better to offer some form of recognition/acclaim to reinforce the intrinsic motivation and promote this behavior. For example helping people on stack overflow rewards you with feeling good about being a productive member of a community; the "reputation" score reinforces that same fact. Now imagine instead of having the reputation score mechanic you were paid 25 cents for every accepted answer instead? Would we have seen the same adoption or would people have not bothered "working" for a few dollars an hour?
Hey, I think sending some cash is cheap too. It is that "you are worth exactly $25" I hate. If it were - - a public thanks, that would be way better than anything.
Either send nothing, or do something good. This bug is not major, but as you said "went above and beyond" some cheap giftcard only implies "you got your $25 that you worked so hard for and we are not grateful anymore, it was a nice trade." These people usually do this because they like it.
This is my point of view and not necessarily right nor wrong.
Yes. I used Visual Studio since 97 (and other Microsoft development tools that eventually merged into VS since 1991). I used VS more than any other development tool until 2001 or 2002. Used it occasionally until 2010. Visual Studio is a very good IDE, but, unless whatever you are developing is designed to run (or be served from) Windows, it's not particularly useful.
My problem is not with Visual Studio, but with Windows. After many years using Macs and Linuxes, Windows is an incredibly confusing environment. With Linux and Macs I always know what to expect. Trivial things like setting up wireless networking or a network printer or a multi-monitor setup often involve downloading a program that will install an application that will manage what you want to do. It's insulting to have to download a hundred megabytes of stuff just to use a printer and then have yet another icon somewhere on the screen that doesn't even visually merge with the rest of the environment.
And then you have an environment where you can't even delete an open file. Or eject a USB stick just because some program decided to quit in an unclean way and leave a file open.
After you get used to a consistent and predictable platform, using anything else becomes almost intolerable.
I think Windows rot stopped being a thing since XP. Windows 7 and Windows 8 installations rarely slow down over time, unless you're installing toobars and adware.
I have a Windows 7 that suffered Windows rot over the year I used it. I finally gave up and went back to the Ubuntu share (despite the Toshiba brightness bug) when Windows refused to suspend properly.
I have used it and I have to agree with the grandparent. It is probably one of the worst IDEs I have had to use. Bloated, slow, and in my way even on a modern multicore machine with 8+ gigs of memory.
Of the IDEs I have worked in (Turbo C++ v3.0, Borland C++ v3.1, NetBeans, Eclipse, Rubymine, DrScheme, Turbo Delphi Explorer, RAD Studio XE5, EiffelStudio, GNAT Pro, Visual Studio 6, 2010 and 2013, along with several embedded C environments), Visual Studio is my least favorite. For C++ development on Windows I prefer Eclipse or SublimeText for editing, build using the command line, and debug in WinDbg in order to avoid the awfulness that is the Visual Studio GUI.
Over the years I have used NetBeans and Eclipse a lot. NetBeans could be beaten for J2ME and was fairly decent for Java web applications. Never really used it for non-web stuff, but it seems reasonable. Eclipse is a complex beast - it's the Emacs of Java (I've jokingly called it Egacs after its tendency to consume all available memory) and is incredibly modular. With that modularity comes complexity and some brittleness. I've used Emacs mostly for Java web application development, but used PyDev for a while. I also used the Eric IDE for Python, but now I write mostly Python and I just use Emacs as my text editor, ipdb (or pdb, when ipdb is not an option - looking at you, Google App Engine) and a couple terminals.
In my experience the "bounty" is faster attention to the issue from the devs (no-one likes to spend a lot of extra effort on trying to work on something that is vague, ambiguous or confusing), a better chance that a fix is created quickly and addresses your actual issue, and that it creates a good working relationships with the devs for working with them in the future (builds karma). I like to think of it like keeping up my end of the implicit user/Dev contract :)
For this bug, it would be a very small or non-existent bounty since this use case affects almost no one, but what if someone found a major bug that was not a security issue, and worked out the cause and fix, as was done in this case? Is that so much less valuable than a security issue?