On Fri, Jul 18, 2008 at 06:51:42PM -0700, David Schwartz wrote:
quoted text
> 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.

Obvious exploits are generally written by random "joe hackers" to get a
name. However, most kernel exploits are really complex, and written by
the person who discover them because they're the only ones with enough
research on the problem to be able to do so (remember vmsplice ?).

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.

People generally don't run kernel exploits on their production systems,
simply because either the exploit works as expected and the system remains
safe, or it fails, and it generally means system crashes, freezes, or will
need a reboot very soon. The same is generally true for proof-of-concepts,
but those tend to touch less things and have less side effects in case of
failure.

quoted text
> 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.

To be clear, *I* am for telling people that they might be facing a problem
(and for not releasing exploits). This is probably because I work on
slow-moving code that people upgrade once a year or so. I know that when
you're wondering whether you'll upgrade your system after that long, you
need to what it will really fix, otherwise you don't upgrade it. That's
why I include indicators when I have them, whether they are about security,
or stability.

In fact, for people always running latest version and upgrading fast,
having all the details or not does not matter much. But as soon as the
code starts to stabilize, they don't upgrade that often, and they need
justifications for an upgrade. Right now, people running 2.6.25 would
have no reason not to upgrade, considering the variety of fixes each
version still carries. People running 2.4 or 2.6.16 *need* details.
And that's even more true for people maintaining their own kernels
or backporting fixes.

However, there is a point nobody has evocated here about backports.
For a long time I've been annoyed by not finding enough information
in some commit logs. But I finally figured that it was as simple as
asking privately either the reporter or the patch author to get that
sensible information sorted out. So the only remaining hard part of
the problem is to identify possible candidates in the huge patch flow
that 2.6 mainline it. That's true too for pure bugs, except that, as
some people have already indicated, they're often better documented.

Willy

--
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/