|||
When Steve Gibson talked on Security Now 398 about how few users’ Java plugins are actually up-to-date, this question hit me:
The problem with having all of these old Java versions running around is that attacks always get better. How much more sophisticated are the attacks of today than the attacks of just one year ago? Why, then, should anyone think a free browser plugin released today—even if it’s secure by today’s standards—will stand up to the attacks of one year from now?
Of course, vendors need to continue to do their best to write secure code in the first place, and release timely updates to fix errors that do make it into the wild. We also need to work on the ecosystem to make it easy for users to stay current—figure out what Apple is doing right, what Android is doing wrong, and how to apply those lessons to the browser plugin market. (I’m not just picking on Java—I’m thinking of Adobe Flash and Reader, too.) I’m not sure how to get end users to care about keeping these plugins up-to-date, but the problem deserves attention. Obviously, the major plugins now auto-update, which will help, but it’s not foolproof (I’m envisioning malware that intercepts update checks to keep vulnerable plugins in-the-wild longer).
What I’m proposing is that vendors build in an expiration date as a safety net, so if a user tries to run a 12-month-old plugin (which won’t happen if auto-update is working and the vendor is still maintaining the product), it displays an expiration message and instructions for how to get a new version. Obviously this doesn’t solve our current problems, but it should be part of a strategy to make sure we’re not still in the same boat a few years from now.