Almost every software vendor today provides a dedicated web page or a bundled text file with their software outlining the latest “Release Notes”, “Version History” or “Change Log”, and listing the new features and improvements that are included in their latest software update.
Some lists are more detailed than others, but look a little closer at any of these and you can gain a real insight into the vendor’s attitude and general approach to the security of their product….
Here are 5 things to look for:
1) How long ago was the “latest” version of their software released?
A good Change Log should include the date when each incarnation and update of their product was first publicly available. Have a look at the date of their most “recent” update – would you consider it to be “recent”, or is it now several months/years old?
If their latest version isn’t all that “recent”, have a look at the dates on some of their other previous releases. If there have been frequent updates in the past, but none more recently, it brings into question whether the software is even still in active development? Perhaps development ground to a halt or the product been abandoned all together if the last update was over a couple of years ago?!
Obsolete or abandoned software should be avoided – there’s no two ways about it!
If a software product is no longer actively maintained and hasn’t been “recently” updated, then its quite possible that a security researcher or hacker has since been able to discover/exploit flaws in the software, which if the vendor is no longer providing updates to their software, will go unfixed. If you then choose to use the obsolete software, you potentially leave yourself exposed to unpatched security vulnerabilities.
2) Are software updates released on a fixed “rigid” scheduled?
Have a further look at the dates on the past few updates to their software – Can you see a pattern? Are updates released like clockwork on the same day every month, or the same date every 3 months, or are the dates more irregular?
If for the past few years they’ve religiously released 4 updates a year on say the 1st January, 1st April, 1st July, 1st October each year, this indicates a very inflexible and “rigid” release schedule. Whilst it’s good that they are committed to providing “regular” updates, having such a rigid release schedule with no interim updates means that security bugs may potentially not be fixed very quickly!
Let’s say the vendor releases an update on 1st January in a give year and their next scheduled update isn’t until 1st April, and then in the second week in January, a security researcher finds a serious security issue in the software and reports it to the vendor. If the vendor determines the security issue is real but doesn’t release a fix until their next “scheduled” release three months later, users of the software remain exposed and vulnerable to the vulnerability during that time.
A prime – and very topical example of this – is Oracle’s MySQL. Only yesterday, Dawid Golunski, a security researcher openly disclosed details about a serious security vulnerability he’d discovered in MySQL.
If you’re not familiar with MySQL, it’s is the world’s most popular open source database, used by over 70% of the world’s websites including big names like Facebook, Google, and Adobe.
There have been a couple of “spin offs” of MySQL too, namely PerconaDB and MariaDB. MySQL itself is now maintained by Oracle. PerconaDB and MariaDB are maintained by completely separate entities.
Dawid writes:
“The vulnerability was reported to Oracle on 29th of July 2016 and triaged by the security team.
It was also reported to the other affected vendors including PerconaDB and MariaDB.
The vulnerabilities were patched by PerconaDB and MariaDB vendors by the end of 30th of August.
During the course of the patching by these vendors the patches went into public repositories and the fixed security issues were also mentioned in the new releases which could be noticed by malicious attackers.
As over 40 days have passed since reporting the issues and patches were already mentioned publicly, a decision was made to start disclosing vulnerabilities … to inform users about the risks before the vendor’s next CPU update that only happens at the end of October.“
…so whilst PerconaDB and MariaDB had already released patches for their respective products before this vulnerability was made public, Oracle aren’t going to release a patch for MySQL for another month and a half!
Another example is Microsoft’s “Patch Tuesday“. As the name suggests, Microsoft ordinarily only release security patches on the second Tuesday of each month. However, to give Microsoft credit, on a few occasions they have previously released patches for very severe security issues outside of this schedule.
So with these examples in mind, have a look again at the dates in the Change Logs for your favorite software titles; are there some updates that don’t fit into their usual update “schedule” and perhaps only contain security fixes with no new features added? – This is a good thing! It demonstrates that the vendor takes a pro-active approach to addressing security issues as soon as practically possible.
3) How vague is the information contained in the Release Notes, Update History or Change Logs about fixed security issues?
Release Notes, Update Histories and Change Logs can often be lengthy – this is where Ctrl + F (or Cmd + F if you’re a Mac user!) is your friend! Try searching in them for the words “security” or “vulnerability”. Can’t find any occurrences? Maybe the software has no security vulnerabilities?(!) …or perhaps more realistically, the vendor perhaps doesn’t want to admit to any security flaws.
The first thing that software vendors should realize is that security flaws are to be expected – in ANY software. It doesn’t do the vendor’s reputation any harm to openly admit that a vulnerability may existed, which has since been fixed.
Because some vendors don’t like to admit that vulnerabilities have existed, they’ll try and cover these up in many cases with a simple non-obtrusive yet vague entry in the release notes stating the update perhaps just contains “Bug Fixes”. Now, these “Bug Fixes” may not all be security-related, but it’s a default “catch all” term that some vendors like to use that may also include security vulnerabilities.
Good software vendors are those who don’t hide behind vague terms like “Bug Fixes” or “Security Fixes”, but instead provide a unique bug or CVE (Common Vulnerabilities and Exposures) reference number for each issue together with links for users to find out further detailed specifics on each security issue that has been addressed by the update. They may also provide key dates in the information on each issue, including the date the security issue was first noticed/reported to them and the date by which it was fixed and an update made available to users. This is also a good indication of how pro-active a vendor is in responding to and addressing security issues.
However, do bear in mind that often a vendor won’t release specifics about a particular security issue until the majority of their users have had an opportunity to update and be protected against the issue. So have a look back through the Change Log for other security issues that have been addressed in the past – did the vendor subsequently provide plenty of information on these now historical security issues?
4) Are security patches/updates available for older versions?
There inevitably comes a time in every software product’s “life cycle” when it become uneconomical to continue adding new features to “older” versions of the product. For example, when version “3.0” is released, the vendor may stop adding new features to the previous “2.x” branch of their software.
However, if there are still a significant number of people still using an older version of their software, does the vendor still provide security fixes for these older versions? You should be able to determine this from the Version History/Change Log.
For instance, if the vendor has released an update for the current “3.x” branch of their software which contains a critical security fix, and at the same time they also update their older “2.x” branch of their software with the same fix – that’s a good thing!
If however, the vendor is no longer providing even critical security patches for their older versions, you’d be strongly advised to update to the latest version of their software as soon as possible!
5) Do Release Notes, Update Histories or Change Logs acknowledge/credit external reporters of security issues?
If security issues have been addressed in a software update, do the release notes credit the person who first reported the issue to the vendor?
Google Chrome’s Release Notes are a great example of this, and they also go one step further – Google provide monetary rewards (often referred to as “Bug Bounties”) to external researchers based upon the severity of the security issues they discover, and openly credit them in the Release Notes:
This is good, as it both demonstrates that Google are thankful and appreciative of the hard work that these security researchers do, and also encourages and motivates more reporting of security issues from other researchers.
In summary:
Looking at a software vendor’s Release Notes/Version History/Change Log, a good pro-active security-conscious vendor will:
- Release frequent software updates
- Not be afraid to release interim security updates as necessary
- Provide detailed information on resolved security issues
- Provide critical security patches for older versions of their software
- Encourage reporting of security issues
- Encourage users to keep their software up-to-date
Of course, the Release Notes/Version History/Change Log are only one element, and you shouldn’t base your entire assessment of a particular vendor’s attitude and approach to the security of their product(s) based solely on this. There many other ways to assess a software vendor’s approach to security (which I may well cover in future blog posts)… however, Release Notes, Version Histories, Change Logs – term them what you will – still provide an interesting and revealing insight into the software’s security!
So the next time you’re thinking of buying/downloading that new app or software program, take a few moments to browse its version history first.
Have you seen some good/bad examples of Release Notes, Version Histories, and Change Logs? Why not share them in the comments below…