This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

Feature: Security

Torvalds creates patch for cross-platform virus

By Joe Barr on April 18, 2006 (8:00:00 AM)

Share    Print    Comments   

Linus Torvalds has had an opportunity to examine the testing and analysis by Hans-Werner Hilse which we reported on yesterday, and has blessed it as being correct. The reason that the virus is not propagating itself in the latest kernel versions is due to a bug in how GCC handles specific registers in a particular system call. He has coded a patch for the kernel to allow the virus to work on even the latest Linux kernel.

That may sound terribly complex, so let's break it down. A system call is made when an application, in this case, the virus, wants the kernel to perform a task for it: perhaps to read some data, or write it to a file, or so on.

As part of the housekeeping done by an application before such a call, specific registers -- a register is a temporary storage address which can be accessed as fast as possible by the CPU -- are loaded with additional information required to perform whatever task the call is asking for.

If you wanted to move a string of data like "CAPZLOQ TEKNIQ 1.0" from one place in memory to another, you would need to load the address where the string begins in one specific register, the address where you want it moved to in another register, and the number of bytes to move in yet another.

By convention, applications assume that certain registers will not be changed during the call. The reason the virus did not work in the latest kernel is that one register, the ebx register, which the virus expects to remain unchanged, is being overwritten.

The bug, which seems to me is more of a bug in GCC than the kernel, doesn't seem to appear in most code. It takes the rare combination of hand-crafted assembler code and the use of old, now deprecated, system calls to appear. This lends support to the speculation that this virus is not new code at all, in spite of how Kaspersky Lab is trying to use it to drum up new business.

I wrote Torvalds with Hilse's suspicion that the problem is caused by the ftruncate system call, manifested in the erroneous old_mmap function. According to Torvalds:

This is exactly right. "sys_ftruncate()" seems to corrupt %ebx due to a compiler issue. We've had that issue before: the kernel uses some special calling conventions where the system call stack is both the saved register area _and_ the argument area to the system calls.

That speeds up system call entry, since we avoid any unnecessary argument setup costs, but sadly gcc then thinks the callee function owns the argument stack, and can overwrite it. We've had hacks to avoid it in the past, but the ftruncate case has gone unnoticed (see later on why it doesn't matter for any normal apps).

So, for sys_ftruncate(), gcc compiles it to

        sys_ftruncate:
                movl    4(%esp), %eax   # fd, fd
                xorl    %ecx, %ecx      # length
                movl    8(%esp), %edx   # length, length
                movl    $1, 4(%esp)     #,
                jmp     do_sys_ftruncate        #

where that "movl $1, 4(%esp)" overwrites the original argument stack (the first argument, which is the save-area for %ebx).

Sad, sad. This particular case only happens with "-mregparm=3", which has been around for a long time, but only became default in 2.6.16. Which is probably why Hans-Werner didn't see the problem with older binaries. He just compiled with a different configuration.

Now, the reason normal programs don't care is that glibc saves and restores the %ebx register in the system call path. So if you use the regular C library, you'd never care. The virus has probably been written by hand in assembly, and because it didn't save/restore %ebx, it was hit by the fact that the system call modified it.

