The brk() vulnerability

Posted Dec 2, 2003 23:00 UTC (Tue) by lacostej (subscriber, #2760) [Link]

Exactly. And with the open development of the kernel, it's not up to the maintainer to detect the risk of a fix, but it has to come has low/early as possible from the development process. Because as soon as a potential fix goes into the open, even before reaching the point where a maintainer must take a decision to include or not a patch, somebody may see and use this patch to find out a security problem.

The way I understand it, a maintainer is just follows some kind of agenda. He gets patches, like recommendations/ideas, and based on HIS own feelings, based on the fact that others have put their confidence on him to do a good job, he decides or not to accept/reject the fix. The more patches the less time to know about all the intricate details of every fix. That's why the security level of a patch must be assessed before they reach him, so that he can make the good decision. That's exactly like politics.

And to me, Marcelo does a great job, I am pretty happy with the 2.4 series. If he didn't put the fix in, it's because he didn't have all the information about the fix.

Because of the openess and increasing use of Linux and other open solutions, the number of attacks following this particular way of working will probably increase. It will also be used by the competition. This openess is one of the biggest weakness of open source, a weakness that also supposedly makes its greatness. People will try to turn that around. Make it an example.

Because of all that, perhaps some kind of patch security assessment policy should be introduced. Like patches should perhaps be tracked and reviewed with security in mind. That's thousands of patches, but we must probably be able to find a handful of detection hints sufficient to remove 80% of the risks.