Six more bugs found in popular OpenSSL security tool

The impact of this final bug is far less serious than Heartbleed. For an attacker, setting up to mount a man-in-the-middle attack is a considerable task in itself.

For this attack to work, both the server and the client application must use a vulnerable version of OpenSSL. Most popular Web browsers, the most common client applications, use an alternative to OpenSSL and are therefore not vulnerable.

What should regular Internet users do?
It appears that most regular users won’t have to take any action in response to this attack.

Some non-browser client applications (such as music players and chat programs) may need to be updated. This process will generally not require anything proactive on a regular user’s part if, as is standard, automatic updates are enabled. At most, you’ll be prompted to install an updated version of the affected software which will then be downloaded and installed. Various distributors of Linux, which makes wide use of OpenSSL, have already issued updates.

Any Internet accounts which are linked to such applications may require a password reset but again, users should be informed by the service provider of this requirement.

Websites may be unavailable for very short periods as fixed versions of OpenSSL are installed by their system administrators.

OpenSSL under the microscope (again)
When the Heartbleed bug was discovered, the programming community was both shocked and wryly amused at the elementary nature of the mistake.

Unfortunately, it seems to be something of a pattern. The DTLS vulnerability is caused by a mistake by the same German researcher and OpenSSL contributor and programmer, Robin Seggelmann, whose mistake caused the Heartbleed error. The new mistake is very similar in nature.

The fact that such a blatant and obvious mistake as the Heartbleed bug could make it into OpenSSL is, to borrow a phrase, the equivalent of “putting blood in the water” to security researchers.

For these individuals — professionals, university students and hobbyists — being the first to find and report a serious flaw in a high-profile application is a major achievement, in the same way that a paper published in Nature would be to a scientist.

The entire OpenSSL project, and particularly Seggelmann’s code, has therefore been under renewed scrutiny. We’re seeing some of the results with the collection of new vulnerabilities revealed this week.

In time, this process is likely to result in a much more secure OpenSSL. Work has also begun on a “fork” of OpenSSL by another development team. That means they have taken the existing OpenSSL code and begun working on it independently.

This new fork, LibreSSL, is managed by a development team renowned for their obsession with security; it will be interesting to see whether their modified version is widely adopted.

But in the short and medium term it seems likely that more flaws in OpenSSL will be discovered. Therefore, there is every chance that this process will be repeated at least once more.

Robert Merkel is Lecturer in Software Engineering at Monash University. This story is published courtesy of The Conversation  (under Creative Commons-Attribution/No derivatives).