From owner-freebsd-chat Mon Feb 17 12:20:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA11951 for chat-outgoing; Mon, 17 Feb 1997 12:20:35 -0800 (PST) Received: from relay.nuxi.com (nuxi.ucdavis.edu [128.120.37.176]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA11946 for ; Mon, 17 Feb 1997 12:20:33 -0800 (PST) Received: from dragon.nuxi.com (reqd-003.ucdavis.edu [128.120.251.123]) by relay.nuxi.com (8.8.4/8.6.12) with ESMTP id MAA06715; Mon, 17 Feb 1997 12:20:31 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.8.5/8.7.3) id UAA24162; Mon, 17 Feb 1997 20:20:23 GMT Message-ID: <19970217122022.XX15588@dragon.nuxi.com> 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 References: <199702170629.QAA08745@genesis.atrad.adelaide.edu.au> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Disclaimer: Mutt Bites! Organization: The NUXI *BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 In-Reply-To: ; from Charles Mott on Feb 17, 1997 07:30:43 -0700 Sender: owner-chat@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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)