Date: Mon, 20 Sep 2004 10:54:30 -0500 (EST) From: Sam <sah@softcardsystems.com> To: Mike Meyer <mwm@mired.org> Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD Kernel buffer overflow Message-ID: <Pine.LNX.4.60.0409201054060.24255@athena> In-Reply-To: <16715.50688.830652.474272@guru.mired.org> References: <4146316C000077FD@ims3a.cp.tin.it> <20040916235936.GO23987@parcelfarce.linux.theplanet.co.uk> <20040918030531.GA23987@parcelfarce.linux.theplanet.co.uk> <16715.50688.830652.474272@guru.mired.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 18 Sep 2004, Mike Meyer wrote: > In <001801c49d38$1c8cb790$1200a8c0@gsicomp.on.ca>, Matt Emmerton <matt@gsicomp.on.ca> typed: >> I disagree. It really comes down to how secure you want FreeBSD to be, and >> the attitude of "we don't need to protect against this case because anyone >> who does this is asking for trouble anyway" is one of the main reason why >> security holes exist in products today. (Someone else had brought this up >> much earlier on in the thread.) > > You haven't been paying close enough attention to the discussion. To > exploit this "security problem" you have to be root. If it's an > external attacker, you're already owned. > > That leaves trojans. Those are always a problem for OSS - and for > proprietary software. With OSS, you have the option of auditing the > code yourself, though that has been beaten (by Ritchie, I believe > *). Personally, I trust the FreeBSD committers to not trojan my system > - and if they were going to, there are *so* many easier ways to do > it. Should I ever decide to run a third party kernel module, I may > well audit the code for that module. But I take that risk everytime I > install software - whether it's from ports, commercial, or just > grabbed off the web. > > <mike > > *) There was at one time a hacked C compiler that did two evil > things. The first evil thing was to recognize the password checking > code in login, and generate code that always accepted a "back door" > password as well as the real password. The second evil thing was to > recognize the place in the C compiler where the two hacks were, and > reinsert them into the generated code. So a source audit would turn up > nothing, but the system was thoroughly compromised. http://www.acm.org/classics/sep95/ Cheers, Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.60.0409201054060.24255>