Vulnerability History
Posted by jericho
Steven Christey (CVE) recently posted about vulnerability history and complexity. The recent sendmail vulnerability has brought up discussion about both topics and adds another interesting piece of history to the venerable sendmail package. One point to walk away with is that while sendmail has a long history of vulnerabilities, the last five years have shown the product to be considerably more secure. While overflows still haunt the ~ 25 year old software package, they are growing fewer and requiring considerably more complex methods to exploit them. The latest discovery is by no means a run-of-the-mill remote overflow, rather it takes considerable skill to find and exploit the flaw.
Using vulnerability history to help evaluate the current security posture of software is a bit sketchy, but certainly helps. If a program starts out with standard overflows, race conditions, symlink issues, XSS or SQL injections, it’s basically expected. If years pass and new versions of the same package continue to exhibit the same coding practices that lead to these vulnerabilities, you begin to get an idea of the quality of code as it relates to security. On the other hand, if years pass and the vulnerabilities are published with more time between each, and the difficulty exploiting them increases, it shows the developers are security conscious and producing more secure code. As always, the lack of published vulnerabilities in a product doesn’t mean it is free from defect, just that they possibly have not been found or published.
Fun fact: The first documented Sendmail vulnerability was on Aug 23, 1981.
This is indeed an interesting area. It is nice to see the progress of code quality over a period of time, and to see the improvements in the area of security. I don’t think there is really any negative impact here, unless of course the maintainers of the software are not keeping up and/or continue to make the same mistakes year after year, and update after update. I agree with you that utilizing a history log to evaulate the softwares security posture is indeed sketchy, but perhaps it does provide some valid proof that steps are being taken to ensure that vulnerabilities are at least being addressed.