Message-ID: <436682BA.4010001@sdf.lonestar.org>
Date: Mon Oct 31 20:47:15 2005
From: bkfsec at sdf.lonestar.org (bkfsec)
Subject: Re: Microsoft AntiSpyware falling further	behind

Valdis.Kletnieks@...edu wrote:

>Which is particularly amusing, given that the Trojan Horse written about by Homer
>was quite specifically a 'remote access Trojan' - a very small number of soldiers
>were hidden inside to open the gates for the main forces.  If anything, the
>use of the term to mean "remote access Trojan" is getting back in line with the
>*actual* historical meaning - uses of "Trojan" for non-remote-access back doors
>were in fact not strictly historically correct...
>
>You'll also notice that I *did* say:
>
>  
>
<snip>

>
>So I *was*, in fact, covering the 0.001% of trojans in use today that aren't
>strictly a remote-access variant.  Meanwhile, the *old* name for what Nick
>wants to call a 'Trojan Horse' was 'trap door' (see Karger&Schell's 1974 paper
>on Multics security - in fact, section 3.4.5.1 of that paper discusses the
>theoretical possibility of a 'compiler trap door', subsequently actually
>implemented by Ken Thompson as discussed in his 1984  Turing Award Lecture "On
>Trusting Trust".
>
>Interestingly enough, Ken calls his implementation a Trojan Horse:
>
>  "Figure 6 shows a simple modification to the compiler that will deliberately
>  miscompile source whenever a particular pattern is matched. If this were not
>  deliberate, it would be called a compiler "bug." Since it is deliberate, it
>  should be called a "Trojan horse.""
>
>Additionally, he goes on:
>
>  "The final step is represented in Figure 7. This simply adds a second Trojan
>  horse to the one that already exists. The second pattern is aimed at the C
>  compiler. The replacement code is a Stage I self-reproducing program that
>  inserts both Trojan horses into the compiler. "
>
>Notice that the second pattern is specifically *not* allowing any remote access,
>but propogating the first pattern.  Yet Thompson calls it a Trojan as well.
>
>Forget it, Nick.  You're fighting a battle already lost in 1984. ;)
>  
>

I'm forced to disagree with you Valdis.

First, I'll deal with the Homer reference:  "Trojan Horse", in the 
story, refers to the horse itself that housed the soldiers.  The 
particular *use* of the horse was not to open a backdoor, that was the 
intention of its "payload", the soldiers inside the horse. 

The horse itself had one sole duty: to trick the trojans. 

That's all it had to do.  They could have put a bomb in there for all 
intents and purposes and it still would have been a Trojan Horse, 
obviously.  No back door required, just a burning city.

So, much like all analogies in network security, people take this one 
too far.  No offense meant here, but reading the story so literally and 
comparing that to the term is, in my opinion, a misreading of the story.

Secondly, Nick wasn't saying that Trojan Horses can't refer to code 
which drops backdoors, rather that that's not all they are.  Frankly, 
the Ken Thompson lecture you cited *proves* his point as the Trojan does 
not open up a back door.

In my mind, there are three important major groups of malware:  Virus, 
Trojan, and Worm.

*ALL* forms of malware tend to match at least one of these subgroupings 
in their design and operation.  All that separates the groups therein 
are payloads which cause them to do different things.  (I am not listing 
manual exploit code as its use is obvious.)

Viruses are file/exec infectors (including boot sectors and anything 
that executes).  Trojans are programs requiring manual execution 
intended to deceive.  And worms spread on their own accord via network 
means.

Spyware, backdoors, keyloggers, and other malware payloads are all 
dropped by one of these types of packages.  Spyware drops its payload 
often through websites with malicious code on it.  This, in my mind, 
consistutes a trojan as the deceptive website draws the target in for 
silent installation.  E-mail "viruses" are trojans in my book because 
the deceptive e-mail is the draw. 

If we start coming up with arbitrary and restrictive taxonomy for the 
different "types" of malware, we're going to harm our ability to deal 
with them.  I think it's very important that we keep the major strata of 
malware from becoming too specific in its meaning.

                -bkfsec

Powered by blists - more mailing lists