CON7403 – ‘Heartbleed’ (CVE ) Case Study II Vulnerability Handling Perspective Bruce Lowenthal – Senior Director, Security Alerts Eric Maurice – Director, Oracle Security Assurance Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |

Program Agenda What is the ‘Heartbleed’ SSL vulnerability? How did the disclosure took place? Implications for vulnerabilities in 1/3rd party components? What are the lessons learned? What lessons can YOU derive for YOUR organization?

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Preliminary Remarks Today’s discussion came about as a unique opportunity We believe that any organizations can derive significant lessons from ‘Heartbleed’: – Secure development practices (see previous presentation) – Implications for dealing with vulnerabilities in third party components – Implications related to uncoordinated disclosure This presentation is the second of a 2-part session: – Heartbleed case study I: Secure Development Perspective – (Was on Wed. Oct. 1) – Heartbleed case study II: Vulnerability Handling Perspective – NOW 4

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Program Agenda What is the ‘Heartbleed’ SSL vulnerability? How did the disclosure took place? Implications for vulnerabilities in 1/3rd party components? What are the lessons learned? What lessons can YOU derive for YOUR organization?

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | CVE a.k.a. Heartbleed A vulnerability affecting certain versions of the OpenSSL TLS libraries: – OpenSSL through 1.0.1f (inclusive) are vulnerable A successful exploitation can result in allowing malicious attacker with the ability to remotely (over the Internet) read (sections of) the memory of the targeted system: – Possible compromise of secret keys and other sensitive information It was called ‘Heartbleed’ because the bug originated n the OpenSSL's implementation of the TLS/DTLS (transport layer security protocols) heartbeat enhancement 6 What is it?

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Tremendous visibility in the press and security community resulted in quick response The vulnerability was limited to only certain versions of OpenSSL The common use of TLS termination proxy (particularly with large sites) which used older versions of the library or didn’t use SSL provided some level of mitigation against successful exploitation 7 Why didn’t the world come to an end? Source:

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Large number of systems may be left vulnerable. Only about half affected Internet servers applied fixes after 3 months Sites that have applied OpenSSL April fixes have not all re-issued certificates and/or invalidated passwords 8 …But we have to remain vigilant Source: protection/heartbleed-to-blame-for-community-health- systems-breach.html

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Program Agenda What is the ‘Heartbleed’ SSL vulnerability? How did the disclosure took place? Implications for vulnerabilities in 1/3rd party components? What are the lessons learned? What lessons can YOU derive for YOUR organization?

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Lack of coordinated disclosure was a problem Heartbleed was essentially made public on April 7 th without notice to either the hundreds of thousands of vulnerable sites or to the vendors of products running on those sites Vendors scrambled to determine which products were vulnerable because many, probably most, did not have OpenSSL use records that could be easily queried After determining vulnerable sites and products, fixes had to be created, tested and distributed Three months later, product fixes are still being released Customers could not apply fixes for a considerable time 10

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Response Timeline 01Apr2014:Vulnerability discovered 07Apr2014:OpenSSL fix released and Oracle learned of issue 09Apr2014: to all Oracle SPOCs; MOS note published; Updates multiple times daily 14Apr2014:Note moved to Oracle.com 18Apr2014: sent to all customers 29Apr2014:Fixes available for all Oracle products - except 1 OEM product) 11 My Oracle Support and Oracle.com Online Reports 1,200 Service Requests Issue: Product Names Provided info for any requested product Five product status tables (counts final) Include OpenSSL, not vulnerable(136) Under investigation(0) Fixes available(20) Awaiting fixes(0) Do not include OpenSSL(244)

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Program Agenda What is the ‘Heartbleed’ SSL vulnerability? How did the disclosure took place? Implications for vulnerabilities in 1/3rd party components? What are the lessons learned? What lessons can YOU derive for YOUR organization?

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | For open source, the gloves are off Huge leverage for vulnerabilities found in commonly included 3 rd party components Common tools indicating included 3 rd party components available Compounded by ease of use of “Weaponizing” facilities such as MetaSploit 13 Enhanced focus of hackers against third-party libraries Source: library-risks-to-be-scrutinized-at-black-hat

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Lack of coordinated disclosure mechanism There is little pro-active communication regarding vulnerabilities in 3 rd party embedded components There are thousands of embedded 3 rd party components Compounded by abandoned support for many 3 rd party components – Example: Apache Attic: Struts1, Jakarta, Shale, XML Beans, …. 14

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Cost of security ownership of 3 rd party products 3 rd party products are used to reduce development costs Support costs may be reduced – But … support is not free -- as is often “planned” – Fixes delayed or support abandoned – Fixes issued unpredictably and possibly frequently For example, OpenSSL: – August 6, 2014: 1.0.1i – Jun e 5, 2014: 1.0.1h – April 7, 2014: 1.0.1g – January 6, 2014 :1.0.1f – February 11, 2013: 1.0.1e 15 – February 5, 2013: 1.0.1d – May 10,2012: 1.0.1c – April 26, 2012: 1.0.1b – April 19, 2012: 1.0.1a – March 14, 2012: 1.0.1

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Program Agenda What is the ‘Heartbleed’ SSL vulnerability? How did the disclosure took place? Implications for vulnerabilities in 1/3rd party components? What are the lessons learned? What lessons can YOU derive for YOUR organization?

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Providing Security with Included 3 rd Party Products Development: Only include Supported 3 rd party products – Through life of product (or make other plans for support) – Criteria: Fixes released at least once/year for last five years and no de-support notice? – Provide adequate staffing Development: Migration plans when products become de-supported – E.g. Struts 1 to some other facility Sustaining: Plan for frequent updates – Fast fix distribution with quick deployment in a form acceptable for customers 17

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Difficulties faced by some vendors related to the use of third-party components in their products Lack of 3 rd party component tracking in products – For both product versions and 3 rd party component versions – Many large vendors spent considerable time “investigating” 3 rd party component use Lack of notification infrastructure when fixes are released – Heartbleed was widely publicized but OpenSSL June and August releases were not Lack of notification when 3 rd party components become de-supported – No automation – Many times there is no de-support notice Replacement of support-abandoned 3 rd party components often expensive 18

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | ‘Heartbleed’ lessons for Oracle Although Oracle provided timely information about CVE : – Need more automation to quickly detect fix releases for 3rd party components – Need to improve ease of patch application – 3rd party component fix distributions not coordinated with Oracle fix schedule Oracle is considering new criteria for third party component inclusion: – Likelihood 3rd party embedded components are really supported for life of product? – Frequency of security fix releases (Too many, too delayed, too few)? – Ease of patching (e.g. forward compatibility enhancement policies)? Criteria for publishing “5 tables” – Must be Security Alert worthy (Attacks in progress or expected imminently) – Otherwise: Case by case basis 19

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Program Agenda What is the ‘Heartbleed’ SSL vulnerability? How did the disclosure took place? Implications for vulnerabilities in 1/3rd party components? What are the lessons learned? What lessons can YOU derive for YOUR organization?

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Key take-away actions 1.Open Source code is now under attack especially because discovered vulnerabilities can be leveraged against a great number of products – It was estimated that 17% of Internet servers were vulnerable to Heartbleed – Successful Heartbleed exploits occurred within three weeks of fix distribution – Users need to be quickly alerted when fixes are released and apply fixes in a timely manner 2.Make sure all deployed products and their components are supported – 3 rd party components often go out of support without notice – Many 3 rd party components do not have a policy of forward compatibility – Take great care in determining with 3 rd party components are used 21

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Key take-away actions (cont’d) Comments, concerns, questions? – 22

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. |23