Slashdot Mirror
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."
I hadn't realised that there were sufficiently many fundamental changes to a 64-bit system as compared to a 32-bit system that meant that a virus written for one wouldn't work on the other. What's so different? How does a different integer or word size affect the functioning of a virus so greatly, when interoperability is such a priority?
Where can I sign up for beta testing!?
Your humanitarian side is showing through. Please make them watch Liza Minelli first, not last.
that Windows is just targeted because it is so popular, not because of inherent security problems.
After all Windows 64-bit is allready installed on millions and millions of machines so it is only natural that hackers attack it instead of those few machines that run 64-bit Linux.
Oh, wait...
Nevermind.
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.
.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).
.exe so that only admin can write to it.
.exe not installed by the MS Installer should be marked as "dirty", and windows should refuse to run it.
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.
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.
Tinfoil hat time: perhaps all the FUD about SP2 problems, users unwilling to update etc. is just being put out by spammers and malware merchants.
I agree there is a problem, especially with people who think they are creative. I'm afraid I was positively delighted when the author Louis de Bernieres lost the first 60 pages of his new novel becaue he had failed to make a backup, and complained that he didn't expect to have to make backups, he wasn't a computer expert (or words to that effect). People need to understand that failure to learn the basics can result in pain and distress.
Panurge has posted for the last time. Thanks for the positive moderations.
Some years ago I contracted with Symantec for about five months and worked closely with several of their departments, including the folks who did tech support for their anti-virus software. During that time Symantec offered a cash bounty to any techie who brought in a virus 'from the wild' that wasn't covered by the their antivirus software.
It was common knowledge that many of these 'wild' viruses were actually, in fact, written by the support staff themselves in order to collect on the bounty. But Symantec didn't care because this just allowed them to enlarge their virus definition file and show their customers why it was important to subscribe to their update service. From my point of view it was a "wink, wink, nudge, nudge" sort of thing.
This was one of just many things about Symantec which disgusted me so much that after that contract I refused to work with them ever again. I don't know if they still have an update service for their anti-virus software, but it wouldn't surprise me if many of our future 64-bit viruses came directly from employees of Symantec itself.
It's a great business model: release the viruses, then sell the software that combats those viruses. Unethical and illegal, but a solid money-maker for those who don't care about such trivial things.
Max
My god carries a hammer. Your god died nailed to a tree. Any questions?
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.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]