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

Comments

How is it POC?

[liliafan]

I guess it is time for me to double check clamav is still updating without any problems on my systems.

In 2001, the sadmind/ISS worm exploited a hole in Sun Microsystems Inc.'s Solaris to infect systems running vulnerable versions of the operating system. Infected systems then scanned for and attacked servers running Microsoft Corp.'s IIS Web server software. That same year, another proof-of-concept virus named Winux infected both Windows and Linux systems.

I am curious about how this is a proof of concept virus if it has been done before surely the concept has already been proven?

Re:How is it POC?

[JordanL]

I am curious about how this is a proof of concept virus if it has been done before surely the concept has already been proven?

It wasn't slashdotted last time?

Re:How is it POC?

[EndlessNameless]

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.

Re:How is it POC?

[Phillup]

There is however
a dangerous situation i can think of: a system running windows that has access to linux system binaries through
samba or nfs ...

If you create a share to one of your binary directories (/usr/bin/) then you deserve what you get.

Especially if you do it in a way that compromises the fact that only root can write to those files...

Re:How is it POC?

[phorm]

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 wouldn't exactly be easily sniffable by a virus), but in that case it would have to find a usable host or open-relay to do so anyhow.

No, linux-capable viruses have been around for awhile, and multi-OS is no more scary than those were.

Netcraft confirms...

[Syberghost]

...BSD just coughed up water and started breathing again.

Re:Netcraft confirms...

[jlarocco]

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.

I'll beat you to it..

[JavaLord]

100 bi jokes to follow

Re:I'll beat you to it..

[zpeterz63]

I'm not so sure...it could go either way.

Whatever

[AKAImBatman]

"For those thinking their "pet" computer is invulnerable to the virus threat -- it's not," SANS said.

Cue ominous thunder. (rolls eyes)

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.

Re:Whatever

[CdBee]

I'll be really impressed when someone comes up with an actual executable binary that contains code to run the appropriate installer on Linux or Windows - a cross-platform version of a Universal Binary

Re:Whatever

[Tim C]

If they can't find convenient vectors, then the ability to produce a fat binary is useless.

Unfortunately, there's a very convenient vector indeed sat at the keyboard of the vast majority of PCs.

Re:Whatever

[gEvil (beta)]

"For those thinking their "pet" computer is invulnerable to the virus threat -- it's not," SANS said.

Dammit! And I thought using 70s technology would keep me safe from all these modern-day viruses.

which architectures?

[jon787]

The article says the worm was written in assembly and I assume it means x86 assembly. Can the worm infect non-x86 Linux hosts?

Re:which architectures?

[molarmass192]

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.

Does this mean....

[da]

... linux is ready for the desktop? [ducks]

Re:Does this mean....

[The Ape With No Name]

No, but it is now ready of proof-of-concept cross-platform FUD.

Re:Not to worry

[GrumblyStuff]

Windows users are prepared for viruses...

What bizarro Earth are you from?

How does it work?

[Nazo-San]

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 executable binaries, so if it's Java, then that's just a frontend obviously. They wouldn't call it an ambidexterious virus if specific code were written for each OS though, right? The only single thing I can think of is maybe make a system call and run "del so-and-so" which in linux's case would rely on an alias being in place to actually run rm.

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?

You know, suddenly I'm reminded of .hack. In it, one amazingly powerful virus was able to wipe out almost all major operating systems with the exception of the single one, and that one was neither windows nor linux. Ok, it's just a story, but, do you suppose some nut wants to see if they can make this come true in their own way?

Re:How does it work?

[martinultima]

“In it, one amazingly powerful virus was able to wipe out almost all major operating systems with the exception of the single one”

So, let's try guessing what the single one is... OpenBSD? :-)

Virus Writer 1: Hmm, let's see... first we have to crack the unbreakable encryption on the root password...

Virus Writer 2: No, you idiot! You can't do that until you've found a security vulnerability in the operating system itself!

1: Well, there is the guy running the machine in the first place...

2: Yeah, like anyone would install a secure operating system that requires insane amounts of technical experience and just spontaneously fall for some virus scam thing...

1: I guess you're right then... oh well, back to waiting for another security hole...

Re:How does it work?

[x2A]

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 when infecting a new file, it would copy both sections of code into it, rather than just the bit that's running. You could in theory make a virus that will spread to many more systems, but each one makes the resulting virus larger.

