Slashdot Mirror
Ambidextrous Linux/Windows Virus
Lam1969 writes "Kaspersky Labs has reported a new proof-of-concept virus that can infect both Windows and Linux systems. It's called Virus.Linux.Bi.a/Virus.Win32.Bi.a and affects ELF binaries and .exe's from windows. SANS has a brief item on the cross-platform virus as well, but no information about a patch or signature yet."
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.
---
According to the latest ruleset, this post should be modded as Vorpal Flamebait +5.
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.
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
On windows, most people (at least, home users) are sitting on admin, most people on linux use this account only for configuration etc.
...)
On root account in *nix, u can do anything with computer.
In windows, this is the same.
Of course, there are bugs (smth like gaining ring0 from user etc) - but they exist on all systems, even bsd sometimes...
Why *nix virus ale such rare?
-these systems are less popular at home
-these systems are used by more experienced user (eg. not clicking on NakedPamela.exe wchich arrived from 235gdsfge4@235cs.com
The basic action of virus - infecting a files - can be done in all systems.
If virus doing that thing will be run on linux, on user account-it will infect all files with write permisions (/home/user ?). Same on windows.
But if u ran it from admin/root account...
The biggest weapon against such thins is to use brain... os is less important (of course if u dont run 9x...).
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.
Actually most people run with the version of Windows that came installed on their computer. And these accounts are, from the best of my knowledge, always Admin.
Yes and no. It isn't so much that Linux is a more secure operating system (an argument I won't touch with a 1010 foot pole). It is more that Linux is a more diverse operating system.
If I run Windows XP (perish the thought), and 1000 other people run Windows XP, we are all running the same operating system. Except for a patch or two, we are running the same code with the same holes. A virus that hits one hits us all.
Now, if I run Linux, and 1000 other people run Linux-- well, we aren't all running exactly the same OS. Red Hat, SuSe, live CDs, home brews-- each and every one is slightly different. Top that off with different modules, services, etc running-- and you effectivly have a large number of different operating systems. If a malware exists that uses an explot to propogate, chances are that it isn't going to hit all 1000 of us.
And yes, I know there's a distinction between a virus, a trojan horse, and a worm. But for the sake of argument, the malware I'm talking about is self-propogating and self-executing in some way. Anyone can write a shell script that does rm -rf / and trick at least a couple people into running it.
The real vector that should be a concern for Linux users are cross-platform shares. Let's say you make your Linux box as secure as possible. No holes in any of the services, etc. Well, if you are on a mixed-OS network, and you Samba a Windows drive that is infected-- then you run the risk of being infected. Linux is just as vulnerable as Windows to malware once it has already been executed. So it is much easier to buffer overload the Windows box, and hope the virus gets Samba'd over to a Linux box.
Either that, or we all unplug from the net, power down, and encase our boxes in cement. 100% virus protection (though it would classify as a denial of service...)
UTF-8: There and Back Again
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.
The revolution will not be televised... but it will have a page on Wikipedia
"Actually, you're quite wrong. Linux flaws have existed and are still found today that can be (and have been) taken advantage of."
/home/granny/.email/files then chmod +X grandchild.jpg.exe, THEN ./grandchild.jpg.exe (in linux you have to create a launcher to execute a file in the gui, double-clicking will not work.
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.
Open source development leads to faster fixes, almost nobody argues this point anymore who is not pushing an agenda. Linux systems are far easier to keep up to date since they are almost entirely open source and free (speech+beer). The result are mechanisms like 'apt-get update; apt-get upgrade' that will update every piece of software on the system, whether os, 3rd party service, or text editor.
This and a strong security model (execute capability must be explicitly enabled by a user who knows how to do it and has permission, default create masks do not make files executable)(users ACTUALLY can only impact files they are supposed to be able to impact). Make the spreading of viruses on linux a non-issue. Flaws are patched faster than the viruses spead, damage is limited to a single user directory and even then only the data created since the last backup. Most clueless users are unable to execute the virus file in the first place because they are unable to set permissions.
grandchild.jpg.exe can never work on linux, period. You have to get the user to open a prompt cd to
"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,"
lol, if you say so. I challenge you to browse porn sites for a couple hours using IE under a user account. You will be amazed to find that spyware has spread beyond the one profile every time.
It is annoying, but not quite as annoying as you suggest. As the other poster said, Run As... works without logging out. You can also change shortcuts for badly-designed programs to "Run with different credentials" in the properties. But that still means you have to login each time you run the program, even if the program was intended to be a user program not a system one.
.ini file next to the program, which doesn't work if you can't write to that directory. If you have the Pro version of Windows, you can usually fix those by changing your permissions for that directory as well.
The badly-designed programs usually try to store settings in a
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's not as hard as you make it out to be, but requires a little bit more setup.
Remember, just because you don't know how to use it, it doesn't mean that the tool isn't there for you to use.
"Never attribute to malice that which can be adequately explained by stupidity." -Anon.
If RunAs worked reliably, you'd have a point. Secondary processes started by the installer default back to the standard user, and then fail because they require admin priveledges. PITA indeed.
Changa hates change.
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 Windows which is different from every other operating system I've ever used. In order to spawn a process as the RunAs user, you must manually look up the user that the process was spawned as, and use an entirely different function call which takes a user (probably a SID) as an argument. This means that when you start an installer with a 16 bit stub, which is still distressingly common even today, the install will run as you, not the user you entered in the RunAs window.
If YOU had really done a thorough examination, you'd know this already. Shill.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
That's fine, makes sense to me, but you will still need root access to install it properly.
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.
However, from a proper security perspective, you won't log in as root - you'd use a "lesser" account and "su" to root. That's how the virus will infect the system - it grabs the root password while you type it in, and it rootkits the system.
If you stick with a mindset that viruses can't spread under Linux, then you'll end up with the exact opposite you expect. While we may not be a tech level that makes this level of hacking practical (because it would generally have to emulate an entire operating system), don't be suprised when these attacks start appearing.
rd . /s /q
Been around since NT.
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.
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.
Maybe not
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.
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.
.exe. Now there are a lot of precautions to prevent this in an up to date Windows system, but architecturally this is how it happens. In linux, the permissions dictate and the permissions are not transferred with the file content (unless encapsulated by something like tar). gnome-open a potentially executable file without the executable permission and nothing interesting should happen.
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 exclusively ELF. Without ELF support, you simply don't have a working modern distribution. You could theoretically try to run the old a.out format, but that really isn't any more safe in the long term and highly impractical.
3) Again, the important aspect is 'proof-of-concept' This particular virus doesn't bother to attempt chdir.but that does not preclude the concept of more general implementation. But the rest of what you say is applicable. Once I would have said an inexperienced user frequently only bothers to run as root, since it makes things easier, but with the proliferation of strategies like Ubuntu, things are handled a lot more sanely. The lesson they learned is not to ask a typical user for a root password at *all*, lest they be tempted to use it for everything.
It is conceptually hard to see this thing spreading. The stategy of spawning from ELF applications means it has to be set executable by something prior to being run. In Windows they historically accomplish the analagous function by leveraging the weak strategy of filename based executable status and the 'friendly' feature of hiding extensions that only sometimes work, and you have 'nicepicture.jpg.pif' or something similar that a Windows app lazily hands the file over and then Windows make the lazy choice of honoring
Again, as non-root usage for even the lazy users increase, this strategy with respect to propogation becomes irrelevant as few users run applications capable of relaying the content that they would also have write access to. Now if by some miracle infected by a virus of this type with goals other than spreading, it can be almost as functionally devastating, despite the privilige separation. For the same reasons that the system files and other users are protected from a particular users activity, most of a single-user machine's important data is owned by the user. Sure, if attacked they could make a new user unaffected without reinstall as worst case, but they may have lost all their documents, records, and images they actually care about that aren't recoverable.
The net of it is that the stuff important to a desktop user is not protected from viruses, but the traditional executable binary approach of viruses just doesn't apply to linux. Exploiting buffer mismanagement and such in media players, document readers, image renderers, etc *are* applicable in linux as well as Windows and this would be the only sort of virus that I would watch to be a remote success. This strategy doesn't try to dance around the strong impedements at the low level architecture, but exploits the much more likely poorly coded app given permission to run legitimately by the low level platform.
XML is like violence. If it doesn't solve the problem, use more.