FreeBSD Kernel buffer overflow

[Julian Elischer]

This is standard proceedure.

"there is no security problem."
There is not even a practical problem..

No-one is going to be able to break into your machine because of this 
unless they
have already broken into your machine by some other method.

There is an implicit understanding in the kernel that it trusts itrself 
to be done right..
If you wan to check this  I can show you many more things we trust 
ourselves on in the kernel

for example do you check the function pointers in vfs method arrays 
before calling them?
If we checked everything we would never get anything done.. In the end 
we draw the line at
"we check values that come from userspace." We trust values that come 
from root indirectly
e.g. when root mounts a filesystem or a kld module.

As you have raise dth issue we might add a KASSERT checking that  it is  
within bounds but
the check would not be turned on  for normal kernels just debug kernels.


gerarra at tin.it wrote:

>>As you point out,
>>    
>>
>
>Seen i said alredy, why repeating? I was pointing out about the problem,
>not security issue.
>Like FreeBSD user I want the patch for this code and I think is useful reporting
>bug. It's an important part of the kernel so I didn't prepared a patch alredy,
>I would like to know how core team will move.
>
>  
>
>>The number of arguments for a syscall is defined within the kernel and
>>    
>>
>
>  
>
>>is not
>>supplied from an untrusted source. This means that this is not a 
>>security problem.
>>    
>>
>
>Inside the kernel? i can define a syscall accepting 30 args and it could
>send in panic freebsd kernel. I think it's a problem and a patch 'must'
>occur.
>
>  
>
>>to load a kernel module you must be root (and not in a jail) meaning 
>>that if you
>>wanted to, the quicker and easier exploit would be
>>/bin/sh
>>
>>    
>>
>nice but it doesn't solve the problem.
>  
>
what problem would that be? If you are writing a kernel module then we 
assume yuo are truted otherwise
whoever gave you root privs is in more trouble than a crashed system.

>
>cheers,
>rookie
>
>
>_______________________________________________
>freebsd-hackers at freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>  
>