Slashdot Mirror
First (proof-of-concept) .NET virus
Juergen Kreileder writes "Symantec
says they've received W32.Donut, the first .NET virus: 'This virus targets EXE files that were created for the Microsoft .NET framework. W32.Donut is a concept virus. It does not have any significant chance to become wide spread. However it shows that virus writers are paying close attention to the new .NET architecture and attempting to learn how to exploit it before the Framework will be available on most systems.'"
More details also at The Register.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
AV companies have been aware of the possibility for a while. It was discussed at the 2001 Virus Bulliten Conference. Here are the abstracts from two papers: MSIL For The .NET Framework: The Next Battleground? amd The Effects of Microsoft .NET on Malicious Threats.
http://benny29a.kgb.cz/
There was a interview with him for Softwarove Noviny (czech magazine), its translation is at:
http://benny29a.kgb.cz/articles/iigi.txt
-- Wanna textmode user interface for ruby? http://freshmeat.net/projects/jttui/
The day i'm FORCED to use a passport, to do business with a NON-MICROSOFT company, is the day I stop doing business with that company.
people have been writing .NET apps for well over a year. There are web sites (including some of MSDN, for instance), running on .NET .aspx pages. You can by books on .NET for pete's sake.
DO NOT DISTURB THE SE
Set a Cron Job that does a backup every hour or two. Have the file time stamped and rotate out the oldest backups in a way that you hard drive space allows.
Full backup every few days, and incrementals throughout the day. Bit of thrashing, but it will protect you from most problems.
"Live Free or Die." Don't like it? Then keep out of the USA
"Normally .NET files do not have any platform dependent code, but a small 5 byte stub. This stub executes the mscoree.dll _CorExeMain() function and thus the .NET MISL (intermediate language) gets control if the .NET framework is installed."
"The virus infects .NET executables by attacking the 5 byte jump to the _CorExeMain() function. It replaces this jump, with another one to point into the last section of the executable, it overwrites its .reloc section with itself and nullifies the relocation directory."
Interesting. I predict we will be seeing many, many attacks on .NET somewhat similar to this, since Microsoft kept function pointers (which are unverifiable) in the mix. Good for the checkbox battles, but fatal for security.
.NET can't be released because .NET is not a product.
.NET are included in Windows XP
.NET implementations, only Win32 PE format executables. Therefore, it wouldn't work with .NET executables on another platform. It wouldn't even work on 64 bit windows.
.NET is a platform. There are many applications and services that make up the platform. Some parts of the platform have been/are being rolled out.
Passport/.NET my services is one
Visual Studio.NET has "gone gold" and will be shipping soon.
various bits of
.NET alerts are included in the latest MSN Messenger.
Yadda Yadda.
Anyway, I think calling this virus a ".NET virus" is mis-information. This virus is a Win32 virus. It doesn't work across all
When you say .NET, you seem to be referring to the .NET initiative, a company-wide push for XML web services. This is separate from the .NET framework, which is what the virus is about.
.NET framework is an executable platform, with an intermediate language runtime (much like Java bytecode). This is the platform the virus was found on. For compatibility, a 5 byte stub of native code is used to start the execution of MSIL code. The virus infects this stub. You could compare this to a 'java' virus that infected your JVM.
.NET initiative has its own problems. It seems like that's what you're thinking of - the issues with Passport, etc. That's a separate issue and it deserves a lot of evaluation before it's declared a safe platform for storing sensitive information.
The
In contrast, the
Firstly, I'm not a MS fan, I hate to defend them, but I feel compelled to correct gross misconceptions when I see them...
.NET is pretty much a Java clone that supports many languages. That's it...
.NET is capable of an applet like technology, restricting the program to not damage the system)
.NET programmers aren't forced to use Passport just like Java programmers aren't forced to use Jxta. So, I don't see how they're going to force you to use Passport, let alone charge for it.
1.
.NET is a virtual machine. It's as dangerous a Java or any other programming platform. (Yes,
2.
3. Microsoft isn't looking to put everything on the Server. This would jeopardize thier client monopoly, and plus it makes absolutely no sense.
If Microsoft wants to insure a steady revenue stream, they have two ways of doing this.
A. Change the license to require companies to renew thier license after x years.
B. Add new features to the next version causing customers to salivate and upgrade.
They're pretty much doing a good job with B, but if they happen to fail, they can always revert to A.
If you would like me to clarify on any further points, feel free to respond.
"Communism is like having one [local] phone company " - Lenny Bruce
You're not required to use Passport for .NET services. MS just makes it real easy to do so.
This virus takes advantage of the fact that the PE for CLR executable assemblies includes a small stub to bootstrap itself into older platforms that do not recognize and or honor .NET PEs natively (i.e. older versions of Windows).
.NET or the CLR, but rather a MS specific "optimization" that saves them from having to retrofit CLR PE recognition into their older platforms when the CLR is RTM. For more information, check out this thread[1] on the Developmentor .NET mailing list.
0 107B&L=DOTNET&D=0&P=47726
This is really not part of
The important thing to point out is that this hack does not foil CLR security. It's foiling standard Win32 security and only because of the afforementioned "optimization".
Later,
Drew
[1] http://discuss.develop.com/archives/wa.exe?A2=ind
http://www.cnn.com/TECH/computing/9808/19/javaviru s.idg/ and I'm sure it's not the only one...
-- these are only opinions and they might not be mine.
Comment removed based on user account deletion
I'm unsure of the "troll factor" in this post, but I'm biting...
In past experience, I find it's typically best to consider stability issues to be the fault of the underlying hardware.
I've many times seen Linux perform flawlessly on motherboards that Windows was horribly unstable on. The reverse I've never seen (A Windows system stable on H/W that Linux was unstable on)
That's not to say that there's some misconfiguration or something in your setup, but I've just never seen it. And note that not all hardware works with Linux (duh!) but we're talking stability here, not compatability.
So, without any further ado:
YOU HAVE BAD HARDWARE, DUDE!
I have no problem with your religion until you decide it's reason to deprive others of the truth.