FreeBSD Kernel buffer overflow

[Sam]

On Sat, 18 Sep 2004, Mike Meyer wrote:

> 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.

http://www.acm.org/classics/sep95/

Cheers,

Sam