Re: BUG with RES/SCRIPT/XP-SP2
- From: Joseph M. Newcomer <newcomer@xxxxxxxxxxxx>
- Date: Wed, 31 Jan 2007 12:43:07 -0500
Perhaps the reason you got no responses is that most of us have a tendency to run
screaming as fast as possible from things like DHTML. (Just a guess, but those who
haven;t fled are probably far to busy trying to get their programs to work to spend time
in this newsgroup...).
I consider JavaScript (known to security people as JavaVirus) as one of the Really Top
Contenders For The Worst Idea Ever Promulgated On The Internet. So I disable it, solidly.
And three levels of firewall strip it out of incoming Web pages.
Local Zone Security sounds like a truly wonderful idea, making it as difficult as possible
to have a bad script cause damage to my machine.
Key here is it is not Microsoft's choice to manage what is going on; it is the end user's
choice, and it should be. My complaint about these security features is that they do not
go far enough. The fact that Microsoft's previous approach to security was so lax as to
be laughable, but allowed all kinds of crap to execute, should not be taken as a
justification for complaining when the security technologies are dragged kicking and
screaming into something that was inadequate a decade ago but is certainly an improvement
over the nonexistent protection that preceded it. If it breaks your code, well, that's
just because your code was predicated on a hopelessly inadequate security model. If your
code breaks under enhanced security, it is the END USER'S responsibility to configure
their security to allow your code to run. Those of us who are truly concerned with
security can only applaud Microsoft's efforts to lock down the otherwise uncontrolled
behavior previously permitted. Your characterization
This is the precursor to letting Microsoft control not only who
can do what to legacy files and resources, but which legacy programs can do
what to legacy files and resources.
misses the ACTUAL purpose, which is CORRECTLY stated as
"This is the precusor for alowing the end user to finally control who can do what to
legacy files and resources, and which legacy programs can do what to legacy files and
resources, a feature still not correctly and fully implemented, but essential for proper
site security. By placing this control, at long last, in the hands of the end user,
instead of the script author or the browser, a significant advance has been made in
computer security. We can only hope that more control and more restrictive control will
be possible in future releases. Furthermore, it follows the new Microsoft policy (again,
long overdue) that security is enabled "out of the box" and therefore, as installed, the
system has maximal security enabled."
If your code is vulnerable to increased security, that's just how life is. In case you
have been living in a cave without Internet connectivity for the last decade, I should
point out to you that what this broke is one of the most serious virus vectors that
currently exists. The kind of script you just showed is the reason I have disabled ALL
scripting execution and have three levels of firewalls that remove scripts from Web pages.
And why should I trust a script from any site, especially the local zone, where various
kinds of spoofing can create bogus scripts which can then be executed under the local
zone.
I certainly agree that the messages are misleading, but that is because there is very
little adult supervision about the form and content of far too many error messages. VS.NET
2003 has a tendency to fail a compilation with a message "Invalid parameter", for example.
The "impossible" errors which security makes possible almost always give misleading or
incorrect messages, for example, if WinDbg has a symbol table open, the linker gives an
error that says the disk is full, instead of one that suggests the symbol table might be
in use. They never seem to test the error paths to see if the errors reported are
meaningful, and in this complaint you are fully justified. But you are not entitled to
complain that long-overdue security enhancements represent an attempt by Microsoft to
control the world. These changes were made based on end-user demands.
joe
On Tue, 30 Jan 2007 12:33:02 -0800, ATS <ATS@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
First off, I'm disappointed with MSDN support and Microsoft's XP/SP2.Joseph M. Newcomer [MVP]
The issue is that XP/SP2 introduced a new security feature which breaks
code. This security feature is called the "Local Machine Zone Lockdown". See
this URL for more information:
http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2brows.mspx#EKQBG
I'm disappointed that MSDN support, that I found this out painfully over the
past week since I started posting problems with the RES Protocol, SCRIPT
Tags, and the CDHtmlDialog class in this forum, and got no response. I also
posted this issue with the Internet Development Forum, as I could reproduce
the issue simply between a Java Script file stored in an EXE that used the
RES Protocol to be in turn used by a SCRIPT tag in a HTML file, and again,
got no response.
I'm disappointed with XP/SP2 in that the errors from Internet Explorer and
the CDHtmlDialog do not accurate reflect anything about "Local Machine Zone
Lockdown", and leave not only developers in the dark as what to do, but also
end users.
At any rate, this "Local Machine Zone Lockdown" basically makes it so that
all files on your local machine now have a kind of "Zone" security control
over them. Where the "Zone" is similar to "Internet", "Intranet", and
"Trusted Sites" zones as one would see in IE's Tools - Internet Options -
Security Tab. This is the precursor to letting Microsoft control not only who
can do what to legacy files and resources, but which legacy programs can do
what to legacy files and resources. It doesn't exactly work that way, but it
accomplishes it 100% for SCRIPT tags, and "active content" that would run
under Internet Explorer. This is my "layman's" explanation.
Before XP/SP2, one could use IE to bring up Java Script from the RES
Procotol from a local HTML file without any hinderance as such:
======= C:\SomeLocalPlacve\MyHtm.htm ======
<html>
<script language="javascript" src='res://MyApp.exe/"MY_SCRIPT"'>
</script>
Hello!
<script language="javascript">
window.onload = function()
{
RunMyFunc();
}
</script>
</html>
======================
In turn, the MY_SCRIPT would come from a local EXE called MyApp.exe who used
the RES protocol to expose the script as such:
======Java Script include in a local EXE called
C:\SomeLocalPlace\MyApp.exe=========
"MY_SCRIPT" HTML ".\\res\\MY_SCRIPT.js"
===============
And finally, the script in the actual TEXT file for the Java Script would be
somethign like this:
=======MY_SCRIPT.js========
function RunMyFun()
{
alert("Hello World!");
}
===============
This would work 100% fine on XP before SP2. After SP2, Internet Explorer 7,
would give a run time error on the RunMYFun, saying object does not exist. If
this HTML was launched from a CDHtmlDialog based class, it would give an
error saying invalid character line 2.
Now, here is the funny this, which that link explains. The IWebBrowser
control and HTA files are not affected by this "Local Machine Zone Lockdown".
And sure enough, the same code would work, if MyHtm.htm was renamed MyHta.hta
and setupo internally to be a TRUE-HTA file. And likewise, if the IWebBrowser
control was used instead of CDHtmlDialog, it also would work, on a XP/SP2.
Because these errors are so misleading, one would never deduce that the true
culprit was "Local Machine Zone Lockdown". And that is a Microsoft/XP/SP2
issue. But worse, and in my opinion, the CDHtmlDialog should not have been
subject to this issue, or at the least, should have its documentation changed
to imply that what ever security one's Internet Explorer is running on, is
how CDHtmlDialog will behave. I'd even dare say, that the CDHtmlDialog should
either not be subject to IE's security, and/or default it to use the
IWebBrowser without being subject to the security, and give an option for one
to go out of their way to set it up.
At any rate, the link above mentions work arounds, and even suggest if one's
application depends on not being hindered by the "Local Machine Zone
Lockdown", to switch it to an HTA, use the IWebBrowser, "Insert a mark of the
web" , or add one's application to a regitry key. I also found that
supposedly in the IE Tools - Internet Options - Advanced - Security section
are 3 "Allow Active Content~~~" checkboxes to let one's PC allow SCRIPT Tags
to work.
The HTA and IWebBrowser I can testify work. Adding one's application to the
registry also works. The IE Tools - Internet Options - Advanced - Security
does not work, even after a reboot. And so far, I can not get the "Insert a
Mark of the Web" to work for CDHtmlDialog, and it appears to be the best
solution.
In conclusion, this whole concept of the "Local Machine Zone Lockdown"
should at the minimum, come with a GUI applciation to let administrators turn
it on or off, and remotely as well as locally, configure one's machine to
grant access to specific applications. And the error codes from IE should
properly reflect that SCRIPT Tags trying to use the RES Protocol are locked
down, and let one have the ability to override them.
Also, we need a working sample for the CDHtmlDialog class that uses 100%
successfully, the "Insert Mark of the Web" to let SCRIPT Tags use the RES
Protocol, as that I still can not get to work.
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.
- References:
- BUG with RES/SCRIPT/XP-SP2
- From: ATS
- BUG with RES/SCRIPT/XP-SP2
- Prev by Date: Re: Sibling Window KillFocus Issue (MFC)
- Next by Date: Re: Drawing Bitmap Over the CHtmlView
- Previous by thread: BUG with RES/SCRIPT/XP-SP2
- Next by thread: Sibling Window KillFocus Issue (MFC)
- Index(es):
Relevant Pages
|
|
