what do you not believe in? that a task refcount leak can be exploited
for privilege elevation?
i never post exploits. however spender did write at least a proof-of-concept
that triggers it and proves that it's potentially exploitable. writing a
weaponized version takes a whole lot more effort than it's worth for us
(though i bet others have been working on it ever since if they didn't
already write one when the bug got introduced).
what i said was *not* specific to this bug at all, any local privilege
elevation bug can be used to, well, elevate privileges, regardless of
how one gets into a box. the browser example was just that, to highlight
that even single home user systems may very well be affected. sure, the
browser bug is not your problem, but the local privilege elevation due
to kernel bugs *is*. your wording was wrong, untrusted users are only
*one* potential kind of threat therefore if only such systems update,
many others will remain vulnerable.
why isn't it useful? i've been asking every one of you who said so and
have yet to receive a reasonable justification. remember, your own
employers do it 'all the time', it must be useful to someone.
and what's with this 'all the time'? if you guys fix security bugs all
the time, then yes, you are expected to announce them all the time. if
you think that reflects badly on the quality of the kernel code, then
maybe you should think over your development process that results in
security fixes 'all the time'.
if you are not qualified to do this job then don't do it. noone forced
you to accept this task. look at Chris Wright, he has no problems with
disclosing the security issues and he actually publicly pledged to do
his best to do so (and i hope he won't revert his position now).
cheers,
PaX Team
--