Re:How does it work?

[alexhs]

I will give two possibilities :
1. "universal binary" : compile code for each platform you want to infect. That one might even work on other architectures

Code needs :
a. an algorithm to know which OS/Arch an executable is for (and needs to know if a file is an executable in the first place)
b. an algorithm to link the appropriate code part.

You have an Win/x86 trojan. He checks for files and finds an PowerPC/Linux ELF. He adds itself to the end of the file, finds a jump in the original code, reroutes it to the PowerPC/Linux part of the virus code. At the end of the virus code, does the appropriate jump so the original program still works.

2. checks for syscalls :
IA32 code (usually named x86) remains IA32 code, whatever your OS is. The biggest difference lies in syscalls.
have generic code (without syscall) checking what OS is running and set, say, CurrentOS. Each time you need a syscall, do a switch(CurrentOS) and execute the appropriate syscall.

I, for one

[sprag]

welcome our new cross-platform proof-of-concept viral overlords.

Its almost like playing buzzword bingo.

Reactions:

[Guppy06]

1. Linux and Win32? W00t, my WfW3.11 box is invincible!
2. So... why can't application developers do this?

Re:Reactions:

[redalien]

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.

Limited to ASM?

[neoshroom]

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

__
Write My Essay

Re:Limited to ASM?

[x2A]

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.

Re:Not to worry

[Rosco P. Coltrane]

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.

Took long enough...

[Eric Damron]

Well it's about time! Finally inter-platform operability.

Wrong and right.

[khasim]

Windows users are prepared for viruses...

Sure they are.

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

Pretty much.

Remember, it isn't about whether a virus exists for a specific platform or not.

It's whether you'll be infected or not.

And that is based upon the infection rate vs the removal rate. A virus that cannot spread faster than it is being removed will die.

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

Re:Wrong and right.

[heinousjay]

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.

Re:Not to worry

[sbrown123]

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.

Symantec

[rmsmith]

I find it interesting that this 'virus' appears shortly after Symantec reportedly gets cushy with the Linux press

Writing viruses for Linux is EASY. Getting them..

[Anonymous Coward]

..to spread is the hard part.

How to write a Linux virus.
http://virus.enemy.org/virus-writing-HOWTO/_html/i ndex.html

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 doesn't have.

Although this WILL CHANGE if certain Pro-GUI factions get their way.

Like having Gnome and KDE user interfaces ignore the traditional Unix permissions for certain types of files... http://thread.gmane.org/gmane.linux.xdg.devel/7014

Damn stupid shit.

But as it stands now a combination of social and technical issues keeps Linux users safe.

One example of a flaw in Windows that causes easy transmission of viruses... Executable files are based on their file names, not based on a permission model.

And it's not just 'exe' or 'bat'.. Here is a partial list of executable file extensions in Windows.
ADE - Microsoft Access Project Extension
ADP - Microsoft Access Project
BAS - Visual Basic Class Module
BAT - Batch File
CHM - Compiled HTML Help File
CMD - Windows NT Command Script
COM - MS-DOS Application
CPL - Control Panel Extension
CRT - Security Certificate
DLL - Dynamic Link Library
DO* - Word Documents and Templates
EXE - Application
HLP - Windows Help File
HTA - HTML Applications
INF - Setup Information File
INS - Internet Communication Settings
ISP - Internet Communication Settings
JS - JScript File
JSE - JScript Encoded Script File
LNK - Shortcut
MDB - Microsoft Access Application
MDE - Microsoft Access MDE Database
MSC - Microsoft Common Console Document
MSI - Windows Installer Package
MSP - Windows Installer Patch
MST - Visual Test Source File
OCX - ActiveX Objects
PCD - Photo CD Image
PIF - Shortcut to MS-DOS Program
POT - PowerPoint Templates
PPT - PowerPoint Files
REG - Registration Entries
SCR - Screen Saver
SCT - Windows Script Component
SHB - Document Shortcut File
SHS - Shell Scrap Object
SYS - System Config/Driver
URL - Internet Shortcut (Uniform Resource Locator)
VB - VBScript File
VBE - VBScript Encoded Script File
VBS - VBScript Script File
WSC - Windows Script Component
WSF - Windows Script File
WSH - Windows Scripting Host Settings File
XL* - Excel Files and Templates

