LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices


Reply
  Search this Thread
Old 03-20-2005, 05:30 AM   #1
penguinlnx
Member
 
Registered: Mar 2005
Location: Ice Station Alert AFB
Distribution: Gentoo
Posts: 166

Rep: Reputation: 30
IM vulnerability for Message services in Linux(?)


12 IM Viruses in 30 Days

70% of IM attacks targeted the MSN Messenger, Windows Messenger, and MSN Network,
and 18% targeted the Yahoo! Messenger and Yahoo! Messenger network.

Kelvir, Bropia and Bizex worms were reported as the top 3 IM infections in corporate environments.

"IM viruses and worms are growing exponentially," said IMlogic's Jon Sakoda.
"Virus writers are now shifting the focus of their attack to instant messaging,
which is seen as a largely unprotected channel in..."
--------
My problem is, some of my local users on my Linux system will be using
Messenger Services like MSN and Yahoo for live chatting etc.
(kids have to yak to all their friends who don't use Linux...)

What danger is there, and what can I do about it?
 
Old 03-20-2005, 06:14 AM   #2
TigerOC
Senior Member
 
Registered: Jan 2003
Location: Devon, UK
Distribution: Debian Etc/kernel 2.6.18-4K7
Posts: 2,380

Rep: Reputation: 49
There is no danger to your Linux based systems but the theat is there to any M$ based system.
 
Old 03-20-2005, 06:21 AM   #3
penguinlnx
Member
 
Registered: Mar 2005
Location: Ice Station Alert AFB
Distribution: Gentoo
Posts: 166

Original Poster
Rep: Reputation: 30
How can there be no danger?

I don't understand: if someone can get code onto an x86 and execute it through an IM,
how can the fact the operating system is Linux help?
Presumably if the code is destructive,
it doesn't have to know or care about system calls, or what operating system is running -
only likely to be present hardware components and their vulnerabilities...
 
Old 03-20-2005, 06:44 AM   #4
TigerOC
Senior Member
 
Registered: Jan 2003
Location: Devon, UK
Distribution: Debian Etc/kernel 2.6.18-4K7
Posts: 2,380

Rep: Reputation: 49
The executable files are *.exe files intended for w32 systems. e.g.

W32/Kelvir.worm.
The website used by this virus has been shutdown, therefore this threat no longer poses a risk.

This worm spreads via MSN Messenger. The worm, sends the following message to Contact List recipients:

haha look at us~http:// {blocked}.net/youandme.pif
note: the actual address has been blocked here to prevent infection.

Following the hyperlink in the email messages may result in the worm file being downloaded and subsequently executed by the user.

The .pif file is an archive containing 2 files:

* f.exe (62,727 bytes) a new W32/Sdbot.worm variant
* LINK.EXE (5,738 bytes) the main IM worm component

W32.Kelvir.D (Symantec)

An *.exe does not have executable permissions in linux. Here is where Linux is so different - even if the file were executable in Linux the user would hopefully be running in a user shell (that's why you NEVER surf as root) and if they tried to execute the executable it would be refused because they do not have root permissions to alter the base system.

Last edited by TigerOC; 03-20-2005 at 06:48 AM.
 
Old 03-20-2005, 08:47 AM   #5
penguinlnx
Member
 
Registered: Mar 2005
Location: Ice Station Alert AFB
Distribution: Gentoo
Posts: 166

Original Poster
Rep: Reputation: 30
One door closed, one door open?

okay, so if the malware penetrated the system by whatever method,
if part of the cycle or process involved saving the file onto a hard drive
and re-loading it, I can understand how the operating system becomes involved.
But what about viruses that rely on far simpler (and deadlier) methods?

What about a virus that exploits some buffer over-run or pointer error,
perhaps as yet unknown in the Linux operating system...
Okay this piece of code is still in RAM where it was placed upon penetration:
Now a code execution pointer hits it and begins executing the x86 instructions.
Not only is the virus now in control of the machine, but it can effectively ignore
the operating system entirely, (which makes it far simpler), and concentrate on
hardware-based attacks.

I'm not saying there *is* such a weakness in a Linux-based system running MS or Yahoo Messenger...
 
Old 03-20-2005, 12:11 PM   #6
TigerOC
Senior Member
 
Registered: Jan 2003
Location: Devon, UK
Distribution: Debian Etc/kernel 2.6.18-4K7
Posts: 2,380

Rep: Reputation: 49
I am not sure I understand what you are getting at. Sounds like you may not be totally familiar with how a computer is controlled. Think of the computer being controlled in layers. The base control lies in the bios (basic input/output system). There are viruses out there that can infect the bios but are quite rare. This layer is responsible for the physical allocation of devices and channels through which data flows. The next layer is the os. In order for anything to happen the software has to give the instructions. These are completed via executable files.
In order for a virus to take control it has to be enabled through a user action i.e. allowing the executable to be installed. In the case of M$ the user generally has root permissions and is therefore easily able to install applications that change the os. In linux users do not have root permissions and therefore it is not possible to do this. It is possble for the same thing to happen in a Linux environment but a lot more difficult.

Last edited by TigerOC; 03-20-2005 at 12:13 PM.
 
Old 03-20-2005, 02:43 PM   #7
2damncommon
Senior Member
 
Registered: Feb 2003
Location: Calif, USA
Distribution: PCLINUXOS
Posts: 2,918

Rep: Reputation: 103Reputation: 103
Quote:
What about a virus that exploits some buffer over-run or pointer error,
perhaps as yet unknown in the Linux operating system...
A Linux vulnerability would be addressed with a security update. There are such things and that is why you should stay up on your security updates.
What TigerOC is saying is that the specific things you are asking about are Windows vulnerabilities that do not work on Linux.
Each particular exploit or virus needs to be considerd in context to it's real abilities to get a clear picture.
 
Old 03-20-2005, 03:51 PM   #8
jiml8
Senior Member
 
Registered: Sep 2003
Posts: 3,171

Rep: Reputation: 116Reputation: 116
Quote:
What about a virus that exploits some buffer over-run or pointer error, perhaps as yet unknown in the Linux operating system...
Okay this piece of code is still in RAM where it was placed upon penetration:
Now a code execution pointer hits it and begins executing the x86 instructions.
Not only is the virus now in control of the machine, but it can effectively ignore
the operating system entirely, (which makes it far simpler), and concentrate on
hardware-based attacks.
Ummmm...no.

Stipulating a vulnerability that lets the virus get in and get loaded, that virus will still only run within the framework of the OS and with the user rights. It will totally lack capability to kick the OS out - which is what you are postulating here. It will get the processor because the OS gives it the processor, but it will lose the processor when the OS says so, and the memory manager will keep it from taking those actions which would tend to kick the OS out. The ony way a virus or other malware could kick the OS out would be to get control of the system before the OS was loaded.

Now, this is possible. But when it happens, it is rather obvious.

A properly secured Linux box (and virtually all of them are properly - or at least adequately secured) is nearly invulnerable to an IM attack.

For that matter, a properly secured Windows box would also be nearly invulnerable. Too bad that Windows systems by default are insecure and provide positive incentives to users to log in as administrators.

Last edited by jiml8; 03-20-2005 at 03:52 PM.
 
Old 03-20-2005, 08:51 PM   #9
penguinlnx
Member
 
Registered: Mar 2005
Location: Ice Station Alert AFB
Distribution: Gentoo
Posts: 166

Original Poster
Rep: Reputation: 30
"I haven't spoken in 18 years..." (Life of Brian)

This seems so important, that I'm going to spend a bit more time on it, even if I make a fool of myself (again):

Quote: "Sounds like you may not be totally familiar with how a computer is controlled."

This is precisely true. So I'll preface everything with this acknowledgement, and still ask some more questions and offer a few points:

Layers: Programs on disk/Net <--> Hardware <--> BIOS <--> OS <--> PROGRAMS in RAM

This may be the norm: program in RAM must go thru OS to BIOS to Hardware to Disk/Internet.

But as an 80's programmer I have to doubt the analogy of resistors in series controlling flow.

We constantly and thoughtlessly cut corners all the time, bypassing BIOS and OS to gain speed, efficiency, or control of hardware; THAT was the real 'norm'. And we weren't writing malware or spyware, just competing commercially. The bad boys were far more insane and clever. more like a leaky circuit shorting itself out than 'isolating' layers.

It began with TSRs, and we were just beginning to understand the power of 'interrupt driven' machines and non-sequential 'user-driven'programs. But we were tricking compilers, resetting stacks, swapping and de-encrypting code, embedding it in data, hiding it in shadow-RAM and extra video RAM, rewriting jump-tables etc. intercepting and faking user input etc. And even OVERWRITING the OS, reverse-engineering BIOS calls, and snapping INTEL chips in and out of 'REAL MODE' and PROTECTED MODE', and writing to DISK behind everyone's back for copy-protection, while putting onboard-control chips into modes that weren't even listed or thought of, let alone documented by Intel etc. I personally conned the 'Hercules'(BW) card into giving twice the resolution of an Apple! And we were the 'good guys'!

Of course the sophistication of 'real' vs. 'virtual' address modes has vastly improved since those days. But the 'bad guys' have been there all along, developing their tricks right alongside Intel, IBM, Microsoft, and UNIX too.

quote: "even if the file were executable in Linux the user would hopefully be running in a user shell"

This is no different than (or better than) Intel chips on IBM PCs running in 'protected modes' allocating hard RAM areas to 'virtual' machines. Not only should the HARDWARE version of such schemes be better (bulletproof!) because they aren't corruptible temporary programs in RAM, they shouldn't even be visible or detectable to the OS, which should have no knowledge of them and imagine it's virtual machine is real.

But the Achille's heel of all these schemes is that *somebody* has to know about it and manage it, and stupidly, this is always assigned to the OS (and the client/user)! Does assigning the job to Linux fix this? No: its a fatal, market-driven design decision.

Unless the OS is burned onto ROM chips, it is vulnerable to manipulation, alteration and damage. This natural vulnerability is a hardware problem, not solved by OS design: If INTEL and IBM couldn't bulletproof their machines in hardware even after spending billions in development, because critical DESIGN decisions were made to meet market 'needs', Linux cannot be expected to become a 'magic bullet' that everyone overlooked.

Linux on a SUNN system or a mainframe may indeed be 'bulletproof' because these hardware configurations don't have or aren't affected by those design flaws, but an IBM-PC with Linux is still an IBM-PC, and even Linux can't make a silk-purse out of sow's ear.
(Linux can't be blamed for microcomputer vulnerabilities, but nor can it fix them.)

The typical PC has hundreds of other HARDWARE vulnerabilities, which may not allow 'hostile takovers', but DO allow viscious destructive attacks. That's a point: if an attacker just wants to destroy, there is no defence. Try stopping a guy with a bomb and a dead-man switch.

Quote: "There are viruses out there that can infect the BIOS but (they) are quite rare."

"rare" is a relative term. And clinical experience deviates WIDELY from the 'norm'.
For instance I have at least 5 friends who have had their motherboard BIOS 'FLASHED' by hostile malware. Sophisticated hackers? hardly! Every motherboard manufacturer pretty much only makes motherboards that have 'FLASHABLE' EPROM 'ROM's nowadays, and on their websites you can download hundreds of "FLASHWARE" programs that update your BIOS. Any idiot can modify one of these to trash a BIOS and upload it via an internet backdoor. Most users don't even bother to figure out what happened, but assume the motherboard just died and buy a new one.

There's an easy fix: NON-Flashable ROMS, but board-makers won't cooperate.

Why isn't there a lot of talk about this? Same reason people don't talk about being framed when they've given their credit card to a porn site. They often know exactly how it happened.
In case there's anybody stupid enough not to know this, many 'porn' sites (i.e. kiddy porn links) and other 'red flag' fake sites, like Communist Newsboards and Chemical Supply companies, are just fronts run by the cops. What a surprise: entrapment? no stupidity.
And the cops regularly use 'FLASH' programs to trap morons, and plant evidence on their machines. Often these days, the 'FLASH'attacks are not overtly malicious, simply replacing your BIOS with only minor and virtually undetectable changes, such as removing or changing your password to prevent you altering your machine, and writing I.D.codes that show you've visited a "staked-out" porn site or 'terrorist' leaning political post. Don't expect big discussions on the ethics of these methods on security sites. Everybody knows about it and nobody in law enforcement is going to blow the whistle about the rights of a kiddy porn dealer.
When a motherboard is only $100, most criminals just think of it as the cost of doing business.
Here the point is simple: Whether deliberately, or just by being dumb, I can get my BIOS flashed in about a half-hour by cruising illegal porn sites on the Net. Rare? no. W

Quote: "This (BIOS)layer is responsible for the devices and data channels..."

Only if the OS and running programs remain well-behaved. The code in the BIOS is the same machine code found in RAM and elsewhere, and the processor does not check where the code came from that it finds in its queue. If you know x86 assembly language you can talk to the hardware peripherals without the BIOS, just like the BIOS does it without you.

Quote: "In the case of M$ the user generally has root permissions and is therefore able to install applications that change the OS. In linux users do not have root permissions. "

Again I have to doubt: permissions may work if everyone is honest, like 'private property' signs. An OS may typically stop unauthorized commands if it recognizes them. Sorry, you don't have permission to FORMAT C: , please ask an adminstrator for assistance." Almost all users have permission to execute SOME program, and if a program is named 'LS', an OS isn't normally going to scan it to see if it is really a modified 'FDISK'. If the virus has gotten far enough to have itself stored as a file on the system, it surely would also be wearing a benign disguise effective enough to get past that kind of OS security and get executed eventually.

But if the OS is relying on HARDWARE to control and monitor illegal memory access or device manipulation, then it faces the same problem as MS Windows. It may be that Linux has found a way to use the 'VIRTUAL MACHINE/PROTECTED MODE' features of an IBM-PC better than Intel, IBM, and Microsoft combined: If that were true we could blame 'programming by commitee' or 'design by market forces' as the cause, and show that Linux was designed to directly address this flaw and successfully solved it by avoiding the key design decisions made by Bill Gates' crew.

But we find here that apologists are (mistakenly?) admitting the same key design flaw exists in Linux: The OS is AWARE of and in control of the 'VIRTUAL MACHINE' technology, which should be completely inaccessible by choice of the OS designers. It seems it *must* have access to the VIRTUAL MACHINE/PROTECTED MODE technology because it GIVES this access to the ROOT. (or else it simply ignores it and hands over the keys!)

And there is some inkling of this hidden flaw in the far more sobering and realistic comments which I quote next: (again from previous replies)

Quote: "A Linux vulnerability would be addressed with a security update."
(not preemptively stopped by the current design of Linux.)

Quote: "...It is possble in a Linux environment but a lot more difficult."
(difficulty is like rarity. Who cares how difficult it was, once it happens?)

Quote: "..that's why you NEVER surf as root"
(If Linux could stop a virus once it is in RAM and running, this wouldn't be a problem! You could surf as ROOT all you wanted. But if Linux IS vulnerable at that point, this is hopelessly inadequate! All this can do it seems is stop script kiddies from executing standard commands if they log on. But the danger isn't in failing to prevent remote control, its in malicious destruction.)

CAN you stop a virus from malicious damage, once it's in RAM and running? Let's think for a minute about how you might do that:

(1) Scan memory for signatures or malicious/suspicious instructions? Worthless strategy:
a) The virus need not show its dangerous code until it executes it byte by byte.
b) You can't have a 'signature' to find until you've caught samples, any more than you can make a vaccine without germs.

(2) Step-execute every command and actively analyze what the program is going to do, one machine-code instruction before it does it:
a) what do you look for?
b) how deep do you analyze?
c) how slow do you want the machine to run?

