Turing's Man Blog

From the Heartbleed bug through TOR to the OpenSSL fork. CVE-2014-0160 discussed

Bookmark and Share

In an interesting news from Ars Technica, which is directly related to recently discovered OpenSSL Heartbeat Vulnerability (CVE-2014-0160), we can read: […] More than a week after the revelation of a fatal flaw in the most recent versions of the OpenSSL cryptographic library—the encryption at the heart of much of the Internet's security — a large number of systems associated with the Tor anonymizing network remain unpatched and vulnerable to attack […]. However, there are more interesting consequences, of course.


No privacy for Tor, unless its server infrastructure is patched…

Without going too deep into the details of CVE-2014-0160 at this moment, we should notice that – first of all, Tor Project maintainers are working hard to secure the whole network, but at the same time:


a significant percentage of the relay servers, many of which serve countries with heavy Internet censorship, have remained unpatched. These systems are operated by volunteers and may run unattended. As of Thursday evening, 586 relays were still susceptible to Heartbleed, according to an ongoing census by Red Team—making up about 10 percent of the network's relay nodes.


Naturally, CVE-2014-0160 is not a Tor Project's only concern, but it is very interesting to watch what is the impact for such network, which is designed to provide anonymity for its users (that feature, honestly, might be very important in all non-democratic countries). We should now realize how this bug, which was discovered in tremendously popular OpenSSL cryptographic library, is potentially a huge threat for "very secured" Internet communication. Even Tor is affected.


… But first: no privacy for all, unless OpenSSL is patched!

Now, slowly going straight to the point, let's summarize according to The Heartbleed Bug website that:

Heartbleed bug is […] in the OpenSSL's implementation of the TLS/DTLS (transport layer security protocols) heartbeat extension (RFC6520). When it is exploited it leads to the leak of memory contents from the server to the client and from the client to the server. […]

This being said, we should already now that […] OpenSSL is the most popular open source cryptographic library and TLS (transport layer security) implementation used to encrypt traffic on the Internet. Your popular social site, your company's site, commerce site, hobby site, site you install software from or even sites run by your government might be using vulnerable OpenSSL. Many of online services use TLS to both to identify themselves to you and to protect your privacy and transactions. You might have networked appliances with logins secured by this buggy implementation of the TLS. Furthermore you might have client side software on your computer that could expose the data from your computer if you connect to compromised services. […]

What's more – […] The most notable software using OpenSSL are the open source web servers like Apache and nginx. The combined market share of just those two out of the active sites on the Internet was over 66% according to Netcraft's April 2014 Web Server Survey. Furthermore OpenSSL is used to protect for example email servers (SMTP, POP and IMAP protocols), chat servers (XMPP protocol), virtual private networks (SSL VPNs), network appliances and wide variety of client side software. Fortunately many large consumer sites are saved by their conservative choice of SSL/TLS termination equipment and software. Ironically smaller and more progressive services or those who have upgraded to latest and best encryption will be affected most. Furthermore OpenSSL is very popular in client software and somewhat popular in networked appliances which have most inertia in getting updates. […]

Therefore? Yes, we (end-users, too) are affected! We should consider this bug very seriously. To find out more information on how to secure ourselves? – please read The Heartbleed Bug website carefully. There are some options presented (from installing a fixed 1.0.1g or newer version of OpenSSL library to compiling a vulnerable version with -DOPENSSL_NO_HEARTBEATS parameter).


Heartbleed… How is bleeding the free heart of Internet security?

If we want to understand the details of Heartbleed bug, there is a great yet simple explanation available from the Fierce Outlaws video, available on YouTube – see below:


Well… Not only we are still a little bit confused about Internet security, the real power of publicly available encryption solutions (OpenSSL library included) and – moreover – our privacy at all, after the Snowden's whistleblowing revelations, there is yet another example how fragile all these complex and modern Internet technologies are. Even if someone can conclude that all the information provided by Snowden is nothing more than officially suspected practices (at least by many professionals in IT industry – and not only there), which – just – were never officially exposed before, one cannot say the same thing about CVE-2014-0160 bug without going deep into – so called – conspiracy theories.

Furthermore, we should learn that even such an "underground" project like Tor, aimed to secure everybody's privacy, is also vulnerable because of the same bug which affects the "real world" – a simple bug in the most popular open source cryptographic library, OpenSSL. Now, if we still cannot realize what is the real threat behind the Heartbleed, this seems to be a good idea to watch some additional videos, maybe a one with an easier explanation – like "How significant is security bug Heartbleed?" presented on PBS NewsHour YouTube channel, see below:

What we know about CVE-2014-0160 bug real impact?

