Six more bugs found in popular OpenSSL security tool

June 6, 2014 by Robert Merkel, The Conversation
New bugs in the code for OpenSSL. Credit: Flickr/Guilherme Tavares, CC BY-NC

Computer system administrators around the world are groaning again as six new security problems have been found in the OpenSSL security library.

OpenSSL is a security tool that provides facilities to other computer programs to communicate securely over the public internet.

For example, if you see "https://" at the start of a web address rather than "http:", the "s" part indicates that the connection is secure. More often than not, at least the server computer on the other end of the connection will be using OpenSSL to provide that security.

OpenSSL provides two main forms of security:

  1. it scrambles information so it is unreadable to anyone other than the intended recipient
  2. it authenticates the source of information, ensuring the sender is who they say they are.

OpenSSL is also used in some common consumer applications, such as software in Google's Android smartphones.

So when the Heartbleed vulnerability in OpenSSL was discovered and widely publicised in April this year, had to rush to update their systems to protect against it.

The latest bugs

The OpenSSL developers, a loosely-connected group of volunteers who primarily collaborate online, announced this week an updated version of their tool with fixes to the six new vulnerabilities, each reported independently by security researchers around the world.

Of the six, four appear to only be exploitable for "denial-of-service" purposes. An attacker could cause a server running the vulnerable software to stop functioning.

But the other two bugs are more serious.

The first (explained in technical detail here) might, theoretically, allow an attacker to gain full control of a vulnerable server. At that point all data on that server becomes available to the attacker.

But this can only occur if a particular facility called Datagram Transport Layer Security (DTLS) of OpenSSL is in use. Fortunately this facility isn't used by the vast majority of applications using OpenSSL.

The second serious bug (technical explanation here and additional technical analysis here), has been present in OpenSSL for at least 15 years.

In essence, by sending certain messages through OpenSSL in the wrong order, a supposedly "secure" connection can be initiated with a known password. This can be used to establish a "man-in-the-middle" attack, where an attacker with access to the communication channel between a server and client can read and/ or modify any messages between them.

Unlike the DTLS vulnerability, clients and servers using OpenSSL in typical ways are vulnerable.

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 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 .

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.

Explore further: Heartbleed bug find triggers OpenSSL security advisory

Related Stories

Heartbleed bug find triggers OpenSSL security advisory

April 8, 2014

A flaw called Heartbleed in OpenSSL, which is a software library used for the protection and security of millions of websites, was uncovered by Neel Mehta of Google Security, who first reported it to the OpenSSL team, triggering ...

NSC backs disclosing software vulnerabilities

April 13, 2014

Disclosing vulnerabilities in commercial and open source software is in the national interest and shouldn't be withheld from the public unless there is a clear national security or law enforcement need, President Barack Obama's ...

'Heartbleed' bug a critical Internet illness

April 11, 2014

The "Heartbleed" flaw in Internet security is as critical as the name implies and wider spread than first believed. Warnings about the danger exposed early this week reached widening circles on Thursday, with everyone from ...

Recommended for you

Forget oil, Russia goes crazy for cryptocurrency

August 16, 2017

Standing in a warehouse in a Moscow suburb, Dmitry Marinichev tries to speak over the deafening hum of hundreds of computers stacked on shelves hard at work mining for crypto money.

Researchers clarify mystery about proposed battery material

August 15, 2017

Battery researchers agree that one of the most promising possibilities for future battery technology is the lithium-air (or lithium-oxygen) battery, which could provide three times as much power for a given weight as today's ...

Signs of distracted driving—pounding heart, sweaty nose

August 15, 2017

Distracted driving—texting or absent-mindedness—claims thousands of lives a year. Researchers from the University of Houston and the Texas A&M Transportation Institute have produced an extensive dataset examining how ...


Adjust slider to filter visible comments by rank

Display comments: newest first

not rated yet Jun 06, 2014
This gives new meaning to the "open" in open source.
not rated yet Jun 06, 2014
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.

The best case scenario is that it isn't, because it would only mean splitting available developer resources into maintaining two of the same thing.

This is the problem of "fork instead of fix" ethos typical of the Open Source community. Many eyes make all bugs shallow, but only if the many eyes are looking at the same code.

Please sign in to add a comment. Registration is free, and takes less than a minute. Read more

Click here to reset your password.
Sign in to get notified via email when new comments are made.