(3) Lock up all hardware as inaccessible (default) until the OS 'metasystem' needs it.
a) perhaps there's hope there.

(4) The obvious:

a) change the design of the Operating System to be unaware of the hardware 'virtual machine/protected mode' aspects of the machine. You can't turn on a switch that doesn't exist.

b) Have a complete hardware 'firewall' that prevents direct access to hardware all the time.
and prevent all hardware from being detected by the OS or the Software. A kind of a Super-GL cross-platform I/O.

...just a thought, and a few questions. Hasn't this been done before?
 
Old 03-20-2005, 09:46 PM   #10
frob23
Senior Member
 
Registered: Jan 2004
Location: Roughly 29.467N / 81.206W
Distribution: OpenBSD, Debian, FreeBSD
Posts: 1,450

Rep: Reputation: 48
First, direct hardware access is only permitted by the kernel and its associated device drivers and loaded modules. To the best of my knowledge it is not possible to bypass these restrictions and, if a way was found it would be closed ASAP. This is one reason writing a highly opitmized program is difficult on *nix based systems. You don't even have direct access to memory (outside the segments allocated to you by an OS call).

Claiming arbitrary x86 code could just ignore the kernel and start doing stuff is just wrong. Disk interrupts, screen ints, even keyboard ints, are all trapped by the operating system and can't be bypassed.

