From owner-freebsd-chat Mon Feb 17 11:14:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA07596 for chat-outgoing; Mon, 17 Feb 1997 11:14:45 -0800 (PST) Received: from nic.follonett.no (nic.follonett.no [194.198.43.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA07572 for ; Mon, 17 Feb 1997 11:14:28 -0800 (PST) Received: (from uucp@localhost) by nic.follonett.no (8.8.5/8.8.3) with UUCP id UAA07089; Mon, 17 Feb 1997 20:12:05 +0100 (MET) Received: from oo7 (oo7.dimaga.com [192.0.0.65]) by dimaga.com (8.7.5/8.7.2) with SMTP id UAA17348; Mon, 17 Feb 1997 20:07:12 +0100 (MET) Message-Id: <3.0.32.19970217200713.00c2f920@dimaga.com> X-Sender: eivind@dimaga.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 17 Feb 1997 20:07:14 +0100 To: Charles Mott From: Eivind Eklund Subject: Re: Countering stack overflow Cc: Michael Smith , msmith@atrad.adelaide.edu.au, freebsd-chat@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-chat@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [Michael Smith] >> I commend the core team for keeping their heads while lesser mortals >> have made fools of themselves. [Charles Mott] >I don't necessarily think an emergency code audit is the way to go. >However, it is a good idea to have a lot of people looking over the code. >My tendency would be to identify security holes but not have a load of >individual fixes. A few broad strategic moves are preferable in my view. I don't agree that this is an 'emergency code audit.' It was triggered by an emergence, yes, but that wasn't the main cause. The audit is done because a lot of people felt it was a generally 'good thing.' Personally, believe in both doing the audit (getting bugs out of the sources won't hurt) _and_ doing what we can to make exploiting any remaining holes as difficult as possible. You idea is a good one for that, as it probably means a custom exploit would have to be written for each buffer overrun. (I think exploits still would be possible for many holes; we can take the actual techniques in private mail if of interest.) >What other security holes exist, other than stack overflow variations, >which allow an intruder to take over a machine? Symlink following for tempfiles, executing shell code which can be manipulated by an attacker (used to be a fairly common hole, but is mostly closed nowadays), sensitive information being accessable (eg, can give error message containing part of file symlinked to, or can core dump sensitive information like todays/yesterdays strange rlogin-hole), manipulation of where code is loaded from (the LDPATH trick against login on Linux), misuse of features (eg, use the route command of IIJ-PPP to redirect packets to a hostile host), creation of files in a user-configurable way, etc. There is a whole host of problems. Eivind Eklund perhaps@yes.no http://maybe.yes.no/perhaps/ eivind@freebsd.org