Virus Writers Look Ahead: Target 64-bit Windows 205
Ashcrow writes "A new virus, named W64.Shruggle.1318 by Symantec, is being 'tested' on AMD64 machines running 64-bit Windows. While it is not currently a danger to 64-bit Windows users, it does show that virus writers are looking toward the future. The exploitable software in questions is currently unreleased outside of beta. News.com has the full article."
Re:Interesting. (Score:5, Informative)
Since the memory is shifted around in bigger chuncks they will have to readadjust their code to pump more useless data to reach the memory address they want.
Many exploits / worms are made with specific memory locations in mind inorder to inject malicious code into them.
Re:It makes me wonder.... (Score:5, Informative)
oldschool (Score:5, Informative)
MS actually has some safeguards to prevent this thing, but it could use some minor tweaks to make it even better.
I propose that XP should require you to create a user account by default.
I propose that all software should be distributed as
The installer should prompt for the Admin password and install the
Any
This would prevent this type of virus. Coupled with XP64s support for NX, you'd actually have some semblance of security.
Re:Wow! Beta Viruses! (Score:3, Informative)
In other words these people have discovered the problem and given it some publicity by making a basicly useless virus. Their intent is not malicious
Its like the first virus for the
Re:Mod parent up (Score:2, Informative)
deserves at least a 0, funny. I mean, it's not that funny, but it's not a troll.
Re:Viruses (Score:4, Informative)
If you had any sense you'd notice that the "virus" in question was written by anti-virus people as a way to demonstrate a vulnerability of the w64 platform.
Do you find road car crash tests equally repugnant?
One could always hypothesise about how much we may or may not have developed programming code without having to spend money on prevention of these exploits.
As long as there are systems there will be exploits; be it computers, social security, passports, education - such is the way of the dragon.
Re:Interesting. (Score:5, Informative)
The techniques you describe are usually used by worms.
Re:oldschool (Score:1, Informative)
Re:conspiracy? (Score:5, Informative)
Re:oldschool (Score:2, Informative)
As long as there are executable entry points, malicious code will unfortunately always find a way to run.
The best we can do is limit the damage they can cause, and requiring users to run in user space has been proven to be a good defence. Granted, its not foolproof at the moment, but we have to build on what works.
Re:oldschool (Score:2, Informative)
Re:oldschool (Score:5, Informative)
> as
> work the same, double click the
> MS's Installer, but the MSI can't run arbitrary
> code.. it works like an RPM in this regard).
Sorry, doesn't work.
MSI files can embed DLL's, and these can be called during setup.
http://msdn.microsoft.com/library/en-us/m
Like the post-conf scripts in RPM and DEB
Re:Viruses (Score:3, Informative)
You can write your code as secure and neat and clean as you want, that doesn't protect you from a virus that injects some code into your compiled executable.
Operating systems may be part of the solution, but IIRC we are weary of proposed solutions (ie: TPC).
Re:It makes me wonder.... (Score:2, Informative)
The plural for computer virus is virus. Not viruses or virii.
So put the finger down and walk away.
3 reasons.... (Score:5, Informative)
AMD64 processors have NX extension [wikipedia.org].
Which [quoting wikipedia] : "stands for "no execute", a technology used in CPUs such as Sun's Sparc, Transmeta's Efficeon, and newer 64-bit x86 processors to prevent code from being executed on areas of memory flagged with an NX bit. This feature signifigantly lowers the probability of crackers exploiting buffer overflows and increases overall system security.".
This technology is only supported in newer OSes like Windows XP 64 and Windows XP SP2. It wasn't supported before (exemple in Windows XP SP1 or in Windows 2000).
So before all, a new AMD64-compatible virus, has to cope with new forms of protection.
2. Binary compatibility.
This is going to be more technical.
AMD64 (and Intel's clone "EMT64") are an extension over the standart 32bits inscruction set (IA-32).
So yes, AMD64 could run any 32bit code natively, unlike Itanium (which can only emulate it, with some hardware assistance).
BUT : A worm isn't your average spread-sheet application. It doesn't always run stand-alone.
In order to perform some operation, like infecting a computer without user attention, or gaining administrator privileges, or hacking some kernel stuff to help its replication, the worm must inject code inside OTHER application.
And even if the virus is 32bit, if it infects a 64-bits OS, odds are the applications in which the virus must inject code (e-mail client, kernel, etc...) will be 64bits application.
64bit bit binary code isn't necessary exactly the same as 32bit. Some binary code may be interpreted as different instruction depending on whether the memory segment (the application) was tagged as "16bit code", "32bit code" or "64bit code".
The processor can run all of this "dialects" natively in hardware, but may be expecting a different dialect because the application is tagged as 64bits and the injected code was intended for 32bits systems.
Denpending on the implementation (i don't know AMD64 well enough), when loading data into pointer register, the 32bit code running in 64bit application could either
- only override the lower 32 bits of the pointer, keeping intect the upper 32 bits.
i.e.: load 0x00001234 into a register whose value is 0x0012345601234567, will give you 0x0012345600001234) a different location than expected by the virus, and the machine would crash instead of being infected.
- read pas the lenght of the instruction in code memory.
simplified exemple
if code is "LOAD into pointer 0x00001234, then ADD 500 to register B".
the pointer will be loaded with garbage data "0x0001234, then ADD", and the processor will try to execute code form "500 to register B" which doesn't mean anything, and the machine would crash instead of being infected.
(some useful link about 64bit architecture) [wikipedia.org].
3. Memory model
Last but not least, memory organisation is different between a 32bits and a 64bits OS.
So worm should use different exploits to inject code into different places.
Re:Interesting. (Score:4, Informative)
In AMD64 (and some other architectures) pages have one more permission: they can be read, written AND executed.. and pages in the data section of a program (where you store all dynamic data, variables, arrays, etc. and buffer overflow exploits) have the NX (not execute) bit set by default.
Re:here's the grain of salt (Score:4, Informative)
This common accusation is a hoax. All major virus detection houses signed a mutual agreement to share their virus research. At one point, all these compagnies decided they would compete on features, ease of use and so forth, but not on virus coverage.
They did so in part to better protect their consumer, but also to dodge the baseless accusation made above.
Re:Interesting. (Score:4, Informative)
Um, you do realize that Linux contains quite a bit of architechture-specific stuff, which can be enabled or disabled at configure time ? Such as support for SMP or NUMA, for example...
Coming to think about it, I don't think a 32-bit processor would be much amused being treated like 64-bit one, and yet Linux supports both...