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
Dark Reading Tech Digest, Dec. 19, 2014
Software-defined networking can be a net plus for security. The key: Work with the network team to implement gradually, test as you go, and take the opportunity to overhaul your security strategy.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-8142
Published: 2014-12-20
Use-after-free vulnerability in the process_nested_data function in ext/standard/var_unserializer.re in PHP before 5.4.36, 5.5.x before 5.5.20, and 5.6.x before 5.6.4 allows remote attackers to execute arbitrary code via a crafted unserialize call that leverages improper handling of duplicate keys w...

CVE-2013-4440
Published: 2014-12-19
Password Generator (aka Pwgen) before 2.07 generates weak non-tty passwords, which makes it easier for context-dependent attackers to guess the password via a brute-force attack.

CVE-2013-4442
Published: 2014-12-19
Password Generator (aka Pwgen) before 2.07 uses weak pseudo generated numbers when /dev/urandom is unavailable, which makes it easier for context-dependent attackers to guess the numbers.

CVE-2013-7401
Published: 2014-12-19
The parse_request function in request.c in c-icap 0.2.x allows remote attackers to cause a denial of service (crash) via a URI without a " " or "?" character in an ICAP request, as demonstrated by use of the OPTIONS method.

CVE-2014-2026
Published: 2014-12-19
Cross-site scripting (XSS) vulnerability in the search functionality in United Planet Intrexx Professional before 5.2 Online Update 0905 and 6.x before 6.0 Online Update 10 allows remote attackers to inject arbitrary web script or HTML via the request parameter.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Join us Wednesday, Dec. 17 at 1 p.m. Eastern Time to hear what employers are really looking for in a chief information security officer -- it may not be what you think.