[3496] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: Medium-term real fix for buffer overruns

daemon@ATHENA.MIT.EDU (Bill Frantz)
Fri Oct 16 14:01:24 1998

In-Reply-To: <199810151148.HAA02440@smb.research.att.com>
Date: Fri, 16 Oct 1998 09:57:41 -0800
To: "Steven M. Bellovin" <smb@research.att.com>, Tom Perrine <tep@sdsc.edu>
From: Bill Frantz <frantz@netcom.com>
Cc: karn@Qualcomm.com, gnu@toad.com, reinhold@world.std.com,
        decius@ninja.techwood.org, cryptography@c2.net

At 3:48 AM -0800 10/15/98, Steven M. Bellovin wrote:
>In message <199810150457.VAA08585@lart>, Tom Perrine writes:
>
>>
>>These days, we have to remember that anything which runs with any
>>non-user privileges is really part of the OS (or the TCB, if you
>>prefer), and should be subject to the same examination as the rest of
>>the kernel.  A buffer overflow is not bad.  A buffer overflow in
>>trusted code is bad.
>
>The problem is that the notion of the TCB is obsolete -- in a network
>security setting, the first-order problem is penetration of the system,
>via failures of daemons that don't have elevated privileges.  The Worm
>is a classic example; neither its penetration of sendmail nor its
>exploitation of the 'finger' buffer overrun relied on those programs
>having 'root' privileges.  The same applies today, where buffer overruns
>in network browsers could be used to steal user files.  In other words,
>far too much of the system would have to be part of the TCB for the
>concept to survive.  (Actually, that was always true -- more or less by
>fiat, the compilers used to build the OS are part of the TCB; remember
>Thompson's paper?)
>
>Assuming that we do solve the buffer overrun problem, I claim that the
>next generic threat is mobile code.  Today's examples are Javascript,
>plug-ins, and macro viruses.  Nor do we have an adequate formal model
>for how to deal with these.  Consider Word, for example, running on
>an A1-rated version of Windows.  It may not be able to get at the system's
>normal.dot file, but it can sure get at the user's equivalent that he
>or she uses to customize Word.  From there, it gets to every other Word
>document that that user touches.  Sure, it can't wipe out the OS.  But
>it can sure do nasty things to the user.

These attacks are all a problem of the application running with too much
privilege.  (ALL the user's privilege in this case.)  This flaw pervades
most operating system work since at least Multix.  Some systems, e.g.
KeyKOS, tried to reduce/eliminate this exposure, but they haven't caught on
in the marketplace. (I hope there's still time.)


-------------------------------------------------------------------------
Bill Frantz       | Macintosh: Didn't do every-| Periwinkle -- Consulting
(408)356-8506     | thing right, but did know  | 16345 Englewood Ave.
frantz@netcom.com | the century would end.     | Los Gatos, CA 95032, USA



home help back first fref pref prev next nref lref last post