PATCH DELAY? Buffer Overflow in UPnP Service On Microsoft Windows

[InfoSec News <isn () c4i org>]

Forwarded from: mrs_aida_capistrano () hushmail com
Cc: marc () eeye com


-----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 majordomo () attrition org with 'unsubscribe isn' in the BODY
of the mail.