5 ms·

Let me try & put your mind at rest a bit. (a) everyone @ msft takes the confidentiality of data uploaded to Watson (the crash reporting system) extremely serio

by edyoung 16y ago

Let me try & put your mind at rest a bit. (a) everyone @ msft takes the confidentiality of data uploaded to Watson (the crash reporting system) extremely seriously - you can't just 'look for useful stuff' in it without a good reason, and you'd be fired immediately if you were found to be reverse-engineering or copying bits of code out of it b) on a technical level, trawling through dumps looking for 'useful stuff' would be an absurdly inefficient way to do anything. For one thing, it just crashed, which in my book is not usually a sign that you'd want to copy it. c) your crash dump is a drop in the ocean. There are millions coming in. Nobody will ever look at it unless the system picks up that there a multiple millions of crashes occurring at the same point in the same widely-used app, in which case it's possible msft might contact the vendor (if identifiable) to offer to help fix it. See http://oca.microsoft.com/en/dcp20.asp http://oca.microsoft.com/en/dcp20.asp

gojomo 16y ago
Yet surely the virus authors themselves aren't experiencing "millions of crashes" during the early development stages that Heckman is describing. So how does he find their code, given what you've said? Clearly, there must be some red flags which cause even small numbers -- perhaps single -- crash reports to get human attention at MSFT.
- Daniel_Newby 16y ago
  The crash database can be trawled after the hostile code is found in the wild.
  - InclinedPlane 16y ago
    Exactly. Many exploits rely on crashing components of the system. Depending on configuration settings a system may automatically be sending in watson reports for certain kinds of crashes. This makes it possible to track down the origin of a virus / worm after the fact. Step 1: take notice of the exploit in the wild. Step 2: determine it's method of operation. Step 3: correlate watson reports with exploit (likely there will be many of these). Step 4: backtrack to the oldest reports which might be from when the exploit was being developed, then dig out as much information from those reports as you can. Certainly this doesn't work all the time, but even if it worked only very rarely it'd still be a pretty substantial payoff.
  - gojomo 16y ago
    Yes, that must be it, thanks. But then the same thing could apply to non-malicious/competitive code, too. Once it proves interesting to Microsoft, they could mine the past crash history for background info. I can believe internal controls and culture mitigate this risk -- but sheer volume doesn't provide confidence of confidentiality for non-malware coders any more than it does for malware coders.
    - profquail 16y ago
      Look at it this way -- the Watson system is pretty important in improving the quality of Windows (let's assume that more quality -> more sales). If coders (most of whom work in a corporate environment) ever found out that Microsoft was looking through their code for a non-emergency reason, they'd immediately turn off error reporting on all of their systems (not to mention, file a few lawsuits), removing sources of crash errors from a sector that is vital to Microsoft (and leading to a decrease in the quality of Windows, and thus, fewer sales). So it's in their best interests to keep those internal controls as strict as possible in order to avoid such a thing.

by edyoung 16y ago

gojomo 16y ago

Yet surely the virus authors themselves aren't experiencing "millions of crashes" during the early development stages that Heckman is describing. So how does he find their code, given what you've said? Clearly, there must be some red flags which cause even small numbers -- perhaps single -- crash reports to get human attention at MSFT.

Daniel_Newby 16y ago
The crash database can be trawled after the hostile code is found in the wild.
- InclinedPlane 16y ago
  Exactly. Many exploits rely on crashing components of the system. Depending on configuration settings a system may automatically be sending in watson reports for certain kinds of crashes. This makes it possible to track down the origin of a virus / worm after the fact. Step 1: take notice of the exploit in the wild. Step 2: determine it's method of operation. Step 3: correlate watson reports with exploit (likely there will be many of these). Step 4: backtrack to the oldest reports which might be from when the exploit was being developed, then dig out as much information from those reports as you can. Certainly this doesn't work all the time, but even if it worked only very rarely it'd still be a pretty substantial payoff.
- gojomo 16y ago
  Yes, that must be it, thanks. But then the same thing could apply to non-malicious/competitive code, too. Once it proves interesting to Microsoft, they could mine the past crash history for background info. I can believe internal controls and culture mitigate this risk -- but sheer volume doesn't provide confidence of confidentiality for non-malware coders any more than it does for malware coders.
  - profquail 16y ago
    Look at it this way -- the Watson system is pretty important in improving the quality of Windows (let's assume that more quality -> more sales). If coders (most of whom work in a corporate environment) ever found out that Microsoft was looking through their code for a non-emergency reason, they'd immediately turn off error reporting on all of their systems (not to mention, file a few lawsuits), removing sources of crash errors from a sector that is vital to Microsoft (and leading to a decrease in the quality of Windows, and thus, fewer sales). So it's in their best interests to keep those internal controls as strict as possible in order to avoid such a thing.