GNU Phishing

GNU Phishing

[Ian Grant]

[-- Attachment #1.1: Type: text/plain, Size: 2837 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 3252 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Lightning mailing list
Lightning-mXXj517/zsQ@public.gmane.org
https://lists.gnu.org/mailman/listinfo/lightning

Re: GNU Phishing

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    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?

It is probably harder to do this to GCC than to a proprietary compiler.
But there is no way to be totally sure.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: GNU Phishing

[Ian Grant]

> It is probably harder to do this to GCC than to a proprietary compiler.
> But there is no way to be totally sure.

The source code to the proprietary compilers is not published, so I
think it's much easier to attack the GNU and OpenBSD tools than the
proprietary ones. It doesn't matter how often the compiler source
changes because the bug automatically copies itself into the output
object code.

Such a bug need not use source code to detect what program is being
compiled. It would be better (and easier) to do pattern matching on
the compiler's internal abstract syntax representation. This could
automatically adapt itself when the structure of the target code
changes. Unless the users immediately recompiled their OS kernel and
all the system programs like login, getty etc.,  each time they
recompiled the compiler, any back-doors that were put in the kernel
would remain and "the penetrators" could just log in and make sure
that the bug was still fully functional in the compiler binaries.

The weak point is the distribution packagers. The focus of such an
attack would be the debian and red-hat maintainers, and the OpenBSD
guys, I would have thought. A compromise there would get into the
source-only distributions as well.

As I said, there is a solution, and instead of just opining what is
the probability, without giving reasons for those opinions, we could
actually show people how to reduce the probability to any required
degree short of absolute certainty. So for example, if the NSA want to
be sure they are secure, they can tell Congress they checked and the
probability that there is a trojan in their systems is less than one
in 2^-32, say.

Ian