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?
News
US Formally Attributes SolarWinds Attack to Russian Intelligence Agency
Jai Vijayan, Contributing Writer,  4/15/2021
News
Dependency Problems Increase for Open Source Components
Robert Lemos, Contributing Writer,  4/14/2021
News
FBI Operation Remotely Removes Web Shells From Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/14/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-3506
PUBLISHED: 2021-04-19
An out-of-bounds (OOB) memory access flaw was found in fs/f2fs/node.c in the f2fs module in the Linux kernel in versions before 5.12.0-rc4. A bounds check failure allows a local attacker to gain access to out-of-bounds memory leading to a system crash or a leak of internal kernel information. The hi...
CVE-2021-20208
PUBLISHED: 2021-04-19
A flaw was found in cifs-utils in versions before 6.13. A user when mounting a krb5 CIFS file system from within a container can use Kerberos credentials of the host. The highest threat from this vulnerability is to data confidentiality and integrity.
CVE-2021-27458
PUBLISHED: 2021-04-19
If Ethernet communication of the JTEKT Corporation TOYOPUC product series’ (TOYOPUC-PC10 Series: PC10G-CPU TCC-6353: All versions, PC10GE TCC-6464: All versions, PC10P TCC-6372: All versions, PC10P-DP TCC-6726: All versions, PC10P-DP-IO TCC-6752: All versions, PC10B-P TCC-6373: Al...
CVE-2020-27241
PUBLISHED: 2021-04-19
An exploitable SQL injection vulnerability exists in ‘getAssets.jsp’ page of OpenClinic GA 5.173.3. The serialnumber parameter in the getAssets.jsp page is vulnerable to unauthenticated SQL injection. An attacker can make an authenticated HTTP request to trigger...
CVE-2021-3497
PUBLISHED: 2021-04-19
GStreamer before 1.18.4 might access already-freed memory in error code paths when demuxing certain malformed Matroska files.