In fact, the actual problem comes in the exact opposite direction you are thinking of. Instead of making it ignore the OS you must write a worm which it intimately linked to the OS and a vulnerability in it. Let's say gaim, or whatever IM client being used, has a buffer overflow that the attacker finds.

Well, he can write a very carefully crafted program to exploit that overflow and start running his own program as the user on the system. At this point he can either just hurt the user's stuff or try for privilage escalation. If he also knows of a local root exploit against the version of the linux kernel which is running, the program can execute that. Now it is running with root access. It STILL has to use the system calls to do any damage except know it most likely has the rights to do that.

Ignoring the OS is likely to cause a segmentation fault or some other access violation which will kill the program and leave a core dump. Which is pretty useless for an attacker.

In short, the vecter of vulnerability is a lot smaller than you want to make it out to be. It requires a usable way to cause the client to execute code, an unpatched local root exploit, and careful attention to detail so as to avoid core-dumping the program.

This is to say it is POSSIBLE. But not likely at all. It is far too much work when you can execute arbitrary code as an admin on a Windows system with barely any effort at all.

EDIT:
Quote:
(3) Lock up all hardware as inaccessible (default) until the OS 'metasystem' needs it.
Uhm.. yes... this is how *nix works. No hardware access except through the OS. Actually, if you want to see levels upon levels of indirection you need to look at disk access code. It is wonderful. It is so abstract that the [lowest level] code in a program doesn't even need to know anything about the disk it is writing... it could be a CD, ffs, ext2, minixfs, nfs 100 miles away, or whatever. There are three or four layers of abstraction. It is long since the days when a library of functions needed to know how to handle inodes.

