linux-kernel - Re: [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforon access scanning

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 18 Aug 2008 11:54:18 +0100
From:	douglas.leeder@...hos.com
To:	"Peter Dolding" <oiaohm@...il.com>
Cc:	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	malware-list@...ts.printk.net
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforon	access
 scanning

malware-list-bounces@...sg.printk.net wrote on 2008-08-18 01:11:24:

> In answer to the small enough set of files idea.   The simple issue is
> that one time cost of black list scanning gets longer and longer and
> longer as the black list gets longer and longer and longer.   Sooner
> or latter its going to be longer than the amount of time people are
> prepared to wait for a file to be approved and longer than the time
> taken to white list scan the file by a large margin.  It is already
> longer by a large margin to white list scanning.    CPU sizes not
> expanding as fast on Linux kind brings the black list o heck problem
> sooner.   Lot of anti-virus black lists are embeding white lists
> methods so they can operate now inside the time window.   The wall is
> coming and its simply not avoidable all they are currently doing is
> just stopping themselves from going splat into it.  White list methods
> will have to become more dominate one day there is no other path
> forward for scanning content.

The problem with white-lists is who gets to decide what's on them:

a) The end-user: Easy to get around - a social engineering attack.
        The problem is if you make all the good applications the
        user downloads appear identical to any random malware they 
        download, the end-users will treat them the same.

b) The network administrator: Often doesn't exist (e.g. home users), but
        even when they do exist, they are often too over-worked to 
        handle a white-listing solution. For example Windows provides 
        white-listing in policies (AFAIK), but still there is a market
        for AV software.
        The admin probably ends up authorizing anything the end-users 
want.
                (Thus leading to the same problems as a)...)

c) The White-listing software company: Now has to maintain a perfect 
database
        of known-good software, without letting in any malware.
        Also problems with edge-cases such as adware.
        Also needs some way of handling private software, and 
self-compiled software.
                (which probably leads to a) or b)...)

d) Third-party: All the problems of c) with more trust issues, plus
        iphone-ish lock-in problems.

The other problem that I can see is that white-list scanners have to be
much more exact on the matching (either checksums or signatures), as the
malware authors will be trying to look-like authorized software.

black-list scanners can afford heuristic detection, because good-software 
authors
aren't trying to look like malware.

-- 
Douglas Leeder

Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,
OX14 3YP, United Kingdom.

Company Reg No 2096520. VAT Reg No GB 348 3873 20.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/