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/
AV companies rarely name the virus by the name the virus author wants. This is done so that there is, hopefully, less incentive to write a virus.
Hogsback
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
Like the other worms (code red, nimda) that didn't infect NT? Security is more than running junk with user permissions. While users of NT might not be as prone to spread it, the virus itself might use other means (like the aforesaid worms) to spread itself. Who knows what in the hell is going to happen once there is a server version of Windows XP (gag).
"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.
Virii are money making entities in themselves and I'm tired of seeing companies encourging the creation of Virii. I don't remember when, but I do remember a scandal typeness on the net a LONG while ago about McAffee going out to software writers to see if they would be interested in writing virii to test out their detector ... then they just happen to get released out into the wild.
The other thing that I see wrong with Virii and Worms is that it kills the IT world. IT department heads are forced to clean up after end user mistakes when they could be developing. And when a worm like nimbda is released my bandwidth was cut by a third almost.
It's rediculous ... and I'm really sick of it ... virii writers are the lowest of lows when it comes to software. A monkey can code, but a true hacker can realize when his code could harm something or someone.
Ignore the "p2p is theft" trolls, they're just uninformed
.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
article here.
Buy a Nintendo DS Lite
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
More details also at cNet News. Its been there for a couple of hours, and I thought about posting it but was too lazy.
Mono is not .NET
.NET is a platform and an archetecture.
Mono is an implementaion of C# that is it.
I am the Alpha and the Omega-3
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.
So, taking the hypothetical stance that one would need to eventually get registered to use
The whole world isn't online.
- Don't pay your bills online. Mail them like many people do.
- Don't shop online. Sometimes it is very convenient to do this, so in those cases look up the item online, and then call in the order over the phone using your credit card, or mail the vendor a check. If the online vendor you are looking at doesn't support this, choose another.
As far as being a developer, there isn't much you can do, but you can minimize the risks to yourself by not usingMark
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
-----Original Message----- .NET Created Virus
.NET Framework (MSIL PE) files. So claims that this is the "first .NET virus" are basically inaccurate.
.exe application to their system and run it locally -- it cannot spread through Internet Explorer or through Outlook (which blocks potentially dangerous attachments).
.exe on the command line).
.NET managed code also detect this virus and will not run it. In other words, users who are taking standard security precautions (like running the current operating system and not downloading and running code they don't know about) won't ever be infected.
From: Scott Guthrie [mailto:scottgu@microsoft.com]
Sent: Thursday, January 10, 2002 3:59 PM
To: aspngcommunity
Subject: [aspngcommunity] RE: First
Just to be clear -- this was not a ".NET virus."
It's a standard Windows virus written largely in unmanaged assembler that happens to locate and modify
To be infected, a user would have to download an infected
In fact, because of the security enhancements in Windows XP it cannot even trigger and spread if you are running Windows XP no matter how hard you try (even if you download and run the
In addition, for downloaded code on all platforms, additional safeguards for
Hope this helps explain it some more,
Scott
P.S. Ironically, the virus author even talks about how hard it would be to write a real ".NET virus" -- "How easy it sounded, so hard to code it was. C#, such like Java have VERY STRICT type checking. And I figured out that there's NO easy way how to work with stringz - once a string is defined, you CAN'T change it - and I needed to do that, becoz it was very important for viral functionality."
Virus writers are terrorists.
"Unlike acts of terrorism, acts of sabotage do not have a primary objective of causing casualties". They're not terrorists but mere saboteurs.
Will I retire or break 10K?
I'm impressed with the number of slashdot readers who, well, are incapable of reading. Hm, actually, no I'm not.
.NET virus. It does not infect a .NET executable, it infects a PE executable. It would be a trivial matter to overwrite the entrypoint of a PE with a jump to the end of the file, tack on your own crap, and jump back. This virus does not target .NET, as it does not infect the IL, or utilize any of the framework. This is no different than the COM trojans of the DOS days, and no more a virus than a shell script designed to call rm, to which Linux is incredibly succeptable. It would be very trivial to pull this off with any binary executable format, all you would need to know is a little machine code for the intended platform, and where the entrypoint lies.
.NET, _CorExeMain is only an intermediary bootstrap for older OSes. It's interesting to note that Windows XP could not be affected by this because Windows XP does not launch it as a PE executable, rather immediately begins to compile and execute the .NET entrypoint instead.
.NET is also built from the ground up to employ a deep security model, where each function to each class is scrutinized by a user or administration editable regime of standards based on where the code lies, who is running it, what day of the week it is, etc. .NET installation in Windows creates two control panel applets for the purpose of configuring exactly what may run. For example, I can execute a program containing pointers that has been saved to my local machine if I have the appropriate permissions, but I would not be able to run that same program if the assembly resided on a website, or an SMB share.
This is not a
Of course, if you read further in the explanation, and know anything about
.NET itself is not immune to virii. To the contrary, the platform was built from the ground up to satisfy both internal compilation needs (System.Reflection) and debugging (System.Diagnostics.) However,
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.