[plug] Bugbear/B (Kai/Ben)

Craig Ringer craig at postnewspapers.com.au
Wed Jun 11 02:14:31 WST 2003


>>One thing to consider that if Linux became the dominant desktop
>>operating system, do you think there wouldn't be any viruses roaming
>>around?  Hell yes there would be.
> 
> The fly in this ointment is that Linux email programs don't run 
> executables.

Well, they're not /known/ to do so. Anyway, as I pointed out, its not 
hard to trick some people into running a virus/trojan. After all, if 
they can be convinced to delete stuff out of c:\windows\system32 , how 
hard could "sh funpix.sh" really be? Or for that matter,
	su -
	sh /tmp/funpix.sh
*shudder*

 > KMail? Evolution? Mozilla?
> Pine?

... mutt, sylpheed, MH, exmh, mailx ... All of them. You'd have to 
target one for a mass-mailing worm, but just because they're the biggest 
and most annoying type of malware doesn't mean they're the only 
important kind. A normal trojan can still scan your mail spools (just 
check for all the common locations, grepping for email addrs or parsing 
mbox, MH and Maildir), mail itsself off to everybody it finds 
(/usr/lib/sendmail or built-in SMTP), then start misbehaving. It could 
trash files, do an infinite loop to load the CPU, fill up your /home/ 
partition's free space with a huge dotfile to break all sorts of things, 
etc.

> The same flaw isn't going to exist in all of them, and the code 
> for every new version is going to live at different addresses, so your 
> "market" is going to be, at best, a very small fraction of the Outlook 
> virus-du-jour playground.

For a buffer-overrun exploit against a mail client to do a mass-mailing 
worm, yes. Then again, it's quite possible that we'll be seeing KHTML 
and gecko based HTML mail viewers, which provides possible 
multiple-mail-client targets. More importantly, the hole need not be a 
buffer overrun - it could be an auto-execute hole (OE HTML exploit 
style) to trick the mail client into running an attachment.

Also, a virus need not be mass-mailing to be destructive. Look at the 
Anna Kournikova virus, or Snow White. There are many more "user 
stupidity exploits" out there. Of course, here stupidity = uninformed | 
unthinking | naive | unwary | poorly computer literate, as well as plain 
'ol stoopid.

>>But there would still be viruses being released,
>>except they'd probably work by social engineering to get people to
>>run them. Same as that "jdbgmgr.exe" hoax that went around, totally
>>reliant on social engineering, it was pretty effective.

> Would it be so effective if by default the user had no write access on 
> the file in question? 

Not really, no :-)

It'll be hard to convince someone to delete their mail spool or a 
dotfile named after a program (.mozilla, etc) ... though far from 
impossible. "The .mozilla folder contains a virus that's infected your 
email! Get rid of it before it spreads!" .

OTOH, I expect it wouldn't be too hard to convince people to become root 
before trashing their system. A home user will, after all, have their 
root password. Education is the only real solution, and for education to 
work fully the person needs to be interested in more than "how do I do 
X". That matches only a minority of computer users, alas.

The main difference to my mind is that a virus can't easily infect 
programs or attack other user's accounts, not unless the user can be 
convinced to run it as root. I suspect it should be possible to get 
though to most (but far from all) users "NEVER EVER EVER run a program 
you got over email as root. EVER. Even if its from your tech friend or 
your distro company."

Alas, preventing them from following "virus warning" instructions could 
be much harder.

> I routinely set up my systems so important files live on a readonly 
> partition (and in extreme cases also chattr them +i and rename the 
> chattr program). How is social engineering going to cope with stuff 
> like that?

Defaults. The distros don't set it up that way, and again - it won't 
protect the users' data.

Craig Ringer



More information about the plug mailing list