LWN.net Logo

A /proc/PID/mem vulnerability

A /proc/PID/mem vulnerability

Posted Jan 26, 2012 14:47 UTC (Thu) by ortalo (subscriber, #4654)
Parent article: A /proc/PID/mem vulnerability

In my humble opinion, the full disclosure debate is only useful when it opposes to the unlawful attitude of some vendors who tries to negate the existence of vulnerabilities in their own products.

Outside of that situation, it seems (to me) to be a little pointless because focussed on a too small perimeter.

First I think at least as much, and possibly more energy should be spent on preventing the introduction of vulnerabilities than on setting up infrastructure or procedures for correcting them. For example, more talking on coding practices, auditing techniques, architectures with several layers of proection or the associated tools that prevent the introduction of bugs with a security impact; than on how to acquire/propagate the information concerning vulnerabilities. In short: work not to introduce vulnerabilities as much as removing them.

Furthermore, the information needed by an attacker is not necessarily the same as the information needed by a security officer, so the content of the disclosure information should be taken into account in the debate. But there is certainly little ROI to expect from this additional effort on writing vulnerability notes, esp. given the previous point.

Finally, the actual impact of full disclosure or embargo depends on the final security needs of a specific system: at home, maybe I am not so much impacted, at work on a highly valuable system, maybe I am. Or maybe the opposite, because the involved software is used at home and not at work. So, trying to get a definitive answer on the best procedure is most certainly impossible in the general case. Fortunately, there are many other things to do.


(Log in to post comments)

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds