Date: Mon, 17 Feb 1997 20:07:14 +0100 From: Eivind Eklund <eivind@dimaga.com> To: Charles Mott <cmott@srv.net> Cc: Michael Smith <msmith@atrad.adelaide.edu.au>, msmith@atrad.adelaide.edu.au, freebsd-chat@FreeBSD.ORG Subject: Re: Countering stack overflow Message-ID: <3.0.32.19970217200713.00c2f920@dimaga.com>
next in thread | raw e-mail | index | archive | help
[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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.32.19970217200713.00c2f920>