| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
The brk() vulnerability
The brk() vulnerability
Posted Dec 2, 2003 19:14 UTC (Tue) by beejaybee (guest, #1581)In reply to: The brk() vulnerability by JoeBuck
Parent article: The brk() vulnerability
Sure - but it's better to do your washing in public than not to do it at all.
Let's prove ourselves better than the Windows admins by getting our systems patched reasonably quickly!
(Log in to post comments)
The brk() vulnerability
Posted Dec 2, 2003 20:21 UTC (Tue) by elanthis (subscriber, #6227) [Link]
This isn't really true. It's similar to how bugtraq and other security organizations give companies time to release fixed software before the announcement of the vulnerability is even made - the fix exists and users can download it, and have had ample time to do so, before most attackers even know there is a hole.With the open nature of the kernel developement, the "announcement" is out there before anyone but a few kernel developers have a chance to so much as know the patch exists.
Some good policy on keeping security fixes "secret" until after they're in a release (or at least -pre patch), and then keeping the details secret until the fix has been out for a while, could solve this problem. *could*.
The brk() vulnerability
Posted Dec 2, 2003 23:00 UTC (Tue) by lacostej (guest, #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.