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] [day] [month] [year] [list]
Date: Tue Nov  1 00:01:40 2005
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: Re: Microsoft AntiSpyware falling further behind

Valdis Kletnieks to me:

> > This is a Johnny come lately perversion of the real meaning of Trojan 
> > Horse in reference to software.  Trojan Horse, or simply Trojan, 
> > software has always meant, and still does to anyone with a vague hint 
> > of historical awareness, software that gets installed under the 
> > pretense of being something desirable or beneficial but that actually 
> > has deliberately (on the part of its designer/developer) undesirable 
> > effects that are (at least initially) hidden or not obvious to the 
> > intended user(s) of the software.
> 
> 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...

Two observations here...

First, I note that "bkfsec" has already pointed out that in the 
Homerian tale, "Trojan Horse" refers to the horse itself, whose job was 
to misdirect the Trojans -- they were supposed to see it as a gift, 
rather than as a poison pill.  The important notion here is the 
obfuscation of the real intention of the device, as "Trojan Horse 
software" came to mean "something apparently desirable that is not".

Second, I _suspect_ (but was not active in that community, so...) that 
the original _common_ use of Trojan Horse in relation to software was 
in the relation to the various warez designed to backdoor BBS systems 
(usually by tricking the sysop into running them).  However, that 
common usage (quickly) broadened, even amongst the BBS community, to 
mean any software with undisclosed, deliberately undesirable features.

This is quite obvious even within the BBS community, as by the time the 
"Dirty Dozen" list came into being, that was clearly the accepted 
meaning, as very few (if any?) entries on that list were classic BBS 
backdooring programs, but things like hacked/cracked/etc but also 
malicious copies of "the latest version of some popular game or util" 
(with archivers being an especially popular target IIRC).

> You'll also notice that I *did* say:
> 
> > and (b) once there, gives the attacker a "back door" into the system, to
> > do unspecified things (run commands, launch DDoS attacks, send spam, scan
>      ^^^^^^^^^^^^^^^^^^
> > for other vulnerable software, upload plugins to extend the Trojan's functionality,
> > or whatever).
>      ^^^^^^^^
> 
> 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".

Did Thompson really implement that?

> 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.

Well, unsurprisingly, early in a field's development, some terms are 
poorly defined, overly widely and/or overly narrowly used by some folk 
and so on.  This is obvious if you look at all the "experts" talking 
about the Morris Worm aty the time.  Some called it a Trojan, some a 
virus, some a worm, some "a virus that is a worm" and so on.  The terms 
were confusingly and conflictingly used by folk who had not, as a 
group, settled on a community standard for those terms (and, at least 
"worm" is still not well-defined or tied down strictly enough to be 
considered a "settled" case, but let's not start that debate here).

> Forget it, Nick.  You're fighting a battle already lost in 1984. ;)

Huh?

Thompson's "definition" of Trojan Horse does not require the notion of 
backdoor or remote access.  As you quoted Thompson:

   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."

There is nothing in that definition that says the miscompilation need 
be the addition of code to allow for remote access.  The added code 
could be a keylogger that Emails keystrokes off to an anonymous drop 
address, or an Email address scrounger or A DDoS agent or...

That Thompson specifically talked about an instance that involved a 
(remote) access mechanism simply reflects the conserns of his time -- 
there was not a criminal underclass striving to collect Email 
addresses, phish personal identity data, etc from computers, so those 
would not have been particularly apposite examples for Thompson to use 
_for an audience of that time_, but there was concern about connecting 
computers together across a loosely trusted network.  I doubt, however, 
that Thompson was naive enough to not realize that all manner of other 
"bad stuff" may befall future uses of computers and is formulation, as 
you quoted, did not limit itself to "remote access" as the defining 
aspect of what he called a Trojan Horse.


Regards,

Nick FitzGerald

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