Re: Xato Advisory: FrontPage DOS Device DoS

[Microsoft Security Response Center <secure () MICROSOFT COM>]

-----BEGIN PGP SIGNED MESSAGE-----

We'd like to set the record straight as to the reports and
speculation regarding the Front Page issue.

First, we stand behind our decision to fix this issue via a service
release rather than a patch.  Service releases and service packs
(which are two terms for the same thing) are the best way to deliver
fixes of all types, including security fixes.  Patches are tactical
measures that provide customers with a means of protecting themselves
between service releases.  Service releases are better than patches
for several reasons:
*       Service releases are quality-driven.  That is, the first priority
is delivering a well-tested, high-quality release.  If meeting these
goals means that we have to slip our delivery schedule, we'll do it.
In contrast, patches are schedule-driven -- that is, our first
priority is delivering a fix quickly, and we test as thoroughly as
possible within the time constraints.
*       Service releases are comprehensive.  A service release includes
fixes for a large number of issues, where a patch fixes only one
issue. Every service release is a "roll up" that incorporates all of
the patches that have been released since the previous service
release.
*       Service releases are more broadly adopted.  The uptake rates for
service releases and service packs are at least an order of magnitude
higher than for patches.

In the case of the vulnerability at issue here, it was appropriate to
fix it via a service release.  We learned of the vulnerability just
as FrontPage 2000 SR1.2 was entering its final test cycle, so we had
an opportunity to have the best of both worlds -- rapid response and
delivery through a service release.   It did take slightly longer to
deliver the fix via SR1.2 than it would have taken to deliver a
patch, but it is important to keep the scope of the vulnerability in
mind.  It
would allow a malicious user to prevent a web author from remotely
updating the content on his site, but it would not prevent him from
doing so locally, nor would it prevent the site from serving content
to visitors.  We judged that the benefits of delivering the fix via
SR1.2 outweighed the short delay.

Second, we have not tried to "hide" FrontPage 2000 SR1.2.  If we
intended to hide the service release, we wouldn't have gone to the
trouble of developing it at all.  The new service release is hosted
on the very same web page that has housed previous FrontPage service
releases.  We certainly agree that we could do a better job of
publicizing the release, though, and we will add information to the
security web page to do this.

Finally, the allegation that we somehow misled the customer who
reported this issue to us is absolutely untrue.  On the contrary, we
kept in close contact with him throughout the investigation, and he
agreed with every decision we made, including the decision to address
the issue via a service release rather than a patch.  In his mails to
us, he clearly
understood that this meant he wouldn't see his name in lights.  We
are, to say the least, surprised to read the version of events
described in his note.

In sum, Microsoft remains committed to protecting its customers.
Since the start of the year, the Microsoft Security Response Center
has received over 5000 notes from our customers, and we have answered
every one.  We have conducted over 400 detailed technical
investigations of reported security vulnerabilities, leading to the
delivery of 61 security bulletins and patches.  We will stack our
response process up against any other vendor's.  Regards,

Scott Culp
Security Program Manager
Microsoft Security Response Center
secure () microsoft com

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQEVAwUBOabU2I0ZSRQxA/UrAQFB3wf/RKAX5pggF2Urdms/gHjEc7LLx59lr6PE
hKcSCA/08YH20vMLq7NA3mvygJLZVWRO+MF5bFtp6E3UvF4Q6XqQUaxZHbKP2DZg
4y5qhMkUZOVwGVSlsxbVsy0OmOOUc3d2xgQGuigIIVla5vdZHNSLwUJs7KMR+1Fr
g3VpQZ0ajvPSaZDvvgLInYnrTxpl3RaIirkqc/uV73nM2BcBOwTk3UUOiAGSlG5u
JyKl6K0eUPQLFlqkZWAO1XPlhKfAF9hW2klNSAs2YLCXdF4w5cqbIFB9q+TWOT7R
0TixHM3Hx4h5h532gGY9G1ePffyUMnYOC3WkUPpwNpNLQVDpgJpweQ==
=hkVH
-----END PGP SIGNATURE-----