Virus Writers Look Ahead: Target 64-bit Windows

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."

Comments

Re:Interesting.

[random_culchie]

Well I'm sure its a concern when they are trying to cause stack overflows and the like.
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.

oldschool

[prockcore]

This is an oldschool virus, it works by appending itself to the end of an .EXE, the Linux "proof-of-concept" viruses worked this same way.

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 .MSI files instead of .exe installers. (They work the same, double click the .MSI and it runs MS's Installer, but the MSI can't run arbitrary code.. it works like an RPM in this regard).

The installer should prompt for the Admin password and install the .exe so that only admin can write to it.

Any .exe not installed by the MS Installer should be marked as "dirty", and windows should refuse to run it.

This would prevent this type of virus. Coupled with XP64s support for NX, you'd actually have some semblance of security.

Re:oldschool

[mlock]

> I propose that all software should be distributed
> as .MSI files instead of .exe installers. (They
> work the same, double click the .MSI and it runs
> 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/ms i/setup/ adding_launch_to_the_customaction_and_binary_table s.asp

Like the post-conf scripts in RPM and DEB :-)

Re:Interesting.

[vi (editor)]

A virus doesn't need any stack overflow as it spreads by the user executing infected programs.
The techniques you describe are usually used by worms.

Re:conspiracy?

[flonker]

Virus writers will frequently submit their own virus to the AV companies, to get it listed in the AV software. They don't release it into the wild, out of ethics, but they get some ego gratification and acknowledgement. When AV companies claim they detect a huge number of viruses, most of the viruses they detect have never been seen in the wild. It's a good thing too, as most viruses in the wild are very simple things. Some proof of concept viruses can be extremely hard to detect and remove.

3 reasons....

[DrYak]

1. First most important technology :
AMD64 processors have NX extension.
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).

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.