Good luck training users not to use those. And the fact that you can launch executable programs by double clicking email attatchments is another huge shitfest of bad designs.

Re:Not to worry

[GrumblyStuff]

Sure they are. Here's the link.

H4WT P1CS V1RU5 PR0T3CTION CLICK H3RE

Re:How is it distributed?

[adnonsense]

I have reverse-engineered the virus and discovered an insiduous distribution mechanism:

root# wget http://warez.example.com/Virus.Linux.Bi.a.tgz
root# tar xzf Virus.Linux.Bi.a.tgz
root# cd Virus.Linux.Bi.a
root# ./configure --prefix=/usr/local/virii --with-natalie-portman=hot-grits --with-beowulf-cluster=yes
root# make && make install
root# PATH=$PATH:/usr/local/virii/bin
root# rehash
root# pwn3d &

Re:Not to worry

[halcyon1234]

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.

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

Re:Not to worry

[RzUpAnmsCwrds]

it is because system design makes their impact minimal

Deleting everything in my home directory is anything but minimal.

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.

No problem...

[mogrify]

I'm just recompiling my kernel without support for ELF binaries. Just a quick reboot, and I'

My PET?

[dbc]

"For those thinking their "pet" computer is invulnerable to the virus threat -- it's not," SANS said.

Woah, not my Commodore PET (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.

Guess it's finally time to retire the old PET.

How About a Story?

[Einstein_101]

Here's a quick anecdote for you:

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)

Re:Not to worry

[Creepy]

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.

Re:Not to worry

[shaitand]

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

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

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

Is this another do-it-yourself?

[WhiteWolf666]

How do you get this "virus"? You have to run infected code, right?

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.

Re:Is this another do-it-yourself?

[runderwo]

As a first step in this direction, I recommend placing the execution stack in ROM. Following that, we can move towards a ROM heap, and maybe ROM-based disk drives.

Re:Not to worry

[LightCecil]

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.

Re:Not to worry

[Reo Strong]

Evern heard about the runas command? It is also known as Secondary Logon.

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.

Oh gee, wow!

[Liam Slider]

Yet another proof of concept Linux virus that will never actually get out of the lab...oh wait, it's also a Windows virus. I guess it will get out of the lab...

Re:Not to worry

[colin_young]

I believe the parent is correct. e.g. the chicken is prepared for the oven...

Re:Not to worry

[andreyw]

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.

RunAs

[Changa_MC]

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.

Re:RunAs

[E-Rock]

No, just think harder.

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.

Linux Infection Instructions

[rossz]

To Infect your Linux box with Virus.Linux.Bi.a, please follow these instructions.

1. If gcc is not installed, install it.
2. Unpack the archive: tar xvzf Virus.Linux.Bi.a.tar.gz
3. Switch to the directory: cd Virus.Linux.Bi.a
4. ./configure
5. make
6. su root
7. make install

Enjoy

Re:Linux Infection Instructions

[Bob The Cowboy]

Compile from source??? No thanks, I'll just wait for the .rpm/.deb!

Re:Linux Infection Instructions

[Xtifr]

That's fine, makes sense to me, but you will still need root access to install it properly.

More Linux advantages...; protecting low value

[PhYrE2k2]

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!

-M

Re:Not to worry

[drinkypoo]

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

It's hard to lose your files in home too

[dbIII]

Deleting everything in my home directory is anything but minimal

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 lot. It really is like the joke "This is a linux virus. Please type 'rm *' - Thanks".

The real issue is about the virus code running in the first place. Since linux mail clients don't execute code in attachments because that would be a stupendously stupid thing to have a program do (Outlook not so good) that reduces the chance of a virus dramaticly. Since software is available in a different way people don't download bonzi buddy or whatever to linux, so that reduces the chance of malware a huge amount as well. There's still the chance of tricking a user into downloading a binary and running it - but that's reduced by the way package management is done and where people go looking for their binaries, usually in a distro repository.

As the way I understand it, in "the real world" as refered to before, single isolated incidents of people getting tricked into running malware is not what you would call a virus, simply because it is very slow to spread. The different system design as such is what makes the impact minimal. The different design means the problem instead is not a virus, but people getting in via poor security and running rootkits. Someone running bots to find vunerable machines and then getting into them is not a virus, and that's what we should be worried about more than a simplistic view based on what happens on very different systems.

