Browsers special handling of EXE files
Mike Smith
downloads it, uses it once and throws it away. The win32 version downloads
and works perfectly but the .NET version does not. Oddly enough, the .NET
version works perfectly using non-Microsoft browsers, it displays the "Open
or Save to Disk" window whereas IE browsers appears to be trying to run the
program over the net!
Can anyone point me to where this action is explained? I want the browser
to download it, not execute it.
As a test I tried creating a simple "Hello World" app called "Hello.exe" in
VJ#. I put it on the remote server (non-MS) and tried to access it with IE.
It goes away for about a minute and finally comes back with the following
dialog box:
IEExec.exe - Common Language Runtime Debugging Services
Application has generated an exception that could not be handled.
Process id=0xa8(168), Thread id=0x5e4(1508)
Click OK to terminate the application.
Click CANCEL to debug the application.
The error log on the server reports the following errors:
File does not exist: /public_html/404.shtml
File does not exist: /public_html/bin/Hello/Hello.EXE
File does not exist: /public_html/404.shtml
File does not exist: /public_html/bin/Hello.EXE
File does not exist: /public_html/404.shtml
File does not exist: /public_html/Hello/Hello.EXE
File does not exist: /public_html/404.shtml
File does not exist: /public_html/Hello.EXE
File does not exist: /public_html/404.shtml
File does not exist: /public_html/bin/Hello/Hello.DLL
File does not exist: /public_html/404.shtml
File does not exist: /public_html/bin/Hello.DLL
File does not exist: /public_html/404.shtml
File does not exist: /public_html/Hello/Hello.DLL
File does not exist: /public_html/404.shtml
File does not exist: /public_html/Hello.DLL
File does not exist: /public_html/404.shtml
File does not exist: /public_html/Hello.exe.config
File does not exist: /public_html/404.shtml
File does not exist: /public_html/Hello.exe.config
File does not exist: /public_html/404.shtml
File does not exist: /public_html/favicon.ico
This entire stream of errors was the result of one access attempt. It
appears the IE browser is doing it's best to find something to execute.
This is a simple executable created using the VJ# wizard selecting "Windows
Application" as the project type. Should IE be trying to run applications
created as "Windows Applications" over the net?
Mike
Lars-Inge Tønnessen
This is part of the security model in .net. You can't access all resources
and harming the computer on the client side.
You could try to change the MIME type for the exe file in the IIS config
panel for the file/directory. I don't know if this works, but give it a try.
Change from MIME application type to MIME data type.
If not, you cold zip it, or make an install shield/project.
--
Regards,
Lars-Inge Tonnessen
http://emailme.larsinge.com
http://www.larsinge.com
Mike Smith
> and harming the computer on the client side.
There are many products Microsoft ships as one setup.exe file which IE
downloads perfectly well, the .NET and J# redistributables among them. Are
you telling Visual Studio .NET is not capable of creating this kind of
executable? How does Microsoft create them, using old versions of Visual
Studio?
Mike
Mike Smith
> panel for the file/directory. I don't know if this works, but give it a
try.
> Change from MIME application type to MIME data type.
It's not the server handling of MIME types, the problem is in IE. Another
.exe file in the same directory created under an old Visual Studio downloads
fine. It is a non IIS server anyway.
Mike
Lars-Inge Tønnessen
> downloads perfectly well,
They are install shields, not .net executables.
> How does Microsoft create them, using old versions of Visual
> Studio?
They make install projects. As far as I know, they are not .net projects,
but install scripts and normal win32 executables (like normal C/C++).
When you open a .net executable in IE, it will run inside IEs internet
security mode. This is like Java Applets.
--
Regards,
Lars-Inge Tonnessen
http://emailme.larsinge.com
http://www.larsinge.com
Lars-Inge Tønnessen
Your old executable is a Win32 application, not a .net application.
Other browsers can't host .net applications, that is why they just download
them. IE can host .net applications with extra internet security, just like
Java Applets. If you run .net applications inside IE, they can't harm your
computer.
If you want to distribute .net applications over the web to run outside the
IE, make install shields or zip them. Or tell your users to push the "Save
As" button before the open them.
Mike Smith
wonder how feasible would it be to actually let it run as a network
application with zero permissions. That might be a feature since I could
let the user experience the application in "demo mode" where they cannot
save to disk, etc.
So this is what the user experiences: They click on the "download" link and
get a dialog box that says "Click the Demo button to preview <app name>. To
download a fully functional version of <app name> click Cancel and
right-click "download", then choose "Save Target As..." from the menu. My
app is actually running over the net at this point to show this dialog box,
and then it jumps into main() if the user presses "Demo" where it runs with
no permissions. If they choose to right-click to download then the
application is saved to disk. When launched it detects that it is now
running with full permission and enables "Save as..." and other permission
related features.
Has anyone tried this with a J# based applicaton? Most of the focus here
has been on using the J# Browser control but why not run it as a full
application? In my case the Java code is set up to run as an applet with no
permissions or as a Java application with full permissions so that aspect of
it is already handled.
Mike
Michel Gallant
a PE representing a .NET executable, and if you don't have the necessary
permissions represented by your CLR permissions, and if you haven't
configured your local .net security to throw the debugger, than you
will see absolutely nothing by default (except for maybe a bit of disk churn etc..)
I reported this earlier. I think this default behaviour is a bit un-nerving
to the end user, particularly with all the recent virus propogation activity.
On the other hand, anyone clicking on a .exe download deserves what
they get ... analogous to clicking any email attachments.
After all, in a heterogeneous environment like today, you must never do
such a thing (click on dnld exe from browser) even if you really expect
your browser download behaviour to protect you. There is no way to
tell before clicking an .exe link if it is a native .exe or a .NET exe.
- Mitch Gallant
MVP Security
JavaScience Consulting
http://pages.istar.ca/~neutron
"Mike Smith" <mikes...@yahoo.com> wrote in message news:%23mbsXld...@TK2MSFTNGP10.phx.gbl...
Mike Smith
newsgroup an got this interesting reply:
> How feasible would it be to set it up to actually
> run over the net with zero permissions but in a sort of demo mode
I've been where you are and have posted the very same questions that
you're posting now and can tell you that the path you're on leads to a dead
end. Here's the basic scoop on this:
Around the time that .NET was released, Microsoft started hyping
something called zero-touch deployment. The idea is that you place a .NET
executable on a web server (be it IIS, Apache, or whatever). Internet
Explorer would then download the EXE. At some point IE would look at the
executable and determine if it were a .NET exe. If so, it would try to run
it, automatically downloading all of your custom assemblies on which your
EXE depends. The idea was cool, but it had problems:
First of all, it was slow. Not only would your app hang while the .NET
runtime tried to download all of your other assemblies, but as posted in the
last message, .NET likes to "probe" for culture specific assemblies. Aside
from the slowness, with .NET 1.0, the downloaded assembly didn't have access
to do much. Pretty much anything your app tried to do, even doing seemingly
innocuous things like opening a new form, would lead to some kind of warning
that the user would have to read. Other operations would just throw
exceptions. If that weren't enough, your app was loaded into the IEExec
process which means that if you're application made use of certain legacy
COM components (i.e. the web browser control), you'd end up with all kinds
of weird threading exceptions if you didn't configure everything just right.
Around the time .NET 1.1 came out, Microsoft was getting some bad press
for virus vulnerabilities. So, to score some press points, they announced
that they were making .NET 1.1 "more secure"... part of this initiative
included tightening the security in such a way that .NET exes located on a
web server wouldn't even *execute.* So much for zero-touch deployment over
the Internet.
With the next release of .NET, Microsoft will reverse course again,
allowing these remote EXEs to execute and with more permissions than 1.0.
Exactly what those permissions are I'm not sure. I don't think it's been
announced. But as you can see, the damage is already done. You as the
developer have no idea whether your users will be using 1.0, 1.1, or this
new Whidbey version of .NET so this idea of putting an EXE on a web server
and have users run it just a no good. This idea is only practical in certain
types of Intranet scenarios... and from what I can tell, there's no way to
force the IE user to get a the "Save As.." dialog without forcing him
through the context menu.
If you absolutely refuse to use an MSI file for deployment, you're going
to have to find a clever way to get the user to run your executable with
FullTrust. One thing I've done in the past is put some instructions on the
site telling users to right-click the exe link, save it to their harddisk,
and run it. That way the EXE runs with full permissions. As part of the
startup code, you can modify the security settings on the user's computer so
that it grants FullTrust to all other EXEs originating from your domain. I
don't really recommend this though. Then you're assuming that the user has
administrative access to his own machine, etc. There also might be a
backdoor through ActiveX [browser-based unmanaged code] that would allow you
to modify the user's security settings, but I haven't tried this.
I think for now you're stuck using an MSI file. :(
--
Sincerely,
David Sworder
http://www.CodeFanatic.com