2008-08-11 22:10:08

by David Wagner

[permalink] [raw]
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linuxinterfaceforon access scanning

Press, Jonathan wrote:
>I think everyone understands one side of the threat model, that is Linux
>machines being carriers of infections aimed at other platforms. There
>are many ways that such infections can be stored, and many ways in which
>they can be communicated to the target machines. There are so many that
>it would not be effective or efficient for each such transfer
>application to be able to handle its own malware scanning, which is the
>short statement of why centralized AV protection with notification
>assistance from the kernel is appropriate.

I'm not sure I follow. Could you name a few channels that you think
are likely to represent a serious problem in practice (not just a
theoretical possibility)? There are a few obvious ones: files shared
over a SMB filesystem; attachments sent via email. What else? Can
you give some other examples?

If it's true that there are an unbounded number of channels by which
malware could reach a target Windows machine, all of equal importance,
then it sounds to me like the end-to-end argument would suggest that the
virus scanner needs to be on the target machine. (Otherwise there will
inevitably be some channel you missed.) But I'm not convinced that this
is true.

One standard counter-argument to the end-to-end argument is that,
in some cases, we can identify a single chokepoint: a single central
machine or network where you can do virus scanning for a large collection
of machines, at much lower administrative cost. If this addresses one
propagation channel that accounts for the overwhelming majority of
viral spread in practice, this can potentially be useful. Is that the
idea you had in mind?

Are we talking about enterprise networks? Are we talking about consumers?

I assume we're talking about a case where there is a Linux machine L
and a Windows machine W, and W is the target and there is a channel by
which malware can propagate from L to W, and L and W are under the same
administrative control (e.g., two machines owned by the same company).
Moreover, I'm assuming that L is secure and has not been compromised
(otherwise you've got a horse of a different color). Have I understood
you correctly so far?

>It is true that most of our experience is with DOS and Windows, and that
>the types of attacks that can be launched there are not easy to
>generalize to other platforms. However, that does not mean that
>non-Windows platforms like Linux are therefore immune, or that we are
>tilting at windmills to say that we address non-Windows infections.
>There are many specific forms of malware on non-Windows platforms that
>we identify in the same way that we identify them on Windows.

The point is that you need to think about what classes of attacks you
want to defend against, and be able to precisely characterize which
attacks are and aren't in scope. So far, I haven't seen any evidence
of that; I've just seen fuzzy slogans and hand-wavy "philosophies".

You can't stop them all, so pick your battles.

>In a sense the reason I have found the question about "threat model" to
>be so difficult to answer is that the basic unpredictability of the
>attack makes the answer in essence: "Anything". That is, it
>essentially doesn't matter what the threat is or how malware is
>implemented, except that we know that it exists, both in theory and in
>practice, and we have an effective way of detecting and removing it.

If your answer to the question of which security threats you want
to address is "All of them", then you've tackled a hopeless problem.
If that's your answer, give up now. There is no silver bullet for
computer security. You need to narrow your scope if you want to
have any hope of building something useful.

I dispute the claim that we have an effective way of detecting malware.
We have a way of detecting some malware.

I'm being blunt because I think sometimes it helps to hear it
told straight, without any sweetening. Please forgive any impoliteness
this may cause.


2008-08-12 07:49:23

by Alan

[permalink] [raw]
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linuxinterfaceforon access scanning

> theoretical possibility)? There are a few obvious ones: files shared
> over a SMB filesystem; attachments sent via email. What else? Can
> you give some other examples?

This is the nightclub model and doesn't work viz:

"If I put a big scary man on the door nobody will be able to get knives
and drugs in because we only have one door for the public"

If you have to enumerate the potential attack vectors to make your model
work you already lost. There is one of you and a lot of them. Smart
nightclubs don't do that they circulate looking for evidence. Yes, they
will miss some, yes they will respond late to some, but they will at
least notice there has been a problem.

Now computer security is a bit different because it has some night of the
living dead type properties where the zombies don't just sneak in through
the toilet window but they go around turning security guards into zombies
too but the basic premise is very much the same.

> Are we talking about enterprise networks? Are we talking about consumers?

What theat model and set of security properties does this change ?
The reasons for poor security may change from 'who cares if we get a
virus, I get an afternoon drinking coffee' to 'not computer skilled' but
the basic problem is very similar.

What are the invariants and what are the probability based things we are
trying to achieve ? What level of interference with existing behaviour is
acceptable ?

The last is important as we SELinux you can achieve much of what is
needed but only at a cost of interfering in normal practice now and then
- eg downloading a shell script versus accidentally downloading a worm is
rather hard for a PC to tell apart so implementing 'written by web
browser, can't be executed' is easy but has side effects

Alan