Don't surf from your dev box either
I've always scoffed some at reports of vulnerabilities in Visual Studio.
After all, how many ways is a developer likely to get attacked through Visual Studio?
Through loading and executing malicious code - don't fetch code from people you don't trust, and don't run code that you don't review first.
Through debugging malicious code - don't try that trick on a machine that you aren't going to wipe afterwards.
Quite frankly, a developer should be smarter, technically speaking, than most users, so he or she should be harder to attack. Also, developers (for various reasons) generally have to wipe and re-install their systems on a regular and frequent basis - every six months or so.
But this bug - in an ActiveX control that's installed with Visual Studio, and may be accessible to Internet Explorer, where it's exploited by malicious web sites, that's something that has me reminding all the developers I work with:
A development machine is like a server - you shouldn't be surfing from it, and if you are using a web browser, it should be to visit sites that contain documentation and source code only. Turn off all "active content" options in your browsers on your development machines.
Partly, though, this is a bit of a rant against ActiveX controls - so many get installed by so many different products, and they all seem to want to make themselves available for scripting by web sites visited by Internet Explorer.
I guess it comes down to Programmer Hubris - that developers are convinced that their ActiveX control will be the way to achieve an action, whether on the web, in an application, or as a kind of shared library. And then we have to bring out the kill-bits.
Whenever you consider writing a shared component, or a network-capable program, remember that you're only one half of the programming team.
The other half of your team are intent on perverting your code to their purposes.
And they're really good at doing so.
And they outnumber you.
And they can take far longer to get their half to work.
And it doesn't have to be as solid, or as stable.
You have to be better - or you have to admit that you shouldn't (yet) be writing the shared component, or the network-capable program.