The risk assessment of a system is crucial in applying the right controls, based on the risk tolerance of an organization. Although we want to believe full knowledge about any system is possible, however all systems are made up of subsystems of people, processes, and technology.
This paper will describe how the influence of individual's self-interest, when applied to the standards body processes, can inject critical vulnerability into our systems which can last for years. Sometimes these vulnerabilities are accidental, as in the case of Heartbleed.
HeartBleed:
This Heartbeat Extension for the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols was proposed as a standard in February 2012 by RFC 6520. It provides a way to test and 'keep alive' secure communication links without the need to renegotiate the connection each time. In 2011, one of the RFC's authors, Robin Seggelmann, then a Ph.D. student at the Fachhochschule MÂ<92>_nster, implemented the Heartbeat Extension for OpenSSL. Following Seggelmann's request to put the result of his work into OpenSSL, his change was reviewed by Stephen N. Henson, one of OpenSSL's four core developers. Henson failed to notice a bug in Seggelmann's implementation, and introduced the flawed code into OpenSSL's source code repository on December 31, 2011. The flaw spread with the release of OpenSSL version 1.0.1 on March 14, 2012. Heartbeat support was enabled by default, causing affected versions to be vulnerable.
Source Routing in IPv4
In another case, source routing is a technique which allows a sender of a packet to partially or completely specify the route the packet takes through the network. The result is the ability by an attacker to bypass security controls and detection systems. For IPv4, the initial introduction was with RFC 791, published in 1981, and later updated in 1992 with RFC 1348. It had taken 33 years before IETF created recommendations to filter this option via RFC 7126, in 2014.
Source Routing in IPv6
IPv6 Source routing, now called Type 0 Routing Header, was included in the initial RFC 2460 in 1998 after recognizing that this behavior was a problem with IPv4. During a presentation at the CanSecWest 2007 Security Conference in April 2007, a number of threats with regard to the IPv6 Type 0 Routing Header extension were described, including the negative impacts on Internet infrastructure elements. Later that month IETF created two drafts that were quickly assembled for review by the IPv6 working group. The first one, by Joe Abley, advocated for deprecation of the mechanism. The second one, by Pekka Savola and Georges Neville-Niel, proposed that a disable-by-default behavior be implemented. By June, IETF issued RFC 5095 to deprecate the use of type 0 routing header from IPv6.
In 2015, a CVE discussing a Software Crafted IPv6 Packet Denial of Service Vulnerability was published. This packet Type 0 Routing Header allowed an unauthenticated, remote attacker to trigger a scan of the Network Processor and a reload of the card processing an IPv6 packet.
The above is a small sample of vulnerabilities which this research tracked to decisions made in standard bodies.
Solution:
Security researchers must ask, and later validate which standards are included in their products, along with some history of the code. Today this is impossible, but with the introduction of DevSecOps, along with better historical review of standards and source code changes, this process could someday be automated.
Future Research:
This research plans on tracking back published vulnerabilities to understand the sources of the problem. With enough samples, identify a method to automate some portion of the research with the outcome of suggesting better ways to reduce vulnerability injection in the product development cycle.