Ruediger Pluem wrote: > > 2 weeks? The text in the reporters mail (see end of mail) speaks about > May 16th, 2006. This would be about a year (and this is mentioned as > reason for publishing) When did they actually send this to security@ > and to which ([EMAIL PROTECTED], [EMAIL PROTECTED])?
My bad, and apologies. We are actually looking at resolving this issue permanently. >> Essentially, PID tables need to move from the score to a local process >> list only in the parent, and unshared. That would solve the 80/20 of >> this entire class of issues. > > So, I guess #2/#3 happens due to a manipulation of the pids in the scoreboard > which tricks the parent process in sending the signals to the wrong pids (once > it has a need to do so to its children). > Any more details about #1/#4? Yes, please refer to [EMAIL PROTECTED] archives, as exploit code is not published. But I have no issue at this point if we start discussing #1/#4 as bugs, here on [EMAIL PROTECTED] Informational pids aught to stay in the scoreboard. Let's face it, NOTHING stops a process from trying to sigkill each process ID from 0 to 65535, except for the language itself. If a scripting language allows you to send arbitrary signals to arbitrary processes, it's your own stupidity for letting untrusted code run on your box. SO, the parent running as root shouldn't be trusting the score for anything such as the pids it is killing, etc. But the fact is 'nobody' can kill the processes running as 'nobody', and nothing will ever change that. Bill
