URGENT: error in latest windows update cripples ability to use frames

In a nutshell, the update distributed this morning
makes it impossible to write to a child frame after
the domain has been modified. This is crippling a
number of internal tools we have that are based on
IE6.0. We have the domain name in both parent
and child set to "att.com" (when both come from
servers "xxx.att.com"), and when I try to execute
var d= content.document.open();d.write('xxx'),
where "content" is the name of the child frame,
I get a "permission denied" error. This was
not happening before the update.
This is a CRITICAL error in the update, and I need to
know (i) if there are plans to fix it and (ii) whether
anybody knows of a workaround.

Torgeir
Tue Aug 03 04:49:43 CDT 2004

Ken Lyons wrote:

> In a nutshell, the update distributed this morning
> makes it impossible to write to a child frame after
> the domain has been modified. This is crippling a
> number of internal tools we have that are based on
> IE6.0. We have the domain name in both parent
> and child set to "att.com" (when both come from
> servers "xxx.att.com"), and when I try to execute
> var d= content.document.open();d.write('xxx'),
> where "content" is the name of the child frame,
> I get a "permission denied" error. This was
> not happening before the update.
> This is a CRITICAL error in the update, and I need to
> know (i) if there are plans to fix it and (ii) whether
> anybody knows of a workaround.
Hi

From the section "Frequently asked questions (FAQ) related to
this security update" at
http://www.microsoft.com/technet/security/bulletin/MS04-025.mspx

<quote>
Does this update contain any other security changes?

Yes. This update contains two additional security changes. The update
refines a change made in Internet Explorer 6 Service Pack 1, which
prevents web pages in the Internet zone from navigating to the Local
Machine zone. This change was introduced to mitigate the effects of
potential new cross domain vulnerabilities. The changes introduced in
this update are further enhancements of the Internet Explorer 6
Service Pack 1 restrictions. The update also further enforces the
cross domain security model in Internet Explorer. This change is
further documented in Microsoft Knowledge Base Article 875345
</quote>

A security update is available that increases the enforcement of the
cross-domain security model that is used by Internet Explorer
http://support.microsoft.com/?kbid=875345


--
torgeir, Microsoft MVP Scripting and WMI, Porsgrunn Norway
Administration scripting examples and an ONLINE version of
the 1328 page Scripting Guide:
http://www.microsoft.com/technet/scriptcenter/default.mspx

S
Tue Aug 03 05:26:29 CDT 2004

Call Microsoft support - they provide free support for security bulletins
and potentially will be able to provide a fix/workaround.

--
Svyatoslav Pidgorny, MVP, MCSE
-= F1 is the key =-

"Ken Lyons" <kbl@research.att.com> wrote in message
news:9cdc01c478db$9dc04150$a301280a@phx.gbl...
> In a nutshell, the update distributed this morning
> makes it impossible to write to a child frame after
> the domain has been modified. This is crippling a
> number of internal tools we have that are based on
> IE6.0. We have the domain name in both parent
> and child set to "att.com" (when both come from
> servers "xxx.att.com"), and when I try to execute
> var d= content.document.open();d.write('xxx'),
> where "content" is the name of the child frame,
> I get a "permission denied" error. This was
> not happening before the update.
> This is a CRITICAL error in the update, and I need to
> know (i) if there are plans to fix it and (ii) whether
> anybody knows of a workaround.

ken
Tue Aug 03 05:53:48 CDT 2004


Torgeir wrote:
>Hi
>
> From the section "Frequently asked questions (FAQ)
related to
>this security update" at
>http://www.microsoft.com/technet/security/bulletin/MS04-
025.mspx
>
><quote>
>Does this update contain any other security changes?
>
>Yes. This update contains two additional security
changes. The update
>refines a change made in Internet Explorer 6 Service Pack
1, which
>prevents web pages in the Internet zone from navigating
to the Local
>Machine zone. This change was introduced to mitigate the
effects of
>potential new cross domain vulnerabilities. The changes
introduced in
>this update are further enhancements of the Internet
Explorer 6
>Service Pack 1 restrictions. The update also further
enforces the
>cross domain security model in Internet Explorer. This
change is
>further documented in Microsoft Knowledge Base Article
875345
></quote>
>
>A security update is available that increases the
enforcement of the
>cross-domain security model that is used by Internet
Explorer
>http://support.microsoft.com/?kbid=875345
>
>
>--
>torgeir, Microsoft MVP Scripting and WMI, Porsgrunn Norway
>Administration scripting examples and an ONLINE version of
>the 1328 page Scripting Guide:
>http://www.microsoft.com/technet/scriptcenter/default.mspx
>.


Thanks for your feedback, but I'd already read that. It
is supposed to be possible to set the domain of a page to
a superset of the server domain (i.e.
for "infolab.research.att.com" I should be able
to set it to "att.com", and then for "xxx.yyy.att.com" I
should be able to do likewise, and then the pages for
those two servers should be able to communicate. The
answer now is that they can "sometimes" communicate, and I
haven't yet figured out definitively what controls
it. I've been at it all night at this juncture.

By serious kluging, I've got our tool working, barely.
But I do NOT think this adheres to the accepted model for
page interaction.

If somebody can explain what they've actually done
to "strengthen" the domain communication algorithm, that
would be a big help. I didn't see any technical details
in the info posted anywhere on the microsoft site.