Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
[ISN] PATCH DELAY? Buffer Overflow in UPnP Service On Microsoft Windows
From: InfoSec News (isnc4i.org)
Date: Fri Dec 28 2001 - 01:12:11 CST
Forwarded from: mrs_aida_capistranohushmail.com
-----BEGIN PGP SIGNED MESSAGE-----
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
- - - 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
Manager, Microsoft Security Response Center
-----BEGIN PGP SIGNATURE-----
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 majordomoattrition.org with 'unsubscribe isn' in the BODY
of the mail.