At this time, we know that the vulnerable versions of OpenSSL are available for over two years now and they have been rapidly adopted by the vast majority of modern operating systems and their software components. Additionally, all the security experts, at least currently, agree there is no evidence that the CVE-2014-0160 bug has been successfully used for information leakage attacks. Therefore, there is a chance this bug was not exploited at all and was discovered just-in-time. Honestly? We don't have any evidence and as a result we cannot be sure.

So? Once again, we know enough to take the issue seriously and take care – without any evidence all the guessing has to be considered speculation only, but the problem remains unsolved as long as we don't secure our IT infrastructure.


Fork is the universal open source remedy? LibreSSL is comming

There is also an obvious consequence after the CVE-2014-0160 – as we can read in the ZDNet's article (titled: "OpenBSD forks, prunes, fixes OpenSSL") by Larry Seltzer:


Members of the OpenBSD project, already known for the OpenBSD operating system and related projects such as OpenSSH, OpenBGPD, OpenNTPD, OpenSMTPD, are creating a fork of the OpenSSL project, likely to be called LibreSSL


We should underline that – however strictly connected in some people's minds, because of OpenSSH – OpenBSD and OpenSSL projects are two different efforts, maintained by two separate groups of developers. Of course, it is easy to imagine how much OpenBSD (positioned as the most secure open source operating system) or OpenSSH (Open Secure Shell – used almost everywhere to remotely and securely work with the terminal consoles and make some more nice things – which should be separately presented) were impacted by recent OpenSSL library security issue. It's enough to be said, that after default OpenBSD installation there is only one service up and running which allows secure remote connection and further administration: OpenSSH (which is OpenSSL based). Not to mention other "secure" network services, which usually have to be provided from OpenBSD box with the usage of OpenSSL library (Apache with HTTPS anyone?). Now, let's add all other possible open source POSIX-compliant operating systems and OpenSSL-based software. Time to act! The fork of OpenSSL project is expected to appear soon from OpenBSD crew and this might be called: "LibreSSL".


LibreSSL begins with huge cleaning of OpenSSL

OpenBSD team decided to do something with the matter on their own and according to their own rules. As we can read in the same article, Theo de Raadt, the founder and the leader of OpenBSD and OpenSSH projects, told ZDNet that they've already removed 90,000 lines of C code and 150,000 lines of content, where:


Some of that is indentation, because we are trying to make the code more comprehensible. 99.99% of the community does not care for VMS support, and 98% do not care for Windows support. They care for POSIX support, so that the Unix and Unix derivatives can run. They don't care for FIPS. Code must be simple. Even after all those changes, the codebase is still API compatible. Our entire ports tree (8700 applications) continue to compile and work, after all these changes."



Open source is not a guarantee of ultimate security, but it can always… Fork!

Having the above statement in mind, we can try to summarize with the three conclusions.

First of all, the OpenSSL code seems not to be maintained and documented with the appropriate diligence for a critical component, which such library definitely is, not only in the world of open source solutions. Honestly, are there any programmers who like documenting their code? I guess not too many.

Secondly, the codebase of OpenSSL seems to be too huge, too open, too portable and, consequently, too hard to be clean and easy for continuous maintenance – as Theo de Raadt said: who cares about VMS support? Seems that OpenSSL has reached its "critical mass" when related to code complexity.

Thirdly, once again there is a question which has been raised in the past several times: how can we consider open source projects being "secure", if – although their code is easily accessible to anyone – no one is able to read and analyse the code from start to end. Moreover, even in such an important efforts like OpenSSL we, almost by-mistake, reveal a trivial bug… After more than two years of exposition. Honestly, there are many people who believe this bug is too simple to be made unintentionally by an experienced C coder.

At last, we should follow with the counter-argument to close this thread: maybe, in case of open source solutions like OpenSSL there is at least a chance to reveal such bugs, even after two years, where in the world of proprietary software all kinds of similar, potentially harmful bugs may not be revealed at all… However, such – unintended or not – special features can be utilized for ages without our knowledge by potential attackers. In fact, this is a good subject for quite another discussion, but what we've learned today – in case of open source we can always make a fork and start again!


Good luck OpenBSD!


OpenSSL Security Advisory [07 Apr 2014]

TLS heartbeat read overrun (CVE-2014-0160)

A missing bounds check in the handling of the TLS heartbeat extension can be
used to reveal up to 64k of memory to a connected client or server.

Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including
1.0.1f and 1.0.2-beta1.

Thanks for Neel Mehta of Google Security for discovering this bug and to
Adam Langley <This email address is being protected from spambots. You need JavaScript enabled to view it.> and Bodo Moeller <This email address is being protected from spambots. You need JavaScript enabled to view it.> for
preparing the fix.

Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately
upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.

1.0.2 will be fixed in 1.0.2-beta2.

 An official OpenSSL Security Advisory - as presented on OpenSSL website



Sources and additional reading:



Bookmark and Share

Add comment

Security code