(To make it even harder to hit - it probably also only happens with the old "int 0x80" system call mechanism, not with the modern "syscall" entrypoint. Again, you'd probably only see this on old hardware _or_ if you wrote your system call entry routines by hand).

So the virus did a number of strange things to make this show up, but on the other hand the kernel does try to avoid touching user registers, even if we've never really _guaranteed_ that. So the 2.6.16 effect is a mis-feature, even if a _normal_ app would never care. It just happened to bite the infection logic of your virus thing.

Hilse has tested the patch provided by Torvalds as a workaround, and reports:

Indeed, this worked. With a recompiled kernel, everything is running as expected. And yes, it is using the int 0x80 interface from assembly code. As it's viral code, it is trying to avoid any overhead and reuses registers as much as it can (from what I can tell).

Leave it to open source hackers to debug and fix aging viral code so that it works correctly. And shame on the anti-viral industry, Kaspersky Lab in particular, for its attempts to deceive the public by passing off old code as something new.

Share    Print    Comments   

Comments

on Torvalds creates patch for cross-platform virus

Note: Comments are owned by the poster. We are not responsible for their content.

Bah, humbug

Posted by: Anonymous Coward on April 19, 2006 05:51 AM
What annoys me is that everybody seems to have completely missed the important thing about this piece of code. Who cares that it's a virus? It could be a fractal generator or a rabbit breeding simalation for all I care, but the important bit would be the same in any case: it's a cross-platform binary. Y'hear? Proof of concept that executables can be built to work transparently in both Windows and Linux at once! Not to mention that with the Linux compatibility efforts of the various *BSD teams this could go even further again.<nobr> <wbr></nobr>:)

#

Re:Bah, humbug

Posted by: Anonymous Coward on April 19, 2006 06:29 AM
Why would why want a cross platform binary? It would be bigger and slower, and completely unnecessary.

#

It's not a cross-platform binary

Posted by: Hans-Werner Hilse on April 19, 2006 06:38 AM
The proof-of-concept virus is not a cross-platform binary in the sense that a single executable is cross-platform. It just contains cross-platform binary code, but the containing executable is always platform specific.

I didn't verify this, but I definately think that it's impossible to create an executable that is both a valid PE and an ELF file. And I don't see much use for this, either.

#

Re:It's not a cross-platform binary

Posted by: Joseph Cooper on April 19, 2006 07:42 AM
If that's it than how is this any more cross platform than anything else?

Of COURSE the "code" runs on either platform, they're both x86. I think that's the whole idea behind Wine. Windows code will run happily in Linux if one provide's a launcher, linking facilities and clones of relevant dynamic libraries.

You know... Things that normally are NOT provided, thus making the whole "cross platform" issue pretty irrelevant unless the user manually runs Wine.

I think all this demonstrates is that if you manually download and run a program, it can edit files that you give it access to.

That's not a virus at all, that's a trojan, and obviously Linux isn't any less vulnerable to an idiot between the chair and keyboard if they're the admin. (And most people with PCs ~are~ their own admin.)

#

Re:It's not a cross-platform binary

Posted by: Anonymous Coward on April 19, 2006 04:25 PM
f that's it than how is this any more cross platform than anything else?

It is by being two programs in one. The linux version does not need wine. In one version, it is a Windows program with a Linux program inside (think self-extracting ZIP). It will infect Windows programs like any other infecting virus, but when it sees a Linux program, it will infect it with the Linux version of the virus.

Similarly, the Linux version is a Linux program with a Windows program inside. It will infect Linux programs normally, but if it sees a Windows program, it will infect it with the Windows version.

(Or does it not go Linux -> Windows?)

That's not a virus at all, that's a trojan

Nope. To be a trojan, it would have to pretend to be something else (Remember Troja? The horse pretending to be a gift, but really was the greek army). Destructive code pretending to be destructive code does not go into the category "trojan". Nothing wrong with destructive code, just look at rm, mkfs...

#

Re:It's not a cross-platform binary

Posted by: Hans-Werner Hilse on April 19, 2006 04:59 PM
> (Or does it not go Linux -> Windows?)

It does. And your understanding of its working is correct (though both Linux and Windows "programs" do share large amounts of code, i.e. there's no strict separation. For system dependent functionality the code path is conditionally separated). And you're right, it _is_ a virus. Nothing special, nothing new, though.

#

Re:It's not a cross-platform binary

Posted by: Anonymous Coward on April 19, 2006 10:19 PM
Troja? I think you mean Troy.

#

Re:It's not a cross-platform binary

Posted by: Anonymous Coward on April 19, 2006 10:52 PM
just a spelling more similar to greek original..<nobr> <wbr></nobr>:)

#

Re:It's not a cross-platform binary

Posted by: Anonymous Coward on April 19, 2006 10:38 AM
I didn't verify this, but I definately think that it's impossible to create an executable that is both a valid PE and an ELF file.

It definitely isn't, for one simple reason: PE files must start with the <a href="http://en.wikipedia.org/wiki/Magic_number_(programming)" title="wikipedia.org">magic string</a wikipedia.org> "MZ" (the initials of the <a href="http://en.wikipedia.org/wiki/Mark_Zbikowski" title="wikipedia.org">person</a wikipedia.org> who designed the DOS executable format it derives from), while ELF files must start with the byte 0x7f followed by the string "ELF".

#

The difference between Windows and Linux

Posted by: Anonymous Coward on April 19, 2006 06:06 AM
Linux people patch viruses then block entrance the vectors. No way into a system does not matter how effective the core virus code is.

Microsoft would never even think of doing stuff like this.

Bad code is bad code if its in a virus or a application. Most secuirty wholes trace to bad code.

#

Humbug, Indeed

Posted by: Anonymous Coward on April 19, 2006 06:10 AM
These people are reaching pretty far to obscure the fact of the cross-platform nature of this executable, and that kernel versions up to 2.6.15 (and now, beyond) are vulnerable.

#

Re:Humbug, Indeed

Posted by: Anonymous Coward on April 19, 2006 06:32 AM
"Vulnerable"? In what way?

#

Re:Humbug, Indeed

Posted by: Anonymous Coward on April 19, 2006 07:02 AM
Exactly!

If Linus himself had to patch the kernel to make it work, then what the heck does this say about the difficulty of creating malware for Linux? (or *nix in general?)

#

Re:Humbug, Indeed

Posted by: Anonymous Coward on April 19, 2006 07:24 PM
Not much considering it was old code using unconventional methods to serve as malware... Honestly if anything it'd be easier to create malware for a Linux system if you can get the user to run it (Which I'd guess would be considerably harder.) I mean really I'm sure I couild come up with 5 unpleasant working scripts off the top of my head that would effect a large portion of Linux systems (those that run as root for whatever reason...)

