FreeBSD Kernel buffer overflow

[Mike Meyer]

In <001801c49d38$1c8cb790$1200a8c0 at gsicomp.on.ca>, Matt Emmerton <matt at 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 at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.