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,
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
Monday, 25 August 2014
Friday, 8 August 2014
A Funny way to Earn a Living
There seem to be quite a few foreigners in La Paz, who earn a living of some sort by doing tricks in front of cars waiting for traffic lights to turn green. I saw a guy today, who had learned how to spin a ball balanced on the end of a wooden-spoon he held in his mouth whilst juggling three skittles. After 5 seconds of this, the ball fell off the end of a stick, and then he flipped his hat off the ground with a foot, and caught it, and bowed and smiled to his audience. "What a weird and pointless skill!" I thought.
Then I realised that I had been doing something weirder and even more pointless for the past few days. I had been learning how to use GNU autoconf/automake/autoheader etc. again. I call them the GNU auto4ck tools. Really, after fifteen years of this crap, we ought to admit defeat and try again. But we don't. Who said enough monkeys banging away on type-writers couldn't write the works of Shakespeare? If a few thousand monkeys banging away on typewriters for a just a couple or three decades can make the GNU software suite, why not the works of Shakespeare too?
Now if we all started thinking instead of just banging away on our typers, then we might be able to make better software. But we haven't time to think, because we're so occupied looking for obscure and stupid bugs introduced by using a 'language' which, for example, can't detect an 'error' caused by putting a space between the name of a function and the parentheses containing its arguments. Or by indenting the arguments to a nested if/then/else block, in an attempt to make it more readable. I despair!
But the upshot is, maybe Red October will build on Linux boxes other than my own. Maybe someone will try cloning the repository now, and typing
Then I realised that I had been doing something weirder and even more pointless for the past few days. I had been learning how to use GNU autoconf/automake/autoheader etc. again. I call them the GNU auto4ck tools. Really, after fifteen years of this crap, we ought to admit defeat and try again. But we don't. Who said enough monkeys banging away on type-writers couldn't write the works of Shakespeare? If a few thousand monkeys banging away on typewriters for a just a couple or three decades can make the GNU software suite, why not the works of Shakespeare too?
Now if we all started thinking instead of just banging away on our typers, then we might be able to make better software. But we haven't time to think, because we're so occupied looking for obscure and stupid bugs introduced by using a 'language' which, for example, can't detect an 'error' caused by putting a space between the name of a function and the parentheses containing its arguments. Or by indenting the arguments to a nested if/then/else block, in an attempt to make it more readable. I despair!
But the upshot is, maybe Red October will build on Linux boxes other than my own. Maybe someone will try cloning the repository now, and typing
cd srcthen
autoreconf -vif
./configure --helpand following the instructions.
Subscribe to:
Posts (Atom)