| |||||||||||||
Critical Linux security API is still a kludge (Inquirer)Critical Linux security API is still a kludge (Inquirer)Posted Oct 23, 2006 15:06 UTC (Mon) by nix (subscriber, #2304)In reply to: Critical Linux security API is still a kludge (Inquirer) by Gollum Parent article: Critical Linux security API is still a kludge (Inquirer)
The idea is that it checks *every* access to a given file, so single-process hacks like LD_PRELOAD aren't really good enough (e.g. what if something else needs a preloadable library? What about what it does to prelink?)
Doing it globally with /etc/ld.so.preload is possible, but using this deactivates prelink and thus generally kills performance (there's no point in fixing it, as /etc/ld.so.preload is very much a debugging hack only and *not* meant for production use).
Putting it in the kernel (perhaps in a stacked filesystem a-la unionfs, once that gets into the kernel) is probably a better idea.
(Log in to post comments)
Critical Linux security API is still a kludge (Inquirer) Posted Oct 23, 2006 15:19 UTC (Mon) by niner (subscriber, #26151) [Link] Checking every access to every file is a giantic waste of resources and the reason why Windows is so unbearably slow, as soon as an anti virus product is installed.
Why check a file 15 times, when it didn't change? Using knotify to only check files that are new or have changed seems to be a much better idea to me. Besides, nowadays checking websites and emails seems to be much more important than files on the hard disk.
Critical Linux security API is still a kludge (Inquirer) Posted Oct 23, 2006 15:38 UTC (Mon) by nix (subscriber, #2304) [Link] It also means that the things opening the files *block* until the dazuko-using application has gated access, which *at best* turns open() from a syscall requiring two ring transitions to one requiring four ring transitions and two context switches!
Doing this sort of thing using inotify is a total waste of time in the presence of network filesystems, SANs, and other filesystems that may be written by other than the local system.
But then this whole thing is a total waste of time anyway. Probably an LD_PRELOADed wrapper *is* the right thing: a wrapper wrapped specifically around WINE and those (very rare) other things that are actually at risk from Windows malware. Normally a clamav milter or something similar can do a better job anyway.
Critical Linux security API is still a kludge (Inquirer) Posted Oct 23, 2006 18:29 UTC (Mon) by bluefoxicy (guest, #25366) [Link] Actions like read() and mmap() can go through FUSE; and if you mmap() a file on a FUSE file system the kernel has to ask FUSE what to do with it. Once the filter extensions hit FUSE mainline (Miklos says they will), you'll be able to reliably determine when a file has changed.
For network file systems like NFS or SMB, you'll have to scan accessed data each time it's pulled over; but incremental scanning is possible. Picture scanning an executable that adds viral code to .text called by _main(). The relocation pages are pulled over, relocations are done, functions in .init are run, some of .text is pulled over, _main() is entered. Now _main() tries to execute virus in a page that hasn't yet been accessed. As that page is brought over, it is scanned for a virus, which is located; the system refuses to give that page to the application, and the application segfaults.
Of course the whole incremental scanning part is conjecture; a proof of concept implementation would be nice.
Critical Linux security API is still a kludge (Inquirer) Posted Oct 24, 2006 14:27 UTC (Tue) by arjan (subscriber, #36785) [Link] fuse doesn't do good enough mmap for virus scanners.fuse only gets to see the mmap page (when written to) at the final commit to the fs; but before that it has been in the VM for a LONG time, and visible to all other apps that have that file open. So the virus evil can already have taken place....
(and before you say "but the other app scans on open", at the time that app opened the file it may well not have been infected yet; many apps have .so files open as mmap for a really long time, weeks if not months)
Dakuzo doesn't work 100% Posted Oct 23, 2006 15:59 UTC (Mon) by arjan (subscriber, #36785) [Link] The problem is that IT DOESN'T check every access, but only some.
So not only is that approach they take a root-kit like kludge, it's not even nearly watertight. The don't (and fundamentally cannot) check reads and writes that are done via mmap() for example.
A fundamentally different technical solution is needed, and it probably is going to need changes all over the OS.
A few things that I think are needed:
Dakuzo doesn't work 100% Posted Oct 23, 2006 16:28 UTC (Mon) by nix (subscriber, #2304) [Link] Well, they *could* check mmap()ed reads, at least, by scanning the file on every open(). But, no, checking writes is out of the question in the presence of mmap() (imagine the expense! two context switches and some sort of expensive check on every write to an mmap()ed region? Gah.)
scanning on write Posted Oct 23, 2006 22:55 UTC (Mon) by skitching (subscriber, #36856) [Link] Is it really necessary to scan on each write operation? It seems to me that scanning on close would be sufficient.
If there are concerns about having to rescan a very large file which has had just a small piece modified then the monitoring layer (FUSE-based or other) could keep a list of modified blocks to be scanned on close. How about an in-kernel module that simply exposes a list of changed block ids which a user-mode module could then check on close?
Of course this is rather asymmetrical to the read scanning, which does need to be done as data is read in order to catch bad data on mounted filesystems such as NFS, so maybe it's not such a good idea..
scanning on write Posted Oct 24, 2006 16:14 UTC (Tue) by nix (subscriber, #2304) [Link] - program A mmap()s foo.so- nasty program B mmap()s foo.so and infects it - program A now sees the virus-infected pages and so is magically infected too
So yes, you have to scan on each write: at least on each write of a file opened by more than one process.
The Inq is wrong Posted Oct 24, 2006 4:39 UTC (Tue) by gdt (subscriber, #6284) [Link] SAMBA and NFS need a way of checking stuff before getting/sending it via the network. This may be able to use the previous thing, but maybe not. Samba already has the Virtual File System API that can be used for virus scanning (and multilevel storage and other neat stuff). See samba-vscan for an implementation of a virus scanner which uses VFS. Other applications which handle data on behalf of Windows systems have similar APIs. Sendmail's milter springs to mind. Milter is now in Postfix too, so we are seeking a common API emerge between the various mail transfer agents. The Inq's complaint is that a API vital to virus scanning files before they are seen by a Window's host is missing. But since Samba, sendmail and other software which passed data to Windows systems have such APIs, what's the beef? The article is a vendor whinge to a naive journalist dressed up with a page-hit-seeking headline.
Critical Linux security API is still a kludge (Inquirer) Posted Oct 24, 2006 11:53 UTC (Tue) by job (guest, #670) [Link] Why WOULD you want to check every file access? I would be surprised if Windows virus scanners this, it would be unbearably slow. What you probably want is to check all files treated as executable code, by hooking the exec call in libc.
Of course, evil code could relocate specific portions in data files, and by directly calling the kernel to execute them bypass the check. But this would be trivial by mmaping those parts in executable space anyway.
It's not very different in nature from self-encrypting code. I think the scanners need to treat them the same way, by checking for the decrypting/execing/mmaping code to begin with. The in-kernel hook described sounds like a flawed design no matter how you look at it, and I am not the least surprised it's difficult to convince the kernel devs to let it in.
Critical Linux security API is still a kludge (Inquirer) Posted Oct 24, 2006 16:19 UTC (Tue) by nix (subscriber, #2304) [Link] Hooking glibc's exec() wouldn't help for infected shared objects (likely to be a common target in any case, at least if viruses were actually a problem, which of course they aren't: infect one shared library and *bang* you've just got N executables too).
And of course shared libraries are mmap()ed in by ld.so (well, so is the executable, but you can tell what that's called statically: finding out the total set of shared libraries a program will use is impossible in the general case because of dlopen(), and indeed anything reimplementing dlopen() itself via mmap(), or via open() and read() into a prepared mmap()ed area.)
It has many of the same fundamental flaws as does digsig: it'll stop everyone but the determined attackers it's most useful to stop. (I'd like digsig to work as well but unfortunately it's one of those tools that only works until a single malware author works around it).
|
|||||||||||||