David Lang wrote:

quoted text
> > That means only people with the time, energy, and expertise to create an
> > exploit will have an exploit. This includes probably 90% of the
> > people who
> > would use the exploit maliciously

quoted text
> haven't you ever heard of script-kiddies? they are by far the majority of
> attacks on systems but do not have the expertise to create exploits. it
> takes someone else writing the exploit for them and packaging it to make
> them a threat.

Nobody is saying you should package the exploit. If they need someone else
to package it, they'll still need that. So the question is not if this will
deter script kiddies but whether it will deter the people who package
exploits for them. And from experience, I can tell you that answer is no.
Manys attacks that were believed too difficult for the script kiddies to do
were packaged by people who had the expertise and then used by script
kiddies.

quoted text
> in the meantime there's a chance for the fix to get propogated out to a
> released version and for people to upgrade their systems. providing
> exploit code along with the bugfix means that the script kiddies have the
> exploit immediatly, but the fix isn't in any released version (not even a
> -rc or daily -git snapshot)

The alternative is that the fix gets released but not implemented.

quoted text
> > It does, however, ensure that the majority of
> > ordinary users won't be able to test their systems to see if they're
> > vulnerable or if the vulnerability is fixed. So at least it
> > will have some
> > effect.

quoted text
> how many people run exploits against their production systems to 'see if
> they are fixed', very few, and those only on strict schedules
> with lots of
> adnvance notice and other safeguards.

I can tell you how many run exploits against their production systems when
they don't know the exploits exist -- zero. It takes, at a minimum, the
knowledge that an exploit is possible. In the cases being discussed, even
this was withheld.

Fixes will not be widely deployed on a timely basis unless, at an absolute
minimum, it is known that there is an exploitable bug that has been fixed.

DS


--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/