How many users do you know who would enter their superuser password to "get free screensavers"?

On workplace machines it is very bad practice to let any of these people have the root or admin password on their machine unless it is in a development environment that can't talk to the outside world. The difference with the MS Windows environment is that there is a lot of stuff that can go wrong even without the admin password due to so many things running as that user. With home machines you have to take responsibility for your own actions.

Uh-Oh

[locohijo]

Steve Jobs' lawyer may come knocking at the author's door handling him a sub-poena about infringing Universal Binary patents.

And Mac fanboys may go about arguing that Windows and Linux are mere copy-cats and that they were the first to have Universal Binaries.

Re:The real difference: root vs. non-root

[Sigma 7]

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.

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.

Dual-boot infector?

[Ungrounded Lightning]

I'm not sure from TFA exactly what concept this thing is "proving".

But one I've been waiting for is a dual-boot virus or worm.

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.

Point is, a dual-boot system is only as secure as the weaker OS.

Re:Not to worry

[mrsbrisby]

Deleting everything in my home directory is anything but minimal.

Compared to deleting your entire system?

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'm editing and then drops privileges. Once the vi-wrapper exits, group-write permissions are removed.

The web browser runs as another user- so while I suppose a "virus" could knock out my bookmarks, I actually publish those over the network (so I can share them with my laptop).

My email client uses rsync to download my email. The client itself runs at a reduced privilege. Worst case scenario is that a malicious virus could delete the flags I put on messages so I might forget which ones I replied to (but only on the most recent ones- because I archive my email into files that have been chattr+i.

All in all, this system that I use is fairly immune to viruses. I'm sorry yours is not, but at least you have the ability to make it so on a Unixish system.

You simply don't on a Windows system.

Spam relays and DDOs botnets don't need root access, just the ability to send data over the network

No. They need to do something normal programs on my system do not. The only UDP traffic I generate is DNS traffic, so I suppose they could DOS my dnscache- it just happens to be running on the same machine. Using iptables is easy with owner-matching, and it protects against this very thing.

Meanwhile, my email is sent using serialmail. I'd notice immediately if when I went to send messages, there were an awful lot of them. Other people would to. Why don't you?

How about modifying your GNOME or KDE menu to point to a fake terminal entry or fake admin tools?

Regular users rarely install programs, and I never do. I don't give my run account the ability to modify my menus. It simply can't happen.

Windows lacks "setuid", so it makes my security measures impossible.

How do you know that the "gnome-terminal-emulator" you're now typing your password into (through sudo) isn't actually stealing it?

It's called a SAK. And I don't switch to a more privileged user without it.

A Marketing Campaign?

[debiansid]

t's important for enterprises to be aware of such issues and implement anti-virus tools for protecting non-Windows operating systems if they haven't done so already, Ullrich said.

So is that the real intention of the entire article? The original report is at viruslist.com, which is again a Kaspersky owned site. So take a guess...

Also, at the end of the story on SANS they have put up an update saying that the virus will have to run as r00t to be able to do any real damage. Kinda like most proof of concept virii developed for *nix in the past isn't it?

Re:POC = Piece Of Crap?

[urbanriot]

Alas, deltree is gone in XP.

I wish I knew what the new equivalent was. Right now I just use cygwin's rm -rf :\

rd . /s /q

Been around since NT.

Re:When one of these is seen in the wild ...

[Admiral Burrito]

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 except through the kernel. This restriction is enforced by the CPU itself. The kernel runs in ring 0, code within the process does not.

Links?

[spaceturtle]

Hi could you give the links to the technology you are using. I am very interested in this field (giving applications less rights than the user). I have not heard of SAKs before.

BTW, Have you heard of Plash or Systrace?

Unfortunately I don't think that many Linux systems are set up the way you describe, though I intend to make it my personal quest to make sure they are.

Also, have you come across a way of stopping GUI applications taking over other GUI application via the X protocol?

I know that it is possible to run X applications in untrusted mode, but I understand that is still possible for untrusted applications to snoop on other untrusted applications via X, so we cannot simply run all applications in untrusted mode.

Re:Not to worry

[shaitand]

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.

Re:Okay, So Here's The Linux "Threat " As I See It

[Junta]

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

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.