It seems that the reason it's considered a POC at this point is because it has no real payload. All it does is spread, and not nearly as heinously as Blaster/Welchia/Sasser.

As soon as it gets backdoor or downloader functionality... then it becomes a more serious threat. And really you, me, and the guys at Secunia/SARC/SANS/ISC/etc all know that's where this is headed.

So yes... in the sense of where this particular piece of malware is headed, this is a proof-of-concept. It's a live test of the progagation mechanism. The payload will be dropped into place soon... probably in the next version since this one looks like it's working fine.

And really you, me, and the guys at Secunia/SARC/SANS/ISC/etc all know that's where this is headed.

Hmm, well in my case it would end up likely being blocked a network-level, as my IPtables log it's unusual activity. Of course, I don't run as root most times... so the best it could do is create infection in files writable by my user.

I suppose it *could* try connecting to outside locations to send email or something of the like... assuming it could find a server to connect to (my webmail address book wou

A worm is not a virus. A virus doesn't exploit holes in web servers, it just infects binaries.There are challenges in making a virus for both windows and linux, although it is definetely possible:A while ago it was the winux [about.com] virus (also a proof of concept)Unlike a worm though, a virus would have a hard time to spread in a linux environment, as it ishighly unlikely that enterprize linux users have write access to any kind of binaries... There is howevera dangerous situation i can think of: a system running w

Think of it - the kernel code is out there - it boots without any system libraries already being loaded. The printk (kernel print function) doesn't call the os at any point - it has enough knowledge to talk to the hardware directly.

Any real operating system (Windows NT and up, Linux, *BSD,...) prevents you from doing any of the stuff you mentioned. You can't just load a program and start doing low level IO to ports. You can't just bypass the MMU and paging system and write directly to physical memory. You can't just write directly to video memory. You can't just have your program load and start acting like it's the operating system. Any operating system worthy of being called an operating system prevents that. Device drivers would come closest, but they most definitely need system calls.

So, do the same, and add enough functionality to read and write to the various filesystems out there, and you're home - you don't even need to do it in assembler... just #include the appropriate pre-existing header files, and #include any code that you would normally call from a shared library.

Yeah...okay. For the moment, lets pretend it's possible to directly access the disk and filesystem from a user program, without system calls. To be any use at all as a cross platform virus, the program would need access to NTFS, ext2, FAT32, and ReiserFS. Writing filesystem code isn't trivial. I would be very impressed if a single person could implement any one of those filesystems in a reasonable amount of time, and all 4 would be nothing short of impossible. Let's just say that if somebody had the skill to do it, they'd be too busy making buttloads of money to waste their time.

#include the appropriate pre-existing header files, and #include any code that you would normally call from a shared library.

I'd love to hear your explanation on how to do that...

But, the whole thing is pointless. Even if you did manage to write filesystem support for all the required filesystems and were able to #include the code from the shared libraries the operating system would still stop you the instant you tried to read or write directly to the disk.

Windows users are prepared for viruses and the reason Linux users do not sweat them much is not because linux viruses do not exist; it is because system design makes their impact minimal.

Actually, you're quite wrong. Linux flaws have existed and are still found today that can be (and have been) taken advantage of. The reason Linux users don't sweat is because flaws are spotted quickly by many people who read the code, and fixed quickly too. That and people who code open-source tend to produce good code, as a matter of pride.

Oh and by the way, Windows has a "safe"(well, safer) operating mode in the form of a user account, but nobody uses it because it's a PITA, so everybody stays in supervisor mode and bad things happen.

Yeah, but even people that know about the "normal" user accounts quickly discover that almost all software written for windows doesn't handle non-admin accounts well. Ever try to install a program just in user space on Windows? If it works at all, you're lucky, and that isn't even scratching the surface of the problems. Got a network password? You can't just switch users to admin (like Linux) or use a sudo password (like Mac) - no, you need to log completely off of your user, then log on as the admin user, install the program, and log off as admin, then log back in as your regular user. Do you have any idea what a MASSIVE pain in the ass that is, especially when I have 20-30 windows open (many are Exceed based X sessions) and am trying to get work done? After 2 months of that and multiple programs that plain wouldn't work if they weren't running as an admin user, I switched back to running exclusively as an admin on Windows.

I do it all the time in windows. this is an XP-only solution, but meta-l-s or logout/switch user leaves your windows untouched to open an admin account. And if that's too much work, there's a 'Run As' box that (on my system) automatically appears when something that requires admin powers to install is run. Not to mention you can also do something like I do, install it in a folder with it's ACL set to child inheritance and rwx for your user account, which doesn't even require admin power to install in.So it'

The problem isn't that it isn't there. The problem is that you need to do something to make use of it. On OS X, if there is some task that needs admin access, I get prompted accordingly. With windows, such functionality is only available in certain control panel applets.

Run the Add/Remove Programs control panel applet as your admin account. Then use add new programs to run the installer. The other benefit is that the installer is running as admin, so you can browse to installs out on the network that live in places users can't reach.

"Actually, you're quite wrong. Linux flaws have existed and are still found today that can be (and have been) taken advantage of."Actually that is pretty much in line with what I have said and does not make me wrong at all.

The system design and development model has led to two things, a shortage of privilage escalation flaws (flaws isn't good enough, they have to allow a user account to gain root under conditions the virus can create) and a short lifespan of any such flaws that exist.

The lack of market share makes a big difference too. Ignoring the (generally true) presumption that most virus writers aren't going to target an OS whose users are by far in the minority, there's also this to consider (shamelessly plaguarised from some guy's journal I read. Wait, that was my journal. Just wait until I get my hands on myself.

Here's a question. Suppose you have a biological virus that can only live inside of hosts that are human, male, that have blue eyes and black hair, and that are over 6

"The reason Linux users don't sweat is because flaws are spotted quickly by many people who read the code, and fixed quickly too."It leads me to assume as though you are implying that "Linux users" as a whole also UPDATE patched software compared to Windows users which I have a hard time believing personally. I am NOT implying however that Linux users are worse at maintaining updates than Windows users...It would be interesting to know a factual study since many Linux distros as well as Windows provide a

Oh and by the way, Windows has a "safe"(well, safer) operating mode in the form of a user account, but nobody uses it because it's a PITA, so everybody stays in supervisor mode and bad things happen.

It's not just that it's a PITA, it's that by the time you configured system security to the point where your apps would work in the user context, you've created enough holes to where it doesn't matter any more.

Anyway, I haven't been infected by a virus in ages, yet I run as Administrator at all times -

I just want to say that anybody that thinks running as User (or even Power User, if you must) and using RunAs is a pain in the ass has not even tried it seriously.

Well, I'm reading your post, and if it doesn't get attention it's not because you're a coward, it's because you're an idiot.

RunAs DOES NOT WORK. Oh, it works sometimes, but any process spawned from your installer will run as the user, not the RunAs user as which the installer is running. This is because of a conscious design decision in W

Windows users are prepared for viruses and the reason Linux users do not sweat them much is not because linux viruses do not exist; it is because system design makes their impact minimal.

There are lots of reasons why it's harder to infect 'NIX systems.

1. Since on many LiNuX distros, the single source of binaries is usually the distributions' package system, it is usually very easy to detect anything out of the ordinary. The trusted channel is a GOOD thing in these cases.

2. Add in a tool like AIDE (or Tripwire) and you can immediately see everything that is off with your system.

3. How about Linux (and most UNIX) not allowing ctime changes to anything but the current time? The ctime (often said as creation time, but wrongly so- it's the CHANGE time) on any update will always be the current time. The _only_ way around this is to change the system time before you modify files

4. Priv seperation is a big thing. Daemons aren't run as root (or if they do, they drop privs right away). There is no svchost.exe running your services at NT_AUTHORITY or SYSTEM like there is in Windows. Then of course there's no need to run your Web browser as a user with any rights at all. IE7/Vista will fix this of course. Personally I like making, even FireFox, setuid to some untrusted user with no access to files

5. Embedding scripting in every tool isn't as popular in the UNIX worlds, as the core tools work so well. There's no need for office software to have scripting capabilities to change all the files on teh system. There's no need for it!

Actually, you're quite wrong. Linux flaws have existed

So do cars, toasters, appliances, and pretty much every item. Welcome to the age where quality means nothing.

The reason Linux users don't sweat is because flaws are spotted quickly by many people who read the code, and fixed quickly too. That and people who code open-source tend to produce good code, as a matter of pride.

They produce good code because they do it for themselves. Most open-source developers are developing for themselves. Every project starts up as "this IMAP server doesn't suit my needs. I'll make a better one". Of course the people who do that are normally the technically able. People make projects for themselves because there's a need that hasn't been met or they're unhappy how it's being met by someone else. Otherwise there's lots of people wasting their time. DJB was unhappy with sendmail/BIND and made alternates. BincIMAP, COurier, and Dovecat folks make them because the others and UW-IMAP didn't do what they want. Patches are submitted to fix something that's affecting them, may affect them, or to add an enhancement they want. Time is money, and people ultimately want to contribute their time for their own benefit somewhere down the road.

Oh and by the way, Windows has a "safe"(well, safer) operating mode in the form of a user account, but nobody uses it because it's a PITA

Even then, you'd be surprised what you can accomplish to destroy the system. Keep in mind, if you're running a SINGLE USER system as a user in order to add security, you're protecting your LEAST valuable asset. I can blow away a system and install Windows/Office/Adobe and all the tools I need in a few hours and have it configured perfectly. I'm sure most people here can. Now replacing the data would take years! Replacing the productivity lost to viruses/spyware/virii can't be measured. Assessing the impact of leaked administrator and bank passwords could be huge!

Microsoft made a number of bad decisions (security-wise) in pursuit of "user friendly" systems.

To be fair, most Unixish system developers made a number of poor decisions usage-wise in pursuit of "secure" systems.

OS X seems to be the closest to blending the worlds, although it has some interesting foibles all its own. I look forward to the next ten years, because I think everyone is starting to get it all the way around. Uncharacteristically, I'm pretty damn optimistic.

Potentially exploting local privilage elevation exploits to get root is anything but minimal.

Infecting software after it has been compiled is anything but minimal.

Using social engineering to get root is anything but minimal. How many users do you know who would enter their superuser password to "get free screensavers"? Too many.

Pretending that you're protected by design to the problem indicates that you don't understand how viruses really work. Guess what? You can run as a non-root user in Windows, too. But you can still do a ton of damage as a normal user. Spam relays and DDOs botnets don't need root access, just the ability to send data over the network. How about modifying your GNOME or KDE menu to point to a fake terminal entry or fake admin tools? How do you know that the "gnome-terminal-emulator" you're now typing your password into (through sudo) isn't actually stealing it?

This is the real world. Attackers are smart, they are motivated by profit (because of the spambot racket), and they have plenty of time to find the next buffer overrun.

Here we have the single user versus multi-user idea. On a multiuser system the virus can only delete things that are owned by the same user or group as it is running as. *nix is a multiuser system even if only one person uses it, since various programs run as virtual users such as nobody, lp and various others. Unless you are tricked into running it yourself or it somehow gets root via privilage elevation through major flaws it can't do a lo

Nevertheless, why do you run at a privilege level that can delete everything in your home directory? Is it so you can delete _a_ file that you make it possible to delete _any_ file?

This isn't necessary; I regularly run applications with split privilege levels. My "main" account and my "run" account are in the same group. If I need to edit a file, my vi-wrapper gives group-write permissions to the file I'

Doubtful, losing docs just means replacing them. Nowdays even mom and pop have some form of backup, even if it is just photo cd's. Losing the system means money. Either a new computer (if they do not have a tech they call) or calling a tech and paying him $65+/hr to fix their system for them.

As for users more informed than mom and pop, they have routine backups of their home directory at a minimum. They may or may not have backups of their tweaked configs.

That would work great if you got complementary photo CDs from Walgreens or CVS when you print digital photos from a memory card. Only you don't. CVS charges $2.99, IIRC, I'm not sure how much Walgreens charges. Pretty sure it's not free.

"And, of course, you're assuming they want to print all their photos."

And of course, you are assuming they know how to do anything else. It is not that mom and pops wouldn't use their computers for photos, it is that they are not technically capable to do so. Even they could figure it out, they are too afraid to try.

"Of course, there are bugs (smth like gaining ring0 from user etc) - but they exist on all systems"Yes. But they exist at all times on windows systems. At the present moment there are none I am aware of on linux systems. If there were, they would probably be patched by tomorrow. I am not aware of any zero day exploits for linux. I can log onto a user account under windows and browse porn for a couple hours and see spyware that has infected the browser under every profile, right now with a fully patched XP.

The marketshare argument has been made before again and again. Until Linux has a 90% desktop share this can not be tested. The best we can do is look to the other popular open source programs that do have a stronger marketshare.

Apache is an excellent example, Apache is the market leader in a much more financially appealing segment than the desktop. Strangely it is Microsoft's underdog IIS program that suffers from exploits and worms.

Remember the permissions model under linux does not allow you to simply click a link and execute code... not even local executable code.

All of these are excellent points. Let me add a few...Could it be that the computer illiterate user would not have enough knowledge to make a file executable under linux and then create a launcher for it (it's not like you can just double click a file under linux).

Could it be that the exploit the virus uses to infect (since your common vector does not exist) would be patched within a few hours and the ease with which linux systems update ALL of the applications on the box would insure widespread distributio

You're all missing the point - this proof-of-concept makes NO system calls. There is NO need for "privilege escalation". Once started, it has enough knowledge of the host filesystem to read and write to files itself.

Bullshit.

User-mode processes - even those running as root - have no access to the hardware, except RAM (and then only pages mapped into the address space by the kernel) and CPU (and then only for a period of time decided by the kernel). There is no way to write to the host filesystem excep

All this means is that data communications and storage has reached a point in time where no one (in theory) is going to notice that infected files get 3 or 4 megs chunkier. The virus writers still have to find vectors into these systems. If they can't find convenient vectors, then the ability to produce a fat binary is useless.

What is this need that security researchers have to claim that all systems are equally vulnerable? Are they worried they're going to be out of a job if everyone moves to more secure computing platforms? I mean, really. They should be encouraging mass migrations to other systems, as it diversifies the playing field and theoretically helps everyone remain safer. But I guess that's not their bread and butter.

I think you answered your own question in a way, if the host has x86 emulation, then why wouldn't it be able to? That said, it's a long way from a POC to a real live virus. I can write a virus today and claim a POC, nobody has ever said that Linux is immune to viruses. Viruses aren't that complicated. That said, an effective (ie. turn it lose and watch it spread) virus would be very difficult to achieve on Linux precisely because there isn't just one flavor of Linux, running the same binaries, on a single arch... unlike another well known OS.

I'm kind of curious how it works. You can't just take, say, C++ and simply write the exact same code and it will work in both Windows and Linux. Some of the basics like cout do, but, once you start getting a little more complicated and try to modify files, then it gets tricky. I'm guessing we aren't talking about a Java type thing (supposedly Java has securities in place, though I've never directly tested them -- I do know that it can delete or modify a file though.) They mentioned ELF and Win32 executa

The linux version comes with WINE;-)When it says 'linux and windows', it will no doubt mean linux-x86, which means that java type code isn't required, as the processor instructions are the same (it's apparently written in assembly code). System calls would have to be done differently, as would inserting the code into an elf/exe file to infect it. One way I guess would be to have different entry points into the code, the linux/windows machines would start running at a different point within the code, but wh

The only thing that would make it different from having two seperate viruses*, is that it can jump from one platform to another (eg, over a network or dual boot system), and back etc, so a windows machine behind a linux machine could still be infected and vice versa, when possibly it couldn't otherwise.(* virus comes from latin, which is why many think you 'virii' it to make it plural. However, the latin word actually refers to a liquid, which would have quantity, not quantities, thus a latin plural is not

I'm kind of curious how it works. You can't just take, say, C++ and simply write the exact same code and it will work in both Windows and Linux. Some of the basics like cout do, but, once you start getting a little more complicated and try to modify files, then it gets tricky.

If you stay within POSIX it'll work. Now, there's a lot you can't do, but for just opening and modifying files you should be fine.

My guess is it's basically two separate pieces of code though. The advantage of doing this over separa

Could anyone who knows more programming than I do (which, btw, isn't so hard so feel free to hop in here) give me just an idea of how this is even possible?

Sure. The code is compiled such that the code and data both link into the same segment. That segment can then be exported to a flat binary file. This file (the meat of the virus code) is then inserted into an EXE and an ELF executable. These two variants execute on their respective platforms. When the virus attempts to infect a new file, it detects wh

It was called Win32S, and actually worked amazingly well. I only ever had 1 programme not work, and that was a quiz programme called "You don't know Jack". This americanism confused me greatly, and I was very annoyed that I couldn't run it and find out who Jack was.

"Writing a cross-platform worm is difficult because it limits you to functions that are available on both operating systems," Ullrich said. "You have to also code the virus in assembly to make it work without relying on any OS-specific function," he said.

This isn't actually quite true, it is merely one way of doing so. You could easily write a virus that uses tons of API and platform specific stuff, but contains a generic detection mechanism at the beginning of its execution and then forks between two pieces of code. One portion contains code specific to Windows and another code specific to Linux. Apart from the generic platform discovery code upon execution it would be like any other platform specific virus. I'm actually surprized this is the first, at least publicized, detection of such a virus.

It's not the first, I recall one before. And you don't even need detection code, you just write a different entry point address into the elf header as you would the exe header. You can have two different payloads, and two different copy mechanisms, as long as both copy both, not just themselves. In fact, there's no reason to stick to just 2. You can have a single virus that spreads across platforms/architectures, it just makes it bigger and easier to spot.

"Writing a cross-platform worm is difficult because it limits you to functions that are available on both operating systems," Ullrich said. "You have to also code the virus in assembly to make it work without relying on any OS-specific function," he said.

Why?

Doesn't it seem plausible that it could just have one copy of itself for each executable type, and then whichever one actually executes knows how to insert the other(s) if needed? Then it's not really a single virus, but more of a set of symbiotic

Nooooo! not my AIBO. I knew I should have left off that email and news fetch hack.

What a bunch of BS. How exactly are they supposed to get this assembly code kludge to my machine? Are they going to try to barf zlib? As the article also pointed out, these things have been around since year 2000. In those six years there has been a big fat nothing done with them.

Woah, not my Commodore PET [old-computers.com] (Personal Electronic Transactor)? Nooooo..... I *love* that chicklet keyboard. And the awesome monochrome graphics. They have the playing card suits built in as *characters*, mind you. You can 1000 PRINT them in the built in BASIC!

Let me tell you, though, it was a bitch getting an entire TCP/IP stack working in the 4K of RAM and still have room for a web browser. And don't even get me started on how hard it was to get 100BaseT working over the exapasion port.

About a week ago, for various reasons, I decided to format my laptop and put Windows XP Professional on there. I previously had Slackware Linux 10.2 installed, but since my desktop has been dual-booting for a while, I figured I might as well get my money's worth and put Windows on the laptop (Linux also doesn't support the SD card reader, but that's another story). The installation went nicely, and I continued to do the tedious tasks that you do after a format. (validate windows, download patches, install drivers and apps, etc...) I installed a second user account for administrative uses and named it "Root".

I logged into my "Root" account, and installed Chessmaster 9000. When I logged back into my regular user account, the game wouldn't start. After a while, it dawned on me that Chessmaster installs the bulk of the data in your My Documents folder. So I uninstalled it, then tried to install it under my user's account. Now, if you're trying to install a program, and you're not the Administrator, a simple dialog will pop up and prompt you the password. However when the install finished, the program wouldn't start. Since I installed as Administrator (I had no choice), I the data was stored in the Administrator's My Documents folder. I tried to link to it - I even tried to install as Administrator, and put a link to his folder (and changing permissions) in the default folder so all users would use it.

Nothing worked properly. I ended up having to change my user account back to Administrator privileges, install the program, then change it back. And this is just for Chessmaster. Other programs are even worse. Doom 3, FarCry, and Call of Duty all install their data in the Program Files folder. So in order to play the game without being root, you have to change the permissions on the saved games folder.

The point of the story is this: Linux doesn't have the problems that Windows has, because it's more secure by design - not by luck. A significant amount of programs are designed for the user to have Administrator access, and assume that you will always run with such permissions. Windows didn't switch the masses to the NT design until XP, which was released 4th Quarter 2001. As a result, you have generations of programs that assume they can read/write whatever and wherever they want - leaving a mess for the end user to sort out. In the end, they'll just say to hell with it and run as Administrator.

(And that's not even addressing the masses that bought OEM pc's that run XP Home with Administrator priviledes by defaut)

Meh. Sounds like a non-issue to me. Especially considering the rarity of cross-platform Win32/Linux binaries.

Just how does this badboy get on to my system in the first place?

People need to understand that any system that permits a user to run unsigned executable code is susceptible to some kind of "malware", if you can call it that. I place these "viruses" in the same category of rm -r -f / wrapped into a shell script.

When you're running windows, for instance, your unix filesystems are all there to be twiddled with, if the malware knows how. Unix' protection mechanisms would be useless because they're not what's running. So the virus could infect the unix partition and do all sorts of nasties later when you boot Linux. (The virus infection head or payload could include enough filesystem code to twiddle the linux files even if the windows system doesn't know how - all it needs is access to the raw bits, which good 'ol windows will be happy to grant.)

It could also work the other way, of course, with a linux virus or worm infecting things on the Windows partition. But given the relative vulnerabilities I expect most will work the other way.

There are numerious reasons why this is true.Reasons include:GNU/Linux is a minority platform.GNU/Linux is highly fragmented.GNU/Linux security is refined and updated often.GNU/Linux users are more educated.Windows has numerious security design flaws that promote viruses, that GNU/Linux systems don't have.Windows has numerious user interface design flaws that promote viruses, that GNU/Linux do

WOW!! I have a Windows XP\Linux Ubuntu Dual boot machine, I generally like to pride myself on my computer knowledge and am in the final year of a BSc In Software Engineering; I havn't even heard of a couple of those, though most of them I did, now if I, with quite a high amount of computer literacy compared with the general public didn't know this, how is your average consumer going to know, will they even understand once you tell them?

The real difference, for now at least, is that most Windows users run applications and more importantly web browsers with administrative privilages.

Most Linux/*nix users do not.

A properly written Linux/Unix virus will do the equivalent of rootkitting the ".bashrc". It hides itself in that file - then it redirects input/output through itself, being the man-in-the-middle. You won't notice it unless you log in as root and see that users have a disproportionate amount of space.

1) If you are considering the virus' validity all by itself, it doesn't matter what language it is in. If you are considering it as a proof of concept for a new type of virus, the detail of it being written in assembly is a) not as damming as you portray and b) probably not indicative of a requirement going forward.2) This is what *really* made me have to reply. You must have *no* idea of what exactly is ELF on a linux box. Every compiled application in the last 10 years or so has been almost exclusive