Forwarded from: mrs_aida_capistranoat_private Cc: marcat_private -----BEGIN PGP SIGNED MESSAGE----- Hi there, I posted this to the main security lists today, but no one seems interested. Chris at vulnwatch.org suggest I send it to attrition and I am copying Marc, in case he wishes to verify this chain of events or not. One can never tell if Microsoft is telling the truth or not :-( Dear Ladies and Gentlemen, The following official statement was published in a Microsoft news group on the 26th of December 2001 when many participants queried why it took nearly two months for a patch to be developed to address the Buffer Overflow in UPnP Service On Microsoft Windows http://www.eeye.com/html/Research/Advisories/AD20011220.html http://www.microsoft.com/technet/security/bulletin/MS01-059.asp It does not explain why these defective goods continued to ship for the Christmas sales season but might be of interest to people on these security mailing lists: direct link to news article on the server: news://news.microsoft.com/#qAgniljBHA.2260@tkmsftngp07 <squirt> We absolutely did not delay in the development of the patch. Here is the timeline for the patch's development. - - - eEye contacted us on 26 October, reporting two denial of service opportunities in the UPnP service. We responded within one minute of the report's arrival, and started an investigation immediately - - - We reproduced eEye's findings by the end of the day, and determined that while the changes needed to prevent the denial of service (DoS) scenario were fairly simple, those needed to prevent the distributed denial of service (DDoS) scenario amounted to significant architectural changes. We discussed this with eEye, and they agreed with our analysis. - - - By 07 November, we had developed a fix for the DoS scenario and conducted preliminary testing on it. We sent it to eEye for their review, while continuing to work on the fix for the DDoS scenario - - - On 14 November, eEye reported that they had found a buffer overrun, and that the preliminary patch we'd sent on 07 November appeared to fix it. We investigated the report and found that there was indeed a buffer overrun and that our preliminary patch had protected against it by blocking access to the code path containing the unchecked buffer. - - - By 06 December, we had completed a preliminary version of a patch that eliminated all of the vulnerabilities: DoS vulnerability, DDoS vulnerability, and buffer overrun. We sent it to eEye for their review, and they agreed that it fixed all of the problems they'd reported. - - - Between 06 December and 20 December, the patch underwent full testing, localization, packaging and release. We released the patch on 20 December. Two points in the above warrant additional explanation: the scope of the changes needed to prevent the DDoS scenario, and why it required two weeks to ready the patch for release. First, let's discuss the engineering changes. As discussed in the Knowledge Base article referenced by the security bulletin, eliminating the DDoS required us to add significant new functionality. The patch introduces two new registry keys. One lets the administrator determine whether a patched system will download device descriptions only from locations on the local subnet, on the subnet or private network, on the private network only, or on external locations as well. (The default value only allows device descriptions to be downloaded from the subnet or the private network). The other lets the administrator regulate how many router hops the UPnP service will traverse in search of device descriptions. (The default is to only allow device descriptions to be download if they are hosted within 4 router hops of the patched system). In addition, we added an variable-delay mechanism that's designed to prevent a patched system from flooding a server with requests for device descriptions. The further away a download site is from a patched system (and hence, the more available the site is to large numbers of UPnP clients), the greater a time lag is introduced in the download requests. Likewise, each time an attempted download fails for some reason, a greater time lag is used in the re-try. All told, you can see that this was a significant engineering change to make via a patch. Regarding why it took two weeks to ready the patch for release, consider a few points. First, we had four patches to test -- one for Windows 98, 98SE, ME and XP. Second, each of these had to be localized into over twenty languages, and every language version had to be independently tested. Third, consider the scope of the engineering changes -- changes this large demanded rigorous testing. Finally, we knew that we were going to need to recommend that every Windows XP user, as well as many Windows 98, 98SE and ME users, download and install the patch. This meant that the patch would be installed by millions of users, running on thousands of different hardware platforms, in conjunction with millions of third-party applications and in countless different configurations -- and the patch had to work correctly on every single machine. Two weeks was barely enough time to complete this testing. While we built the patch, we monitored a number of mailing lists, web sites, and other information sources, looking for any sign of someone independently discovering the vulnerability. If we had seen any indication that this had happened, we would have immediately released a security bulletin advising customers to disable the UPnP service. This would have been a last resort, though -- most users aren't comfortable disabling services, and we knew that the best opportunity to protect customers was through the release of a patch that would restore proper system operation. That's what we released on 20 December. I hope this helps set people's minds at ease. Not only did we not take an excessively long time to build the fix, our engineering teams worked around the clock for the final week before release, in order to get the patch into customers' hands as quickly as we could. For more information on what's involved in building a fix for a security issue, please see "A Tour of the MSRC", at http://www.microsoft.com/technet/columns/security/sectour.asp. Regards, Scott Culp Manager, Microsoft Security Response Center Microsoft Corporation </squirt> Love, Aida -----BEGIN PGP SIGNATURE----- Version: Hush 2.1 Note: This signature can be verified at https://www.hushtools.com wmgEARECACgFAjwro9chHG1yc19haWRhX2NhcGlzdHJhbm9AaHVzaG1haWwuY29tAAoJ EKtZ/2JWWeDFiNAAnRwsmT0gg++QKtLOZ/4GRb5mSRSaAJ91eOtHfFC++uWnssCqkAEq vzlQ4w== =uwS7 -----END PGP SIGNATURE----- - ISN is currently hosted by Attrition.org To unsubscribe email majordomoat_private with 'unsubscribe isn' in the BODY of the mail.
This archive was generated by hypermail 2b30 : Fri Dec 28 2001 - 06:02:27 PST