Risk
8/14/2014
12:00 PM
John Rostern
John Rostern
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
50%
50%

Why Patching Makes My Heart Bleed

Heartbleed was a simple mistake that was allowed to propagate through "business as usual" patching cycles and change management. It could easily happen again.

Now that we have some chronological and emotional distance from the discovery and disclosure of the Heartbleed vulnerability, cyber security professionals can reflect on some elements of the root cause. As with any complex system, the cause-effect relationship is multi-faceted. At the "heart" of the matter is the reflexive upgrade/patching cycles embedded into the IT processes in most enterprises.

The Heartbleed vulnerability (CVE-2014-0160) in the OpenSSL cryptographic software library affects the security of information protected by Secure Socket Layer/Transport Layer Security (SSL/TLS). SSL/TLS supports secure communication over the Internet for applications such as web browsing, email, instant messaging (IM), and some virtual private network (VPN) implementations.

The vulnerability exists in the OpenSSL implementation of the TLS/DTLS Heartbeat extension as described in RFC 6520. Exploitation of this vulnerability allows access to memory exposing the private key used to establish the secure session. With this key, an attacker may be able to gain access to content in the secure SSL/TLS connection. This may compromise the authentication process by allowing access to usernames and passwords, as well as actual content. It can also allow an attacker to perform a man-in-the-middle attack and/or impersonate legitimate services and users.

The root cause was determined to be a programming error in OpenSSL in December 2011. The vulnerability has been "in the wild" since release 1.0.1 in March 2012. All versions of OpenSSL from 1.0.1 through 1.0.1f contain this vulnerability. OpenSSL 1.0.1g, which was released on April 7, 2014, corrects the problem. Other OpenSSL "branches" (0.9.8 and 1.0.0) are not vulnerable, since they were not affected by the programming error.

The context within which this vulnerability was introduced provides a wakeup call to cyber security and IT professionals. Thoughtful analysis leads to the following points:

  • A popular argument in favor of open source software is community review. The likelihood and impact of vulnerabilities, whether or not they were introduced maliciously, is thought to be mitigated by the public review process. Clearly, the time needed to discover the programming error and resulting vulnerability in the open community -- more than two years -- indicates that the process may not be effective and is certainly not timely.
  • Patching is driven by regulatory compliance requirements at the expense of the carefully considered introduction of changes into the environment. Many regulatory and compliance frameworks require that systems be "current" in terms of revisions/patches. This defeats the argument in many of these same frameworks for "business justification" for all changes. The DTLS functionality introduced in release 1.0.1 of SSL/TLS is not needed in many/most organizations.
  • Change management is not a mature or well-defined process in many organizations. Compliance mandates have led the change control and configuration management process in many organizations to focus on "filing the forms" to have the documentation ready to support an audit request. Few organizations perform meaningful testing prior to implementation in the production environment.

So what should the cybersecurity community be taking away from Heartbleed? I think there are three major action items.

  • Action Item No. 1: The widespread reliance on common open source software libraries creates a threat vector not assessed or accounted for in most organizations. The impact of cascading failures from single points such as OpenSSL should be assessed.
  • Action Item No. 2: More rigor must be implemented in the change control and configuration management process. This should focus on the business or technical need for the change, as well as the impact. The focus of this process must be to protect the integrity of production systems, as opposed to audit support.
  • Action Item No. 3: Compliance frameworks and standards need to recognize that the "latest" release/version is not always the most secure. This will require intelligent commentary and feedback in updating the widely varied frameworks that affect IT systems.

Heartbleed was a simple mistake that was allowed to propagate through "business as usual" patching and change management. A similar but innately malicious piece of code could easily exploit the same path.

John Rostern has more than 33 years of experience in audit, information security, and technology. His areas of expertise include IT audit, technology risk assessment and management, IT strategic planning, architecture, information security, operations, applications ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
bpaddock
50%
50%
bpaddock,
User Rank: Apprentice
8/15/2014 | 1:23:01 PM
Re: community fix

There are several things that would have found a double 'goto', had they been used:

First as simple as turning on all of the compiler warnings, and then allowing no warnings in code:

GCC:
#-Wunreachable-code
#Warn if the compiler detects that code will never be executed. [Seems to give bogus results]

# -Werror : Make all warnings into errors.

Follow a programming standard such as MISRA that is commonly used in the embedded space:


MISRA rule 14.1 does not permit unreachable code, as the second 'goto' would be unreachable:

http://www.misra.org.uk/

"Unreachable code:
Code is unreachable if the syntax does not permit the code to be accessed.

Infeasible code:
Code is infeasible code if the syntax allows it to be accessed but the semantics ensure that it cannot be reached whatever input data is provided.

Dead code:
Code is dead if it reachable and feasible, but has no effect on the outputs."

Then there any number of tools that can be used for static analysis such as Gimpel Software's Lint amoung others:

MSG#527 Unreachable code at token Symbol -- A portion of the program cannot be reached.

The problem is the many programmers find doing things correctly "cramp their style".

What will really cramp their style is when software developers will be required to have a license by the state.  If we don't clean up our own act, someone else will do it for us, and no one is going to like it...
soozyg
50%
50%
soozyg,
User Rank: Apprentice
8/15/2014 | 10:49:54 AM
community fix
Clearly, the time needed to discover the programming error and resulting vulnerability in the open community -- more than two years -- indicates that the process may not be effective and is certainly not timely.

Yes, I'm surprised no one noticed it sooner? Or did anything about it?
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2015-5084
Published: 2015-08-02
The Siemens SIMATIC WinCC Sm@rtClient and Sm@rtClient Lite applications before 01.00.01.00 for Android do not properly store passwords, which allows physically approximate attackers to obtain sensitive information via unspecified vectors.

CVE-2015-5352
Published: 2015-08-02
The x11_open_helper function in channels.c in ssh in OpenSSH before 6.9, when ForwardX11Trusted mode is not used, lacks a check of the refusal deadline for X connections, which makes it easier for remote attackers to bypass intended access restrictions via a connection outside of the permitted time ...

CVE-2015-5537
Published: 2015-08-02
The SSL layer of the HTTPS service in Siemens RuggedCom ROS before 4.2.0 and ROX II does not properly implement CBC padding, which makes it easier for man-in-the-middle attackers to obtain cleartext data via a padding-oracle attack, a different vulnerability than CVE-2014-3566.

CVE-2015-5600
Published: 2015-08-02
The kbdint_next_device function in auth2-chall.c in sshd in OpenSSH through 6.9 does not properly restrict the processing of keyboard-interactive devices within a single connection, which makes it easier for remote attackers to conduct brute-force attacks or cause a denial of service (CPU consumptio...

CVE-2015-1009
Published: 2015-07-31
Schneider Electric InduSoft Web Studio before 7.1.3.5 Patch 5 and Wonderware InTouch Machine Edition through 7.1 SP3 Patch 4 use cleartext for project-window password storage, which allows local users to obtain sensitive information by reading a file.

Dark Reading Radio
Archived Dark Reading Radio
What’s the future of the venerable firewall? We’ve invited two security industry leaders to make their case: Join us and bring your questions and opinions!