OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: Xato Advisory: FrontPage DOS Device DoS
From: sozni (sozniXATO.NET)
Date: Fri Aug 25 2000 - 19:41:18 CDT

I must clear some things up on this issue and more clearly state my
position. In writing my advisory I neglected to consider that anything
remotely anti-Microsoft will be amplified and over-analyzed. It seems that
when people read my advisory, all they saw was "blah blah blah bad Microsoft
blah blah." The advisory wasn't about Microsft bashing. It was about a
FrontPage DoS.

I fully agree with Microsoft's decision to roll the patch into a service
release. They did communicate this to me and I do agree that was the best
decision. I felt that it took longer than it should to get the service pack
completed, but being a software developer myself I know how that goes. In
other words, the turnaround time was not the best but we cannot totally
blame Microsoft for that. And since I didn't tell anyone about the hole and
they would only apply to specific situations, it was indeed were a low risk
issue.

The other issue was Microsoft misleading me. I sent the issue to Microsoft
and within 45 minutes I had received a reply. Six days later the issue was
confirmed and scheduled to be fixed with ver 1.2. There was no confusion or
misleading there I agree. They did a great job communicating with me. We
did not really need our company name "in lights" but a on the otherhand, we
were not mentioned at all. Even in the email I am responding to now he
referred to me as "the customer." That all wasn't cool, but really it
wasn't that big of a deal.

HERE IS THE MAIN ISSUE: There was no security advisory or knowledge base
associated with the fix. Sure, you could have gone to the FPSE page and
seen it, but we really do not have time to visit the download pages of every
MS product every day. That is why we rely on security bulletins and KB
articles. If someone went to Microsoft's Windows Update site, they would
get many of the security patches, but not all. One would then have to jump
over to the security bulletins page
(http://www.microsoft.com/technet/security/current.asp) to make sure they
got everything. If they have already installed SP1, they must then jump
over to the SP1 page to see what updates were included to know what is left
to download. Many system administrators base all their security updating on
the security bulletins page. If there are security issues in a MS product,
it should be addressed at the security bulletins site. So taking everything
together, not releasing an individual patch, the somewhat slow response
time, not giving credit, and mostly not issuing a security bulletin, one may
wonder if indeed Microsoft was trying to hide the issue. But I never
accused Microsoft of hiding the issue, only that "it was almost as if they
were hoping to sneak the issue by without all the bad press." I wasn't
accusing, I was wondering.

Summary: Microsoft made the appropriate choice in releasing the fix in the
service pack, it took too long but I doubt anyone was attacked in that time,
Microsoft did not acknowledge my company which is really not that big of a
deal, and finally Microsoft did not release a security bulletin or knowledge
base article to officially document the issue.

One other issue is that I have been accused of hyping the vulnerability
through the scenarios I provided. The answer is that yes, I did. I wanted
to do that. In the security world, hype gets things fixed. I have seen so
many critical vulnerabilies looked over and yet everyone in the world is now
protected from the ILOVEYOU virus. Hype gets things fixed so expect plenty
more where that came from.

And since I am on this whole subject of fixes I would like to announce an
upcoming xato service. We also know that it is difficult to keep on top of
all the Microsoft security issues and places to find the issues. So I would
like to announce our Patches and Updates database. It will be a timeline of
Microsoft security-related fixes that we will gather from the security
bulletins, knowledge bases, product update sites, download sites, and
wherever else we have to go to consolodate all this information. Our list
will be hyperlinked and cross-referenced where appropriate and we will
clearly designate which patches are included in which service packs. It
will all be divided by product so updating an IIS web server will be a
straight shot.

We are excited about this new service and we are actually referring to it
ourselves on a daily basis already. Look for that at www.xato.net the first
week in September.

We're not here to bash Microsoft, but we do have opinions. We all know that
security through obscurity is bad and if most people don't know about a
security issue, then most people will be vulnerable.

--the xato security team
"just faces in the crowd"

> ----- Original Message -----
> From: "Microsoft Security Response Center" <secureMICROSOFT.COM>
> To: <NTBUGTRAQLISTSERV.NTBUGTRAQ.COM>
> Sent: Friday, August 25, 2000 2:20 PM
> Subject: Re: Xato Advisory: FrontPage DOS Device DoS
>
>
> > -----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
> > securemicrosoft.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-----
> >
>
> --------------------------------------------------------------------------
> --
> > Delivery co-sponsored by VeriSign - The Internet Trust Company
> >
>
============================================================================
> > Upgrade your server security to 128-bit SSL encryption!
> >
> > Get VeriSign's FREE guide, "Securing Your Web Site for Business." You
will
> > learn everything you need to know about using 128-bit SSL to encrypt
your
> > e-commerce transactions for serious online security. Click here!
> > http://www.verisign.com/cgi-bin/go.cgi?a=n046607800016000
>
> --------------------------------------------------------------------------
> --
>

_____________________________________________________________________
** TO UNSUBSCRIBE, send the command "UNSUBSCRIBE win2ksecadvice"
** FOR A WEEKLY DIGEST, send the command "SET win2ksecadvice DIGEST"
SEND ALL COMMANDS TO: listservlistserv.ntsecurity.net