Date: Mon, 17 Feb 1997 12:20:22 -0800 From: obrien@NUXI.com (David O'Brien) To: cmott@srv.net (Charles Mott) Cc: msmith@atrad.adelaide.edu.au (Michael Smith), freebsd-chat@FreeBSD.ORG Subject: Re: Countering stack overflow Message-ID: <19970217122022.XX15588@dragon.nuxi.com> In-Reply-To: <Pine.BSF.3.91.970217065849.2218A-100000@darkstar>; from Charles Mott on Feb 17, 1997 07:30:43 -0700 References: <199702170629.QAA08745@genesis.atrad.adelaide.edu.au> <Pine.BSF.3.91.970217065849.2218A-100000@darkstar>
next in thread | previous in thread | raw e-mail | index | archive | help
Charles Mott writes:
> I see two major categories of security vulnerabilities:
>
> (1) A backdoor which trivially allows someone to become
> a superuser, bypassing all the normal passwords, security
> and authentication.
>
> (2) Data and file manipulation/corruption leading to either
> poor system reliability or compromise of privacy
>
> Category (1) is far more serious, and seems to warrant some broad and
(1) is NOT a vulnerability (as you've stated it). A "backdoor" is
something purposely installed, and is doing what it intended to do.
Vulnerabilities are things like race conditions, buffer overflows, etc.
Please do your homework first, then write back.
Security researchers have classified vulnerabilities into several
categories. The results of the two seminal ones are:
Protection Analysis -- R. Bisbey II and D. Hollingsworth, ISI/RR-78-13,
DTIC AD A056816, USC/Information Sciences Institute (May, 1978)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Improper protection (initialization and enforcement)
1a. improper choice of initial protection domain -- "incorrect
initial assignment of security or integrity level at system
initialization or generation; a security critical function
manipulating critical data directly accessible to the user"
1b. improper isolation of implementation detail -- allowing users
to bypass operating system controls and write to absolute
input/output addresses; direct manipulation of a "hidden" data
structure such as a directory file being written to as if it were
a regular file; drawing inferences from paging activity
1c. improper change -- the "time-of-check to time-of-use" flaw (ie.
race condition); changing a parameter unexpectedly
1d. improper naming -- allowing two different objects to have the
same name, resulting in confusion over which is referenced (ie.
symlink vulnerabilities)
1e. improper deallocation or deletion -- leaving old data in memory
deallocated by one process and reallocated to another process,
enabling the second process to access the information used by the
first; failing to end a session properly
2. Improper validation -- not checking critical conditions and
parameters, leading to a process' addressing memory no in its memory
space by referencing thru an out-of-bounds pointer value; allowing
type clashes; overflows (ie. the setlocale vulnerability)
3. Improper synchronization
3a. improper indivisibility -- interrupting atomic operations (e.g.
locking); cache inconsistancey (ex. old v7 mkdir vulnerability,
no mkdir(), so mknod() and chown() was used --> allowed you to
own any file you wanted).
3b. improper sequencing -- allowing actions in an incorrect order
(e.g. reading during writing)
4. Improper choice of operand or operation -- using unfair scheduling
algorithms that block certain processes or users from running; using
the wrong function or wrong arguments.
RISOS -- R.P. Abbott, J.S. Chin, J.E. Donnelley, et al., "Security
Analysis and Enhancements of Computer Operating Systems", NBSIR 76-1041,
Institute for Computer Sciences and Technology, National Bureau of
Standards (Apr. 1976)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Incomplete parameter validation -- failing to check that a parameter
used as an array index in the range of the array
2. Inconsistent parameter validation -- if a routine allowing shared
access to files accepts blanks in a file name, but no other file
manipulation routine (such as a routine to revoke shared accesses)
will accept them.
3. Implicit share of privileged/confidential data -- sending
information by modulating the load average of the system
4. Asynchronous validation/Inadequate serialization -- checking a file
for access permission and opening it non-atomically, thereby allowing
another process to change the binding of the name to the data between
the check and the open
5. inadequate identification/authentication/authorization -- running a
system program identified only by name, and having a different
program with the same name executed
6. Violable prohibition/limit -- being able to manipulate data outside
one's protection domain
7. Exploitable logic error -- preventing a program from opening a
critical file, causing the program to execute an error routine that
gives the user unauthorized rights.
> What is amazing about stack overflow, and really surprised me, is that it
> is a vulnerability that has been known at least since the Robert Morris
> Jr. internet Worm attack, almost ten years ago.
Very good -- we just *DONT* learn from history. Features sell OS's, not
security. When was the last time you went to the store and asked for the
most secure OS you could buy? Now when was the last time you went to the
store and asked "which OS runs Doom?", and let that influence your buying
decision? We live in a capitalistic buying market.
> Yes, a code review is worthwhile, but the OS and basic system calls should
> provide a layer of defense against stack overflow. It is astonishing
> that this has not been done yet over the past 5 to 10 years.
And it can, but such a system is not Unix, nor will Unix *ever* be such a
system. And most don't want it to be such a system. Have *YOU* ever
used a B classed machine (from the Orange Book). Did you *enjoy* your
experience with it???
--
-- David (obrien@NUXI.com -or- obrien@FreeBSD.org)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970217122022.XX15588>