Date: Sat, 18 Sep 2004 00:22:08 -0500 From: Mike Meyer <mwm@mired.org> To: "Matt Emmerton" <matt@gsicomp.on.ca> Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD Kernel buffer overflow Message-ID: <16715.50688.830652.474272@guru.mired.org> In-Reply-To: <001801c49d38$1c8cb790$1200a8c0@gsicomp.on.ca> References: <4146316C000077FD@ims3a.cp.tin.it> <20040916235936.GO23987@parcelfarce.linux.theplanet.co.uk> <20040918025217.GB54961@silverwraith.com> <20040918030531.GA23987@parcelfarce.linux.theplanet.co.uk> <001801c49d38$1c8cb790$1200a8c0@gsicomp.on.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16715.50688.830652.474272>