[ISN] PATCH DELAY? Buffer Overflow in UPnP Service On Microsoft Windows

From: InfoSec News (isnat_private)
Date: Thu Dec 27 2001 - 23:12:11 PST

  • Next message: InfoSec News: "Re: [ISN] First teenaged certified security professional"

    Forwarded from: mrs_aida_capistranoat_private
    Cc: marcat_private
    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
    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:
    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
    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
    Version: Hush 2.1
    Note: This signature can be verified at https://www.hushtools.com
    -----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