GNU Phishing

[Ian Grant]

The following is probably the USAF report on Multics security that Thompson mentions in his "Reflections in Trusting Trust" talk.

This has been known for forty years now. What do you reckon is the probability that it has been tried? What system/compiler would be the most likely target for such an attack?

There is a solution, but we need to work _together_ on it. This one can't be won by any party.

Excerpt from "MULTICS SECURITY EVALUATION VULNERABILITY ANALYSIS"

   Paul A. Karger, 2Lt, USAF
   Roger R. Schell, Major, USAF

   June 1974

   Approved for public release;
   distribution unlimited.

Pg 51.

[ ... ]

Two classes of trap doors, which are themselves source or object trap
doors are particularly insiduous and merit discussion here.  These are
the teletype string trigger trap door and the compiler trap door.

[... one paragraph describing the teletype trigger trap door omitted ...]

Pg. 52

It was noted above that while object code trap doors are invisible,
they are vulnerable to recompilations. The compiler (or assembler)
trap door is inserted to permit object code trap doors to survive even
a complete recompilation of the entire system. In Multics, most of the
ring 0 supervisor is written in PL/1. A penetrator could insert a trap
door in the PL/1 compiler to note when it is compiling a ring 0
module. Then the compiler would insert an object code trap door in the
ring 0 module without listing the code in the listing. Since the PL/1
compiler is itself written in PL/1, the trap door can maintain itself,
\underline{even when the compiler is recompiled.} (38) Compiler trap
doors are significantly more complex than the other trap doors
described here, because they require a detailed knowledge of the
compiler design. However, they are quite practical to implement at a
cost of perhaps five times the level shown in section 3.5 [<$4,000,
See Pg. 57]. It should be noted that even costs several hundred times
larger than those shown here would be considered nominal to a foreign
agent.

There is also a variant on the compiler trap door called the
initialization trap door. Here, the system initialization code is
modified by the penetrator to insert other trap doors as the system is
brought up. Such trap doors can be relatively invulnerable to [page
break] detection and recompilation, because system initialization is
usually a very complex and poorly understood procedure.

------------------------------------------------------

(38) This type of trap door does not require a higher level
language. Entirely analogous trap doors could be placed in an
assembler.

====================================================

Downloaded from:
   http://seclab.cs.ucdavis.edu/projects/history/papers/karg74.pdf

Accessed 25 August 2014.

PDF 558901 bytes, SHA1 c/s: a77bb61b2a65a337506a72ec98fe8d546f830994