Last edited by frob23; 03-20-2005 at 09:54 PM.
 
Old 03-20-2005, 11:26 PM   #11
penguinlnx
Member
 
Registered: Mar 2005
Location: Ice Station Alert AFB
Distribution: Gentoo
Posts: 166

Original Poster
Rep: Reputation: 30
Its all true...but only part of the time.

Yes, what you are saying is all true....on a new machine.

But there are probably millions of machines out there reaching all the way back to IBM 286.s, and a hell of a lot of these older "obselete" machines, (too slow and too small for modern MS windows) have been recycled with you guessed it...Linux.

The kind of hardware protection you are describing is only applicable when the kernel is running on a modern machine, which JUST LIKE THE OS, must be updated with the latest hardware 'patches' to avoid being exploited. There are plenty of machines out there with plenty of vulnerabilities.

It is a huge mistake and a very misleading picture to ONLY talk about the Linux software itself and its reliability. The software is only as reliable as the hardware it runs on: a chain is only as strong as its weakest link.

Finally, let me give you a scenario, which is not a 'prediction', but a virtual certainty at least for the windows case first:

(1) 17 year old computer hacker grabs a copy of the latest Windows net-virus/spyware for uploading worms and trojans. All he has to do is use his own machine for bait and a few hacking tools to make it use his files and IP etc.

