| |||||||||||||
|
| |||||||||||||
The brk() vulnerabilityThe brk() vulnerabilityPosted Dec 2, 2003 19:04 UTC (Tue) by JoeBuck (subscriber, #2330)Parent article: The brk() vulnerability
The problem with doing kernel maintainance in public is that the bad guys are watching. Every commit to the source control system that fixes a flaw is an opportunity for a cracker to ponder whether unpatched systems can be exploited. I fear that publicity surrounding this particular exploit will alert others to this way of finding new cracks. Of course, the kernel maintainers are already aware of this possibility, so they will be more cautious when they are conscious that they are fixing a security hole. But any missing integrity check might make an exploit possible.
(Log in to post comments)
The brk() vulnerability Posted Dec 2, 2003 19:14 UTC (Tue) by beejaybee (guest, #1581) [Link] 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!
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 (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 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.
The brk() vulnerability Posted Dec 4, 2003 5:52 UTC (Thu) by brouhaha (subscriber, #1698) [Link] The problem with doing kernel maintainance in public is that the bad guys are watching.The problem with doing kernel maintenance secretly (e.g., proprietary kernels such as that of Windows) is that it's a little harder for the bad guys to find exploits, but it's a lot harder (effectively impossbile) for the good guys to audit the code to discover and fix weaknesses before they are used for attacks. Like any engineering decision, it is a tradeoff. Most people that don't have a vested interest in promoting proprietary software believe that the open development model results in better security. The studies Microsoft has funded that claim Linux security is worse reach that conclusion based purely on the number of advisories issued, ignoring the fact that the number of advisories is not a measure or even a good predictor of the number of remaining vulnerabilities in the software.
|
|
||||||||||||