Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

8/14/2014
12:00 PM
John Rostern
John Rostern
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
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: Strategist
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?
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/25/2020
9 Tips to Prepare for the Future of Cloud & Network Security
Kelly Sheridan, Staff Editor, Dark Reading,  9/28/2020
Malware Attacks Declined But Became More Evasive in Q2
Jai Vijayan, Contributing Writer,  9/24/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15216
PUBLISHED: 2020-09-29
In goxmldsig (XML Digital Signatures implemented in pure Go) before version 1.1.0, with a carefully crafted XML file, an attacker can completely bypass signature validation and pass off an altered file as a signed one. A patch is available, all users of goxmldsig should upgrade to at least revisio...
CVE-2020-4607
PUBLISHED: 2020-09-29
IBM Security Secret Server (IBM Security Verify Privilege Vault Remote 1.2 ) could allow a local user to bypass security restrictions due to improper input validation. IBM X-Force ID: 184884.
CVE-2020-24565
PUBLISHED: 2020-09-29
An out-of-bounds read information disclosure vulnerabilities in Trend Micro Apex One may allow a local attacker to disclose sensitive information to an unprivileged account on vulnerable installations of the product. An attacker must first obtain the ability to execute low-privileged code on the ...
CVE-2020-25770
PUBLISHED: 2020-09-29
An out-of-bounds read information disclosure vulnerabilities in Trend Micro Apex One may allow a local attacker to disclose sensitive information to an unprivileged account on vulnerable installations of the product. An attacker must first obtain the ability to execute low-privileged code on the ...
CVE-2020-25771
PUBLISHED: 2020-09-29
An out-of-bounds read information disclosure vulnerabilities in Trend Micro Apex One may allow a local attacker to disclose sensitive information to an unprivileged account on vulnerable installations of the product. An attacker must first obtain the ability to execute low-privileged code on the ...