(2) then he downloads a half-dozen Flash-BIOS updaters from the net, conveniently provided by the motherboard companies, and hacks them with his cute 'signature' and a couple of virus bombs.

(3) Then he downloads a copy of GRCs Low Level HardDrive recovery program. And he hacks that to fry every drive connected to an IDE cable.

(4) He and his friends set up not a DDoS, but a DoVE: Distributed act of Vandalism Extreme:
20,000 motherboards have their critical business and personal files erased from their hard drives, and their BIOS's flamed out, creating a huge paperweight on each desk.

(5) A year later some clever clown finds a way to do it under Linux.

What makes Linux a good operating system isn't invulnerability, but a dedicated community of brilliant programmers who honestly want to maintain and fix the system when (not if) it breaks. If that community splinters or becomes infected with a Microsoft money virus, then Linux would become worth about as much as Windows.
 
Old 03-20-2005, 11:35 PM   #12
frob23
Senior Member
 
Registered: Jan 2004
Location: Roughly 29.467N / 81.206W
Distribution: OpenBSD, Debian, FreeBSD
Posts: 1,450

Rep: Reputation: 48
Linux does not run on a 286. Never has... you would need to get Minix or Xenix to run on one of those machines.

And, in both those cases... how the hell are your users running a windowing system and a modern IM client?
 
