Many Hackers Accidentally Send Their Code To Microsoft 220
joshgnosis writes "When hackers crash Windows in the course of developing malware, they'll often accidentally agree to send the virus code straight to Microsoft, according to senior security architect Rocky Heckman. 'It's amazing how much stuff we get.' Heckman also said Microsoft was a common target for people testing their attacks. 'The first thing [script kiddies] do is fire off all these attacks at Microsoft.com. On average we get attacked between 7000 and 9000 times per second.'"
Re:How Does It Encapsulate the Source Code? (Score:5, Informative)
Re:So then what's with the wait? (Score:3, Informative)
I know you're jesting, but aside for their download/msdn sections sometimes being hosted by a third party who actually does run Linux, Microsoft.com for the most part runs on IIS. Not only that, but its actually hosted on SharePoint.
Re:How Does It Encapsulate the Source Code? (Score:4, Informative)
compiled byte code in the utilities they use would do you little good unless you were extremely patient
Many people in the Windows OS team only debug at assembly level. For e.g. Raymond Chen.
http://blogs.msdn.com/b/oldnewthing/archive/2004/11/11/255800.aspx [msdn.com]
"1. Once the optimizer has messed with your code source level debugging falls apart.
2. Most debugging is done remotely. When you have to debug a customer's machine 5000 miles away over a 56k modem, you can't tell them, "First, I want you to install Visual Studio on your domain controller..."
3. Installing a GUI debugger on the test machine changes the system configuration and therefore influences the test itself. Imagine if Windows XP had some horrific bug that goes away when you install Visual Studio. If all test machines had Visual Studio installed on them, then this bug would never be found!
4. Just today I had to debug a problem that occurred only immediately after installing the OS. No chance to install VS even if you wanted to.
5. If you're debugging the OS itself (say the window manager), then you can't use a GUI debugger since it needs the window manager to draw its UI!
Conclusion: Since so much debugging is done in situations where GUI debugging is not possible, you are quickly forced to become an expert at command line debugging. At which point the incremental benefit of a fancy debugger is rather small.
"You can't possibly debug any significant size project in this fashion."
Shhh, don't tell the Windows team. Not all debugging is done at asm-level, but a significant chunk is. They'd be pretty disheartened to learn that what they're doing is impossible.
Re:How Does It Encapsulate the Source Code? (Score:4, Informative)
I don't think Microsoft really cares about fixing application crashes other than for their public perception. They would be concerned that a Windows crash was possible in some particular way, and didn't recover/fail gracefully - and this boils down to the code that is sitting below the application code so they wouldn't need your source.
The only data that could be sent would be data currently in the memory space. So if the process had *str1= "Need to buy groceries: meat, eggs, cheese" , *str2 = "Assassinate the president at 17:30 on Tuesday", they would be able to see that by debugging through the stack variables and looking at where it's stored (i.e. heap). I'm not precisely sure how minidumps are configured - they may not include heap information.
Re:How Does It Encapsulate the Source Code? (Score:1, Informative)
Really guys. You're talking about Windows, which has billions of dollars in corporate invested developer money. Microsoft isn't snooping on your revolutionary code. Lay off the FUD please.
Re:How Does It Encapsulate the Source Code? (Score:5, Informative)
When the hacker's system crashes in Windows, as with all typical Windows crashes, Heckman said the user would be prompted to send the error details — including the malicious code — to Microsoft. The funny thing is that many say yes, according to Heckman.
it doesn't explain how the "error details" comes to be "including the malicious code". He goes on to say
"People have sent us their virus code when they're trying to develop their virus and they keep crashing their systems," Heckman said. "It's amazing how much stuff we get."
System crash implies a bluescreen - which further implies a memory dump -- but R-ing TFA doesn't answer the question one way or the other.
Re:So now crackers have a new way to attack Micros (Score:4, Informative)
Actually, Microsoft does fix bugs based on these reports. http://blogs.msdn.com/b/oldnewthing/archive/2010/08/04/10045651.aspx [msdn.com]
Re:1-2 billion concurrent internet users? (Score:3, Informative)
.. out of which 0.1% is developing malware?
Or even better, of which 40-60% are malwared and target MS.com?
That would imply that those 1-2 billion concurrent user all use a Windows computer.
Please share your references used with us
Windows has an 85% market share (conservative estimate) It's general common knowledge sourced in a great many places.
As for infection rates? Here is a simple graphic. Again a search will turn up more info.
http://i.zdnet.com/blogs/apwg_pandasecurity_crimeware2.jpg [zdnet.com]
from: http://www.zdnet.com/blog/security/report-48-of-22-million-scanned-computers-infected-with-malware/5365 [zdnet.com]
It shows of 22 million scanned computers, 48% were infected.
I don't think my statements were unreasonable in their assumptions. It would be like me saying the US population is somewhere over 300 million. I'm not a research paper, and this isn't a journal where sources are always given.
Re:How Does It Encapsulate the Source Code? (Score:3, Informative)
Windows Error Reporting only sends mini-dumps. You won't see code or contents of notepad/word etc. You get the callstack for all running threads, exception information that caused the fault, list of all loaded modules and processor context for all threads.
Re:How Does It Encapsulate the Source Code? (Score:2, Informative)
The reason the article doesn't explain how Microsoft crash dumps work is because no one understands them.
This guy seems to be closest to understanding of anyone I've found:
http://www.wintellect.com/CS/blogs/jrobbins/archive/2009/05/11/pdb-files-what-every-developer-must-know.aspx [wintellect.com]
Re:How Does It Encapsulate the Source Code? (Score:2, Informative)
So, you gave up on bugfixes and new features for MP3Tag because they added an optional update checking mechanism...
Yes, yes I did avoid bugfixes and new features, as the principle of privacy is more important to me.
The choices are use an old version of the software, use a current version and live with a lower level of privacy (the application notified the developer each time the application was run, IIRC), or use a different product. As I quite like MP3Tag, I took the first choice, though have been keeping my eyes peeled for something to fit category 3.
MP3Tag, even though it is freeware, isn't OSS. I would rather use Free software whenever possible these days. The more software has features that possibly benefit the developer or publisher more than the user, the more I step away from using their products at all.
A developer doesn't want support questions from users on old versions, and an update mechanism helps push users onto the new versions. For for-profit entities, the fewer versions the user base are using, the lower the support costs.
and Microsoft is violating your privacy because they offer you the option to send a report if an application crashes.
An option that is ticked by default, in not a simple to find place. Any declaration of privacy compromise will be hidden away in pages of legalese that very few people read, and fewer understand.
I know I don't understand legalese, nor the inner workings of Windows, or other proprietary products, so I act sceptically about anything that is said.
It's insane that stuff like that get's modded up.
What is insane is how the user is seen as secondary to the desires of the developer[1], or the business' interests, and that people accept this shit situation!
[1] Though a simple utility can be someone's pet project. As much as users might bitch, its is ultimately up to the developer how the application works, and what features are there or not. The user is free to walk away when they like.
Re:How Does It Encapsulate the Source Code? (Score:2, Informative)
Nice to think being a muppet is worth modding up.
Also, you have to trust the optional submission isn't buggy, and does what the user wants. Yeah, that's clutching at straws, but I can think of at least one instance of proprietary software privacy raping when it shouldn't have been. Real, years ago, was "accidentally" uniquely identifying installations of its player when it declared them anonymous.
The data collected via crash reports and update checking mechanisms could have commercial worth to the vendor. They have a financial interest in possibly misleading the user as to exactly what the update checks or crash reports do.