Fujitsu
Not logged in » Login
X

Please login

Please log in with your Fujitsu Partner Account.

Login


» Forgot password

Register now

If you do not have a Fujitsu Partner Account, please register for a new account.

» Register now

Recent Discussion:

NickBown | 22.12.2018, 14:18
We have come across this issue as well, and don't seem to have found a way around it (the server is ...
NickBown | 20.12.2018, 18:40
Hi everyoneWe've got an RX2540 M1 which won't boot past the Fujitsu splash screen (which shows the i...
MarkM | 15.10.2018, 11:33
Hi there.I do not believe the Fujitsu policy on this subject has changed.So NO you can not order dri...
Apr 30 2014

Heartbleed – A Digital Nightmare

Since the disclosure of the devastating OpenSSL vulnerability, Internet users and ICT companies either seem to be caught in a shock and awe state or struggling to reestablish system and product security. And if you trust security analysts on the matter, the situation won't change anytime soon – despite the plethora of patches that were handed out over the past three weeks.

Whether the so-called Heartbleed bug is indeed a "DBA for Internet encryption," as some experts suggest, or whether its impact is somewhere below that level still remains to be seen. The only thing that's clear at the moment is that just a year ago reports about the vulnerability and ways to fix it would hardly have made the headline news. In the post-Snowden era, however, users prefer being informed over being left in the dark – so developers and ICT companies no longer have the option to keep quiet and 'fix things' behind the scenes. That's primarily a good thing. Still, the comparatively fast and full disclosure as well as the detailed analyses of what seems to be a relatively simple mistake raise more questions than they answer – questions about the overall quality of network protocols and encryption programs, about the depth of code reviews that preceded the implementation of OpenSSL into commercial products, and ultimately about the ways in which we design software that's not only business-critical, but can literally help save lives – whether it's used by dissidents in authoritarian states or to protect our own "critical infrastructure sectors."

Simple Mistake with Monstrous Impact
In the unlikely event you haven't heard about Heartbleed, here's a short definition from our colleague Chris Williams who works for the British IT news service The Register:

  • "This serious flaw (CVE-2014-0160) is a missing bounds check before a memcpy() call that uses non-sanitized user input as the length parameter. An attacker can trick OpenSSL into allocating a 64KB buffer, copy more bytes than is necessary into the buffer, send that buffer back, and thus leak the contents of the victim's memory, 64KB at a time."

At first sight this may seem like a rather simple mistake that only affects companies running open source web servers that rely on the flawed OpenSSL versions 1.0.1 through 1.0.1f. (Earlier versions were not affected, and the vulnerability has been fixed in OpenSSL 1.0.1g.) . But unfortunately, it's not that easy, because OpenSSL was supposed to serve as a security mechanism in numerous hard- and software products from leading ICT vendors, among them Akamai, Apple, Cisco, Google, Juniper Networks, NetApp, Oracle, and VMware. What's more, the bug also affected providers of online backup and document sharing services, such as Dropbox. As if all of this wasn't bad enough already, Siemens reported that some of its SCADA and automation systems, Ethernet communications processors, and industrial Ethernet switches could fall victim to an exploit as well – products that are typically used for process and network control and monitoring in  the chemical industry, agriculture and food production, and the utilities sector (namely energy, water and sewage systems). In short, the range and scope of the affected processes indicates that Heartbleed is exactly the kind of nightmare that critics of the digital age have warned us about for years.

Truths and Consequences
What, then, can be done to avoid or at least mitigate the resulting security risks – other than patching vulnerable OpenSSL implementations – and prevent similar troubles occur in future? To answer this question, we need to look at the history of the bug. Thankfully, Robin Seggelmann – the onetime OpenSSL developer who wrote the perilous code – has spoken out about how it all happened in interviews with the Sydney Morning Herald and the Guardian:

  • "'I was working on improving OpenSSL and submitted numerous bug fixes and added new features,' he said. 'In one of the new features (a heartbeat extension previously unknown to TLS/DTLS communication protocols, N.B.), unfortunately, I missed validating a variable containing a length.' After he submitted the code, a reviewer 'apparently also didn't notice the missing validation,' Dr. Seggelmann said, 'so the error made its way from the development branch into the released version.' Logs show that reviewer was Dr. Stephen Henson. Dr. Seggelmann said the error he introduced was 'quite trivial,' but acknowledged that its impact was 'severe.'"

While Seggelmann's confessions are certainly welcome, they say little about the working conditions that allowed for the malfunction to slip through and become part of an IETF standard, which appear devastating to begin with. At the time of the code review in early 2012, Henson was one of only four core team members overseeing OpenSSL development – nowadays there are three. This is more than just a flaw in project governance; it's a sign that OpenSSL has been chronically underfunded for years, which in turn means that the ICT industry has outright neglected the development of a secure communications standard that is absolutely crucial if its constant push for cloud infrastructures and an "Internet of Things" is intended to be successful in the long run. Against this backdrop, it was reassuring to learn that the Linux Foundation and a number of key partners – including Fujitsu, IBM, and Dell – have formed the Core Infrastructure Initiative, a project supposed to "collaboratively identify and fund open source projects that are in need of assistance" and endowed it with US-$3.9 million.

With this initiative in the making, one might normally conclude that all is well again and we just need to move forward together. But in an era where IT security and privacy are so obviously at risk, one industry-wide infrastructure project will not achieve a lot, for two main reasons. One is that $3.9 million will hardly suffice to cure the problems of every ill financed, but strategically relevant open source project the group may find. The other is that no collaborative effort can eliminate poor code reviews and standards implementation at the company level – this task is left to each individual developer team that proudly counts itself among the best in the world.

 

 
SHARE

Comments on this article

No comments yet.

Please Login to leave a comment.