Microsoft previews Avalon graphics engine

TalkBack 27 of 66:: Next »; « Previous

Thread View
Flat View

Details.: From Microsoft:

"If you run the W32.Donut virus, the virus attempts to infect all .exe files that contain .NET code in the folder that contains the virus and up to 20 parent folders."

True, the stub is the attack vector. But as far as I can tell, currently if you want to do .NET on Windows, you've gotta do the stubs. I guess running .NET natively on Windows is for Longhorn, right? I can't come across anything on Microsoft's site that says I can run .NET code natively yet on my Win2K boxes. So, effectively, .NET should currently be considered unsafe. I'm really more concerned about the exploits which haven't seen the light yet than I am about w32.donut, which really just showed other malware writers out there that a new attack vector is ripe for the exploiting.

And yes, Java is inherently unsafe as well (I've recently seen some Java malware, although the damage was minimal and easily fixed). As the security folks keep telling us (and telling us and telling us and telling us), any technology which allows you to download and run executables from unknown systems is a big security risk. A quote from an O'Rielly publication on .NET/Java security: "Starting with the initial releases of Java, there have been multiple verification problems reported, where invalid/malicious bytecode could sneak beyond the verifier. At the moment, there are no new reports about verification bugs, and Java 2 documentation does not list verification switches, which implies that the verification is always run in full."

Later, we are told:

"The Java VM is responsible for loading, linking, verifying, and executing Java classes. In the HotSpot JVM, Java classes are always interpreted first, and then only certain, most frequently used sections of code are compiled and optimized. Thus, the level of security available with interpreted execution is preserved."

Yet, a few paragraphs earlier, when discussing .NET:

"In .NET, CLR always executes natively compiled code; it never interprets it. Before IL is compiled to native code, it is subjected to validation and verification steps."

Which would seem to tell me that the .NET execution method is more problematic from a security standpoint. Furthermore:

"At the same time, developers are urged to develop their applications targeting the Internet permission set, as an application sandbox with low trust and a "safe" permission set (preliminarily named Secure Execution Environment, or SEE) will be introduced in the Longhorn Windows OS (due in 2005) for executing applications. However, according to the preliminary MSDN Longhorn documentation, Longhorn's security system, as it is presently designed, does not attempt to verify trust of local .exe files that do not have deployment manifests, and simply grants them the same FullTrust as before. Hopefully, this policy will change by the release time, because, with its present design, this setup presents an unfortunate way to bypass the system checks in local scenario."

Hmmm...talk like this makes me very nervous about the current state of .NET. Granted, this article is over a year old.; Posted by: Yen_z Posted on: 01/17/05 You are currently: a Guest | Members login | Terms of Use