From owner-freebsd-hackers Tue Feb 11 10:09:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA08284 for hackers-outgoing; Tue, 11 Feb 1997 10:09:12 -0800 (PST) Received: from burka.carrier.kiev.ua (snar@burka.carrier.kiev.ua [193.193.193.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA08262 for ; Tue, 11 Feb 1997 10:08:47 -0800 (PST) Received: (from snar@localhost) by burka.carrier.kiev.ua (8.8.4/8.who.cares.1) id UAA13517; Tue, 11 Feb 1997 20:07:12 +0200 (EET) From: Alexander Snarskii Message-Id: <199702111807.UAA13517@burka.carrier.kiev.ua> Subject: Re: Increasing overall security.... To: imp@village.org (Warner Losh) Date: Tue, 11 Feb 1997 20:07:00 +0200 (EET) Cc: freebsd-hackers@freebsd.org In-Reply-To: from "Warner Losh" at Feb 11, 97 08:40:27 am Content-type: text/plain; charset=koi8-r X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > : Or did he checked all the FreeBSD > : packages/ports which can use this functions and have enough privileges > : to destroy your system if exploited? > > No. He hasn't. That's a FreeBSD thing :-). However, now that ports > are part of the OpenBSD system (or at least supported), I think this > may change. Well, that's not his problems. > > : Or did anybody checks it and > : published patches to ones (if the holes are found) ? > > Often time Theo is behind the scenes and knows about these before the > great unwashed masses know about them. And he fixes those problems in > OpenBSD that are present. Well, but now any 'hidden security violation' ( 'hidden' just because noone knows that there are one) have these stages of evolution: 1. somebody ( often time original author ) places to his program some code, which can be used to violate security. 2. that part of code are used in normal purposes, just because noone knew, that there are ones. 3. somebody ( often time Theo de Raadt or original author of the code founds some 'bad things' ( buffer overruns, f.e. ) in the code, and patches the program, or writing exploit to get additional privleges with the one part of code, or notifies author about that disfuncionality or something else. 4. author or security-officer of the project applied these patches, and we are again on the step 1 ... ( and on the step 2 and 3 for some another bugs ). Just an example of such violation: user-level ppp was written sometimes ago. And, in the first FreeBSD-release that i seen ( 2.1.0 ) it has next string: strcpy(buffer,getenv("HOME")) ( or something like that, there were an exploit ). About three months ago, when ppp on my computer tells me, that it can't recognise any of tun* device, i saw the sources and found these strings. And notified security-officer@freebsd.org about possibility of exploit. And Paul Triana answers me, that seurity advisory is pending. And it was FreeBSD security advisory. Well, but i did'nt verified _all_ ppp code to avoid all these bugs ! I just found one of principal exploits in, and i have no time to read _all_ the ppp code... As for me, fast-and-dirty way to avoid the _class_ of problems is to rewrite the strcpy(2) function, to let it _itself_ verify, did it overwrite any stack frame or not! F.e. in the example above, if the somebody wants to get the euid=0, he just executing ppp with the HOME='exploit-code', and strcpy, in time of copying 'exploit-code' to 'buffer' overwrites stack, and did not care about it. As a result, after returning from functions, hacker gets his euid=0... But, in libc with my patches to, strcpy calling checkframe functions, which checks, _did_ _that_ _function_ _overwrited_ _any_ _stack_ _frame_. And calling kill(SIGSEGV,getpid()) if so, just because we will not take segmentation violation only in case of exploiting some hole. So, _noone_ of holes, which were found by anybody and uses strcpy as 'exploit-function' will not work with that libc. More than, noone of _yet not founded_ exploits, based on stack-smashing technology and which uses strcpy(2) _will not_ work. Just because strcpy(2) will generate SIGSEGV to the program _before_ the stack got to be executed. > > Keep in mind, as was recently pointed out to me, that just bringing in > the OpenBSD patches will not make FreeBSD secure. For that a top to That's not OpenBSD patches. That is original patches. More that, these patches based on original idea, and i did'nt heard anything like it. > bottom audit of code running at elevated priviledge must be > completed. The patches will tend to make FreeBSD more secure, but you > won't know until after you've audited if you've grabbed everything or > not. I'm absolutely sure, that my patches is not an panacea from all classes of exploits. But, with that patches, _noone_ stack-smashed attack, which uses strcpy, strcat, sprintf and some other functions will not work. So, FreeBSD with that patches have one exploits class less that any other PC-based UNIX (Including OpenBSD). -- Alexander Snarskii the source code is included.