Messages in this thread | | | Date | Sat, 19 Jul 2008 07:41:00 +0200 | From | Willy Tarreau <> | Subject | Re: [stable] Linux 2.6.25.10 |
| |
On Fri, Jul 18, 2008 at 06:51:42PM -0700, David Schwartz wrote: > 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 ?).
> > 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.
> 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
| |