Ambidextrous Linux/Windows Virus 361
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."
Whatever (Score:5, Insightful)
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 (Score:3, Insightful)
Re:Whatever (Score:1, Insightful)
Reactions: (Score:5, Insightful)
Limited to ASM? (Score:3, Insightful)
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 [elephantessays.com]
Wrong and right. (Score:3, Insightful)
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:Does this mean.... (Score:4, Insightful)
Amazing! (Score:1, Insightful)
Writing viruses for Linux is EASY. Getting them.. (Score:3, Insightful)
How to write a Linux virus.
http://virus.enemy.org/virus-writing-HOWTO/_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/701
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:which architectures? (Score:4, Insightful)
Re:Not to worry (Score:5, Insightful)
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.
How About a Story? (Score:3, Insightful)
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 (Score:4, Insightful)
Re:Not to worry (Score:1, Insightful)
Actually, you're quite wrong.
Actually, he is not.
The design of Linux is simply much better when it comes to security. If (when) a vulnerability is discovered in Linux, the inherent design of Linux usually limits what an exploit can do. Key among all of these is that very, very few things require escalation to system priviliges to work. Most things run in user mode and are fenced off from critical system resources by that very fact. In general, without root access, whatever damage may be done is less than that possible with a Windows exploit.
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.
and the reason it is only a "safer" operating mode? Because so many silly things are wrapped into the OS that even user mode programs need to escalate to system priviliges to do the simplest things. There are a thousand places where you know that an exploit in that area will automatically give you system priviliges! By design, Windows is less secure. Microsoft is making strides (baby steps?) in this area now, but they are discussing and dealing with things that *nix designers dealt with 20 years ago.
I keep hearing the assertion that Linux is just as vulnerable as Windows in regards to viruses. By design, this simply is not true!
Is this another do-it-yourself? (Score:5, Insightful)
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.
More Linux advantages...; protecting low value (Score:5, Insightful)
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!
So do cars, toasters, appliances, and pretty much every item. Welcome to the age where quality means nothing.
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.
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:How is it POC? (Score:3, Insightful)
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? (Score:3, Insightful)
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.
It's hard to lose your files in home too (Score:3, Insightful)
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.
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.Re:Not to worry (Score:1, Insightful)
I believe you are slapping the parent while what he says is true. Let's take this one by one:
Deleting everything in my home directory is anything but minimal. Granted. While even on Windows systems this is not normally what they will do, it is a bad possibility. Potentially exploting local privilage elevation exploits to get root is anything but minimal.
True. What vulnerability though? Will it exploit something common on all linux systems, or something a percent of linux users will have on their systems. This is one way damage is minimized.
Infecting software after it has been compiled is anything but minimal.
It can infect only the software the user has write privilages to, ruling out most system apps like the terminal you mention later on.
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.
This is true. But there is no protection from this on any single user system where the admin is generally dumb. On a multiuser system, only the computer literate person knows the superuser password. Damage again minimized in this case. Same with windows, but using windows as a multiuser system is a PITA most times. Hopefully Vista will fix this.
Guess what? You can run as a non-root user in Windows, too.
But it is built to run as a 'root' user by default, making it a sitting duck. Hopefully Vista will fix this 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.
True.
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?
Altering the actual binary is not a question as pointed out above, unless it has found a way to escalate to root already, in which case this step you are describing is not needed. The case of a fake terminal is odd. Which terminal is it gonna emulate? Aterm? Rxvt? Xterm? XFTerm4? Why specifically gnome-terminal-emulator? This is going to ring alot of bells for someone not using gnome-terminal. Compare that to a windows virus that would only need to emulate a DOS Prompt. Again, damage minimized.
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.
You are right, they are smart, they are evil, but linux is not the easy target windows is. First the better multiuser design and the philosophy in designing applications and secondly the diversity of linux systems. There is no way someone can design a winner-takes-all piece of malware for this platform easily, unless a serious hole is found on a critical part of the system. In which case you then have the fast patching of OS that will minimize the lifespan of such a threat even further. Summing it up: You are right that no system is invulnerable to malware, but I think parent is also right that linux 'makes their impact minimal'...
Dual-boot infector? (Score:3, Insightful)
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 (Score:3, Insightful)
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? (Score:2, Insightful)
So is that the real intention of the entire article? The original report is at viruslist.com [viruslist.com], which is again a Kaspersky owned site. So take a guess...
Also, at the end of the story on SANS [sans.org] 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:When one of these is seen in the wild ... (Score:3, Insightful)
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 [wikipedia.org], code within the process does not.