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.



[EMAIL PROTECTED] 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


_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"



_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to