Old 03-20-2005, 11:39 PM   #13
frob23
Senior Member
 
Registered: Jan 2004
Location: Roughly 29.467N / 81.206W
Distribution: OpenBSD, Debian, FreeBSD
Posts: 1,450

Rep: Reputation: 48
Your scenario is fairly far-fetched. It assumes a lot and doesn't express an understanding of the weaknesses in the *nix system. Rather you base it around "assumed" brilliant programmers figuring out how to do something like they would do it in Windows.

Edit:
Quote:
(5) A year later some clever clown finds a way to do it under Linux.
This is the only point where you even start to talk about linux (the rest is words wasted on windows problems). If you could explain how this would work on Linux it would be great. There is a reason that flashing your BIOS has to be done from a FreeDOS disk and not from in Linux (BTW).

Last edited by frob23; 03-20-2005 at 11:43 PM.
 
Old 03-20-2005, 11:43 PM   #14
penguinlnx
Member
 
Registered: Mar 2005
Location: Ice Station Alert AFB
Distribution: Gentoo
Posts: 166

Original Poster
Rep: Reputation: 30
How do I crack thee? ...Let me count the ways....

For every method and delivery system you and I can think of,
there are ten more easily as effective that we haven't thought of.
 
Old 03-20-2005, 11:47 PM   #15
frob23
Senior Member
 
Registered: Jan 2004
Location: Roughly 29.467N / 81.206W
Distribution: OpenBSD, Debian, FreeBSD
Posts: 1,450

Rep: Reputation: 48
What the hell are you muttering about? Are we discussing your topic (viruses through IMs) or trying to spread FUD about the security of Linux?

Make a clear, coherent, and informed point about a weakness in Linux -- such as the one I pointed out in my own posts here -- and we can talk about it. But you are making sweeping statements which don't even apply.

Your statements are like, "What if one day they make a biological agent which can travel through powerlines and eat your hard-drive... linux couldn't protect against that!!!"
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
POSIX message queues(Solaris) to SYS V message queues(Linux) devershetty Programming 1 01-22-2007 10:15 AM
Linux Kernel Vulnerability jeremy Linux - Security 2 03-15-2005 02:03 AM
Linux Services Ameii83 Linux - Software 7 12-24-2004 03:12 AM
Linux vs Mac question (Virus vulnerability related) unixfreak Linux - Security 14 08-29-2004 06:05 AM
TightVNC Ver terminal Services.. also looking for terminal Services for linux 2782d4 Linux - Security 3 05-20-2004 02:30 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 02:34 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration