Enumerating badness [LWN.net]

Enumerating badness

Posted Aug 6, 2008 22:53 UTC (Wed) by ctpm (guest, #35884)
In reply to: Enumerating badness by boog
Parent article: The TALPA molehill

   "Scanning for exploits is always going to be a lost cause - viz 
windows security and the ineffectiveness of the whole anti-malware 
industry."

 Well, its effectiveness doesn't matter really. What matters is that it 
makes money. Lots of it. And the truth is that 99% of the World is just 
gullible and insists on thinking that security holes are handled by 
scanning for viruses/malware and not by patching holes.

 You may even call it a conspiracy theory, but the fact is that there is 
a many-billion dollar industry behind AV/Malware scanning that probably 
feels that its core business is threatened by the emergence of 
alternative free and open systems. These people have no interest on 
secure operating systems, since those represent a major loss of revenue.

 The way I see it, those patches the article talks about (which seem 
rather more like a solution in search of a problem), may be just the 
effects of the AV industry lobbying some Linux vendors just to try to 
convince end users that they need to pay for AV/Malware scanning, just 
like Windows users, so that money keeps flowing...

to post comments

Enumerating badness

Posted Aug 6, 2008 23:14 UTC (Wed) by rahvin (guest, #16953) [Link] (4 responses)

Not as concise as I would put it so I will summarize. 

They want to sell Anti-virus to Linux Users AND (more importantly) to Linux Servers that
handle Windows traffic. 

It's easy with windows, they can sell their AV solution for the server, and a separate more
expensive server package that scans the hosts and traffic across the file server. Right now on
Linux all of this is being handled in user space with free open source programs that scan
specific server traffic like email of SMB traffic. 

With the right kernel hooks they would have something they could create a product on and throw
their marketing weight behind. Without the hooks they are up against the question of "how is
this better the clamd?" With the hooks they can create a very invasive AV package, much like
the windows versions that hooks itself deep into the kernel, hurting performance with
negligible benefit but with the ability to claim that their package scans at the Kernel level
every file that passes through the Linux system. This would make it possible to sell Norton /
McAfee AV for Linux, and Norton / McAfee AV for Linux SMB. Without the hooks everyone can see
the negligible value, with the hooks it becomes much harder to compare because I think
everyone can admit there might be some situation where the Kernel Level hooks could grab
something the user space tool wouldn't be able to.

Enumerating badness

Posted Aug 7, 2008 7:30 UTC (Thu) by wblew (subscriber, #39088) [Link] (2 responses)

Very insightful.... here is one additional thought: How about, once those hooks exist, that
they be used by the next release of clamd? Those vendors are again screwed....

Here is those vendors' real problem: with open source operating systems, the vulnerabilities
get patched because any user *CAN DO THAT*.

Enumerating badness

Posted Aug 7, 2008 8:45 UTC (Thu) by dan_a (guest, #5325) [Link]

Users can do that, but often don't - or don't until it's too late.  It would be good to have
an extra layer of protection against problems.  In my experience on Linux though this is far
more likely to be exploiting vulnerable web scripts than Windows style viruses, and so TALPA
and a virus scanner may not be the solution.

Viruses do not depend on vulnerabilities

Posted Aug 7, 2008 9:26 UTC (Thu) by epa (subscriber, #39769) [Link]

The traditional 'computer virus' does not depend on exploiting kernel or userspace
vulnerabilities to get more privileges.  It just attaches itself to every executable it can
write (and on Unix, I suppose, it might add itself to shell scripts).  So patching is not a
way to avoid viruses.  Not running untrusted code is a way to avoid them, but can any of us
here honestly claim that we audit all source code before typing 'make install'?  Or verify PGP
signatures on the tarball?  Wouldn't non-technical users download and install the Flash plugin
or Nvidia drivers without a second thought?

Enumerating badness

Posted Aug 7, 2008 16:14 UTC (Thu) by iabervon (subscriber, #722) [Link]

Of course, Linux servers that handle Windows traffic handle it in userspace as bulk data. They
need hooks into Samba, not the kernel. I'm not even completely certain that you can't do a
client-to-client transfer with Samba without Samba ever calling open(), if one client is
reading while another client writes. And there's no particular reason to think that a server
on Linux would store the content as recognizable files in its filesystem which it opens again
before serving them.

This sort of hook only makes any sense at all for protecting the local system, where the
kernel-provided filesystem is what programs use directly, and it seems unlikely, to me at
least, that bulk filesystem scanning will find a non-trivial portion of threats to a Linux
system.

Enumerating badness

Posted Aug 7, 2008 10:23 UTC (Thu) by nix (subscriber, #2304) [Link]

As I understand it, these are more the effect of RH asking the vendors to please define a
consistent interface so they can use an interface that's already there, instead of using
appalling hooks deep into the kernel from binary-only modules (overwriting things in the
sys_call_table, finding file_operations structures and overwriting their pointers, that sort
of thing). Even a nasty kernel interface is better than *that*.