Launching .EXEs from a web page
-
Here at the Microsoft PDC, I noticed something in a demo which surprised me a little: If, from a web page, the user downloads and runs a .EXE from a web site, and that .EXE is a .NET managed executable, the user will NOT get a security warning. The .NET program will be "sandboxed" (gee, I thought MS didn't like sandboxing :-)), so the user is safe. I like that. I tried it myself -- wrote a .NET exe, which was NOT signed with Authenticode, and then tried downloading it via a web page that looked like this: Click <a href="foo.exe">here</a> It worked as I had seen in the demo: foo.exe downloads and runs, with no security warning, but as soon as foo.exe tries to do something "bad," e.g. open a file, a security exception is thrown. Cool. And a bit better than the Java way, because Java applets download inside the IE frame, but .NET exes can open Windows and stuff -- they look like regular client apps. My questions are: (1) How does this work? My guess is, IE downloads the EXE, looks at its header and sees that the bit is set indicating it's a .NET EXE, so it knows that it doesn't need to put up a security warning since the CLR will sandbox the program. (2) Is this a feature of IE6? If I downloaded the EXE in an earlier version of IE, would it work the old way (put up a security warning based on the Authenticode stamp on the EXE)? Mike Morearty mike@morearty.com http://www.morearty.com - handy code and programs
-
Here at the Microsoft PDC, I noticed something in a demo which surprised me a little: If, from a web page, the user downloads and runs a .EXE from a web site, and that .EXE is a .NET managed executable, the user will NOT get a security warning. The .NET program will be "sandboxed" (gee, I thought MS didn't like sandboxing :-)), so the user is safe. I like that. I tried it myself -- wrote a .NET exe, which was NOT signed with Authenticode, and then tried downloading it via a web page that looked like this: Click <a href="foo.exe">here</a> It worked as I had seen in the demo: foo.exe downloads and runs, with no security warning, but as soon as foo.exe tries to do something "bad," e.g. open a file, a security exception is thrown. Cool. And a bit better than the Java way, because Java applets download inside the IE frame, but .NET exes can open Windows and stuff -- they look like regular client apps. My questions are: (1) How does this work? My guess is, IE downloads the EXE, looks at its header and sees that the bit is set indicating it's a .NET EXE, so it knows that it doesn't need to put up a security warning since the CLR will sandbox the program. (2) Is this a feature of IE6? If I downloaded the EXE in an earlier version of IE, would it work the old way (put up a security warning based on the Authenticode stamp on the EXE)? Mike Morearty mike@morearty.com http://www.morearty.com - handy code and programs
Mike, In your VS.NET Release Candidate that you received at PDC, check out the help for an article called "Security in .NET: Enforce Code Access Rights with the Common Language Runtime". It talks a little about the SAFER initiative and code verification. Cheers! Colin
-
Here at the Microsoft PDC, I noticed something in a demo which surprised me a little: If, from a web page, the user downloads and runs a .EXE from a web site, and that .EXE is a .NET managed executable, the user will NOT get a security warning. The .NET program will be "sandboxed" (gee, I thought MS didn't like sandboxing :-)), so the user is safe. I like that. I tried it myself -- wrote a .NET exe, which was NOT signed with Authenticode, and then tried downloading it via a web page that looked like this: Click <a href="foo.exe">here</a> It worked as I had seen in the demo: foo.exe downloads and runs, with no security warning, but as soon as foo.exe tries to do something "bad," e.g. open a file, a security exception is thrown. Cool. And a bit better than the Java way, because Java applets download inside the IE frame, but .NET exes can open Windows and stuff -- they look like regular client apps. My questions are: (1) How does this work? My guess is, IE downloads the EXE, looks at its header and sees that the bit is set indicating it's a .NET EXE, so it knows that it doesn't need to put up a security warning since the CLR will sandbox the program. (2) Is this a feature of IE6? If I downloaded the EXE in an earlier version of IE, would it work the old way (put up a security warning based on the Authenticode stamp on the EXE)? Mike Morearty mike@morearty.com http://www.morearty.com - handy code and programs
.NET exes can open Windows and stuff -- they look like regular client apps. That is very very scary. Please tell me there's at least a "Warning: applet window" message. --Mike-- http://home.inreach.com/mdunn/ This posting is provided "as was" with no warranties, guarantees, lotteries, or any of those little bags of peanuts you get on planes. You assume all risk for crossing the street without holding mommy's hand. © 2001 Mike's Classy Software. Member FDIC. If rash develops, discontinue use. :love: your :bob: with :vegemite: and :beer:
-
.NET exes can open Windows and stuff -- they look like regular client apps. That is very very scary. Please tell me there's at least a "Warning: applet window" message. --Mike-- http://home.inreach.com/mdunn/ This posting is provided "as was" with no warranties, guarantees, lotteries, or any of those little bags of peanuts you get on planes. You assume all risk for crossing the street without holding mommy's hand. © 2001 Mike's Classy Software. Member FDIC. If rash develops, discontinue use. :love: your :bob: with :vegemite: and :beer:
Yes, there is such a message. Over the app's window, a little "speech balloon" comes up, which says:
.NET Security Information
This application is running in a partially trusted context.
Some functionality in the application may be disabled due to
security restrictions.This message comes up on each top-level window the program creates. I haven't yet delved into exactly what such a program is and is not allowed to do, but basically it's similar to the sandbox model that Java has. E.g. they can't touch the local file system (except for a small scratch area called IsolatedStorage). Mike Morearty mike@morearty.com http://www.morearty.com