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 :)
That explains it: this is a Schabse bug. He reports bugs like: when you have 4 levels of nested generics with an overriden indexed property going through ComImport, the modopts are incorrectly copied into the method signature, causing a runtime crash in the CLR.
My guess would be that it's an automated build / deploy system that required some addon installed to run, so they had to run `devenv /build` instead of using msbuild. Then they saw this behavior on one of their build machines when something wasn't installed correctly and the process just terminated, after 71 retries...
Source: I was on the visual studio environment team a decade ago, and Rube Goldberg himself could not design a build process that would surprise me, at this point.
That makes sense... I was imagining that there was some build process that froze VS 99% of the time and some poor developer was sitting at his desk silently crying into his coffee trying over and over to get his project to build so that he can go home for the weekend.
One main project (open all day) and small projects throughout the week/month with a machine never shut down? I can see that happening easily at web agencies and the like.
Step 2 in the reproduction case also includes shutting down the new instance, so I think there is only ever a maximum of two instances at a one time. Seems that the unusual bit is that 70 instances are opened without ever closing the very first instance.
It's not multiple instances running at the same time, step 2 kills an instance. It's one "main" instance running continuously, then opening and closing a second instance over and over.
Maybe it happens if you click on a cs or sln file and then press shift and click somewhere else. This might select all sln or cs files and invoke open on all of them, launching many instances at once. Happened to me once with another programm
I don't think you can always expect your users to do the reduction and the debugging for you, they pay you for a bug free product. In this case it's a developer-centric product, so I guess the bug reports are more geeky, but customers are not here to serve the developers.
A nitpick but it's really important that HNers understand it: users do not, in fact, pay for bug free products. They pay for products which achieve the benefits promised to them, bugs and all. If they wanted to buy bug-free products, they'd a) make decisions about software adoption driven primarily by externally visible indicia of bug-freeness and b) pay prices similar to that paid by e.g. the Space Shuttle or flight control systems. Users do neither of these things for most software.
Agree, I should have made that clear in my comment. in fact I've found that a) the product devs should be able to find the cause much faster than you can, b) it's more effective for you to spend your time developing a repro script/code/etc, because unlike describing a bug, this is unambiguous and the devs can run it very quickly to verify tat the issue can be reproduced on their end.
Agreed but I was confused by the MS response of "Thank you for submitting feedback on Visual Studio and .NET Framework." It seems like the bug is in VS and not .NET. Are they that interweaved these days?
The bug report frontend is for both. The Thank you is just an automated response that it was seen. Generally, lots of the official replies on Connect seem to be either text building blocks or canned responses. Not terribly surprising, either, I might add.
in 1998 I was working with VS and had a bug with OCX and was told that the bug was due to VS not working with the current IE version as well in places and was fixed in the new release of VS due out.
So I'd say very interweaved if history has its design legacy mantra.
IIRC Internet Explorer used to overwrite the shell DLLs which contain a lot of random helpers and stuff that is not strictly shell related but tempting to make your application depend on. I remember this being a frequent source of "app not working, probably works on the developer's machine" type issues, especially in the time period where this was changing a lot.
haha, yeah, it's really funny:
"Do not open more than 70 copies of Visual Studio and do not, in any case, choke the artery! What's wrong with you? Choking the artery! Have nothing better to do?"
They might be wanting to run automated tests to find some other problem, and find after 70 tests, they get an error.
So it's sensible to want to fix it.
Would the GetLinesFromFile() memory leak cause performance issues on anything outside of this example?
Its hard to think of a broader usecase.
Though I would suppose its annoying that it eats memory on an older machine. But since it will only be updated for VS 2013 that wont matter until the newer machines get old.
Slight affect if doing long running performance testing?
"It depends". If I'm getting this out of a user support case, I can't really do that. The support person in question might get an earful... actually, tense correction, support people have gotten earfuls from me on the virtues of filing the moral equivalent of "it doesn't work"... but for the customer's sake I can't just smash the bug report closed and smile smugly.
I run multiple instances of vs.net and don't reboot every week, In my case, I'm cycling through at least 10 instances a day. This bug report is actually interesting (to me).
I've killed so many devenv.exe in my career that there must be some kind of warrant on my name in Redmond.
I agree that vs.net is not really pertinent to the core 'hacker' audience here, but this bug report is actually relevant to me, and I didn't get it from my MS-oriented feeds.
I should read HN's FAQ, but aren't articles making it to the front page by being upvoted from new?
Entitled "XL97: Data Not Returned from Query Using ORACLE Data Source", one of the solutions reads:
Method 2: Move Your Mouse Pointer
If you move your mouse pointer continuously while the data is being returned to Microsoft Excel, the query may not fail. Do not stop moving the mouse until all the data has been returned to Microsoft Excel.
I'm sure some large bank has employed a data operator to do this at some point. It's a job I guess.
In case people think you were being sarcastic (and maybe you were), a large bank used to pay me $10/hour to push F11, F7, F7, F2 for the first 2-3 hours of each day.
That was the sequence to accept a security transfer and print the screen (hundreds a day). Then I would match the print-outs to trade confirmations and type the data back into a spreadsheet. Sort of a digital equivalent of digging a hole in the morning and filling it back up after lunch. It was supposed to be a temp job for a couple weeks until the fancy new system was ready, but I quit after 6 months.
hehe.... i wonder if they will fix it or simply accuse you of being an idiot several times over before reading the bug report and realising its genuine. :P
what i find much more interesting than this kind of bug though is that there are several possible ways to expose vs bugs with one step after making a new project in the current version...
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?