#

Re:Humbug, Indeed

Posted by: Anonymous Coward on April 19, 2006 09:32 PM
Sure rm -rf / packaged into an rpm. Thats why we look at code, have peer review and watch forums and irc. That's why security needs to be built into the user and thier usage as well as the system. Viruses are no threat to Linux.

#

He fixed a BUG in the kernel

Posted by: Anonymous Coward on April 20, 2006 10:07 PM
He didn't add a vector, he fixed a bug that just happened to be interfering with the virus.

#

relief joint

Posted by: Anonymous Coward on May 28, 2006 06:14 PM
[URL=http://painrelief.fanspace.com/index.htm] Pain relief [/URL]
[URL=http://lowerbackpain.0pi.com/backpain.htm] Back Pain [/URL]
[URL=http://painreliefproduct.guildspace.com] Pain relief [/URL]
[URL=http://painreliefmedic.friendpages.com] Pain relief [/URL]
[URL=http://nervepainrelief.jeeran.com/painrelief<nobr>.<wbr></nobr> htm] Nerve pain relief [/URL]

#

Sheesh, what foolish garbage.

Posted by: Anonymous Coward on April 20, 2006 12:16 AM
No one fixed viral code, and no one deceived anyone. Nor is it a bug in gcc, but I guess "the kernel uses some special calling conventions where the system call stack is both the saved register area _and_ the argument area to the system calls<nobr> <wbr></nobr>... gcc then thinks the callee function owns the argument stack, and can overwrite it" is beyond your comprehension.

#

Re:Sheesh, what foolish garbage.

Posted by: Joe Barr on April 20, 2006 12:34 AM
Nobody claimed the viral code was fixed, rather that the kernel was patched (fixed) to allow the viral code to run. As far as gcc is concerned, perhaps you know it and the kernel well enough to contradict Torvalds, but I sure don't. He is pretty clear in his description of events, and gives example code generated by gcc to back it up.


What do you have to offer on the subject?

#

antivirus vendors deserve trashing, but

Posted by: Anonymous Coward on April 21, 2006 02:06 AM
Now, I agree antivirus vendors deserve good trashing now and then. However, Kaspersky may be right in saying that 'now that the proof-of-concept is released', new threats will come in. It doesn't matter when the code was written; what matters is when it became publicly available.
(And yes, a bug is a bug; kudos to Torvalds.)

#

Pain

Posted by: Anonymous Coward on May 28, 2006 06:12 PM
[URL=http://painrelief.fanspace.com/index.htm] Pain relief [/URL]

  [URL=http://lowerbackpain.0pi.com/backpain.htm] Back Pain [/URL]

  [URL=http://painreliefproduct.guildspace.com] Pain relief [/URL]
[URL=http://painreliefmedic.friendpages.com] Pain relief [/URL]
[URL=http://nervepainrelief.jeeran.com/painrelief<nobr>.<wbr></nobr> htm] Nerve pain relief [/URL]

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya