DOCSLIB.ORG

Openssl Cryptographic Module Version 1.0 FIPS 140-2 Non

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Openssl Cryptographic Module Version 1.0 FIPS 140-2 Non OpenSSL Cryptographic Module version 1.0 FIPS 140-2 Non-Proprietary Security Policy Version 1.5 Last update: 2020-02-06 © 2020 Canonical Ltd. / atsec information security This document can be reproduced and distributed only whole and intact, including this copyright notice. OpenSSL Cryptographic Module FIPS 140-2 Non-Proprietary Security Policy Prepared by: atsec information security corporation 9130 Jollyville Road, Suite 260 Austin, TX 78759 www.atsec.com © 2020 Canonical Ltd. / atsec information security This document can be reproduced and distributed only whole and intact, including this copyright notice. 2 of 55 OpenSSL Cryptographic Module FIPS 140-2 Non-Proprietary Security Policy Table of Contents 1. Cryptographic Module Specification ....................................................................................................... 6 1.1. Module Overview .................................................................................................................................. 6 1.2. Modes of Operation ............................................................................................................................... 9 2. Cryptographic Module Ports and Interfaces ......................................................................................... 10 3. Roles, Services and Authentication ...................................................................................................... 11 3.1. Roles .................................................................................................................................................... 11 3.2. Services ................................................................................................................................................ 11 3.3. Algorithms ............................................................................................................................................ 13 3.3.1. Ubuntu 16.04 LTS 64-bit Little Endian Running on POWER System ............................................ 14 3.3.2. Ubuntu 16.04 LTS 64-bit Running on Intel® Xeon®/Atom® Processor ........................................ 18 3.3.3. Ubuntu 16.04 LTS 64-bit Running on z System ........................................................................... 25 3.3.4. Non-Approved Algorithms .......................................................................................................... 29 3.4. Operator Authentication ..................................................................................................................... 31 4. Physical Security .................................................................................................................................. 32 5. Operational Environment ..................................................................................................................... 33 5.1. Applicability ......................................................................................................................................... 33 5.2. Policy .................................................................................................................................................... 33 6. Cryptographic Key Management .......................................................................................................... 34 6.1. Random Number Generation .............................................................................................................. 34 6.2. Key Generation .................................................................................................................................... 35 6.3. Key Agreement / Key Transport / Key Derivation ................................................................................ 35 6.4. Key Entry / Output ............................................................................................................................... 36 6.5. Key / CSP Storage ................................................................................................................................. 36 6.6. Key / CSP Zeroization ........................................................................................................................... 36 7. Electromagnetic Interference/Electromagnetic Compatibility (EMI/EMC) ............................................ 37 8. Self-Tests ............................................................................................................................................. 38 8.1. Power-Up Tests .................................................................................................................................... 38 8.1.1. Integrity Tests .............................................................................................................................. 38 8.1.2. Cryptographic Algorithm Tests .................................................................................................... 38 8.2. On-Demand Self-Tests ......................................................................................................................... 39 8.3. Conditional Tests ................................................................................................................................. 39 9. Guidance .............................................................................................................................................. 41 © 2020 Canonical Ltd. / atsec information security This document can be reproduced and distributed only whole and intact, including this copyright notice. 3 of 55 OpenSSL Cryptographic Module FIPS 140-2 Non-Proprietary Security Policy 9.1. Crypto Officer Guidance ...................................................................................................................... 41 9.1.1. Operating Environment Configurations ...................................................................................... 41 9.1.2. Module Installation ..................................................................................................................... 42 9.2. User Guidance ...................................................................................................................................... 42 9.2.1. TLS ............................................................................................................................................... 42 9.2.2. AES GCM IV ................................................................................................................................. 43 9.2.3. AES XTS ........................................................................................................................................ 43 9.2.4. Random Number Generator ....................................................................................................... 43 9.2.5. API Functions ............................................................................................................................... 43 9.2.6. Environment Variables ................................................................................................................ 43 9.2.7. Handling FIPS Related Errors ....................................................................................................... 44 10. Mitigation of Other Attacks .................................................................................................................. 46 10.1. Blinding Against RSA Timing Attacks .................................................................................................... 46 10.2. Weak Triple-DES Keys Detection .......................................................................................................... 46 © 2020 Canonical Ltd. / atsec information security This document can be reproduced and distributed only whole and intact, including this copyright notice. 4 of 55 OpenSSL Cryptographic Module FIPS 140-2 Non-Proprietary Security Policy Copyrights and Trademarks Ubuntu and Canonical are registered trademarks of Canonical Ltd. Linux is a registered trademark of Linus Torvalds. © 2020 Canonical Ltd. / atsec information security This document can be reproduced and distributed only whole and intact, including this copyright notice. 5 of 55 OpenSSL Cryptographic Module FIPS 140-2 Non-Proprietary Security Policy 1. Cryptographic Module Specification This document is the non-proprietary FIPS 140-2 Security Policy for version 1.0 of the Ubuntu OpenSSL Cryptographic Module. It contains the security rules under which the module must operate and describes how this module meets the requirements as specified in FIPS PUB 140-2 (Federal Information Processing Standards Publication 140-2) for a Security Level 1 software module. The following sections describe the cryptographic module and how it conforms to the FIPS 140-2 specification in each of the required areas. 1.1. Module Overview The Ubuntu OpenSSL Cryptographic Module (hereafter referred to as “the module”) is a set of software libraries implementing the Transport Layer Security (TLS) protocol v1.0, v1.1 and v1.2 and Datagram Transport Layer Security (DTLS) protocol v.1.0 and v1.2, as well as general purpose cryptographic algorithms. The module provides cryptographic services to applications running in the user space of the underlying Ubuntu operating system through a C language Application Program Interface (API). The module utilizes processor instructions to optimize and increase performance. The module can act as a TLS server or client, and interacts with other entities
Load more

Recommended publications
  • Effective Cryptography What’S Wrong with All These Crypto Apis?
    Effective Cryptography What’s Wrong With All These Crypto APIs? Thorsten Groetker, CTO Utimaco, Inc. Utimaco IS Business Unit· Aachen, Germany · ©2015 Page 1 Outline § What I mean by Effective Cryptography § Crypto APIs § Security § Ease of Use § Runtime Performance § Predictions § CryptoScript in a Nutshell § Outlook Utimaco IS Business Unit· Aachen, Germany · ©2015 Page 2 Effective Cryptography Definition in a Nutshell Cryptography is effective if it is Li lingues es membres del sam familie. Lor separat existentie es 1. Secure unJCE/JCA myth. Por scientie, musica , sport etc, litot li sam vocabular. Li lingues differe solmen in li grammaticaOpenSSL, li pronunciation e li pluEVP commun vocabules. Omnicos directe al desirabilite de un nov lingua franca: On refusa continuar payar custosi traductores. At solmen va esser necessi 2. Efficient far uniform grammaticaPKCS#11, pronunciation e plu sommun paroles. Ma quande lingues coalesce, li grammatica del resultant lingue es plu CAPIsimplic e regulari quam ti del coalescent lingues. Li nov lingua CNG a. Time to Result franca va esser plu simplic e regulari quam li existent Bouncy linguesCastle. I b. Performance What’s wrong with all these crypto APIs? (Focused on Hardware Security Modules) Utimaco IS Business Unit· Aachen, Germany · ©2015 Page 3 Problem #1: Security PKCS#11 § Numerous key extraction attacks known § Jolyon Clulow “On the Security of PKCS#11” § Tookan project (e.g., “Attacking and Fixing PKCS#11 Security Tokens”) § CVE entries (not necessarily sporting “PKCS#11” in the text)
    [Show full text]
  • Secure Socket Layer (SSL) Transport Layer Security (TLS)
    Secure Socket Layer (SSL) Transport Layer Security (TLS) © André Zúquete Advanced Network Security TLS (Transport Layer Security, RFC 5246): Goals w Secure communication protocol over TCP/IP ® Standard inspired by SSL V3 (Secure Sockets Layer) ® Handles secure sessions per application over TCP/IP • Initially conceived for HTTP traffic • Currently being used by other kinds of traffic w Security mechanisms ® TCP payload protection • Confidentiality • Stream integrity ® Key distribution ® Peer authentication • Server authentication (the normal scenario) • Client authentication • Usually a person • Not usually explored © André Zúquete Advanced Network Security 1 Change Handshake Alert IMAP, Cipher Protocol Protocol HTTP Spec. etc. IMAP, TLS/SSL: HTTP etc. Protocols Record Protocol w Handshake Protocol TCP ® Key distribution • Master secrets (48 bytes) • Computed with DH; or • Chose by the client, upload to the server encrypted with the server’s public key • Session keys • Computed from a master secret and two nonces exchanged ® Peer authentication • Asymmetric encryption with long-term or ephemeral keys • Public key certificates for long-term public keys w Record Protocol ® Handling of secure data records ® Compression, confidentiality, integrity control © André Zúquete Advanced Network Security TLS/SSL versions w SSL ® 1.0 ® 2.0: 1995, prohibited by RFC 6176 (2011) ® 3.0: 1996, RFC 6101 (2011), deprecated by RFC 7568 (2015) w TLS ® 1.0: 1999: RFC 2246 SSL BEAST (2011) ® 1.1: 2006: RFC 4346 ® 1.2: 2008: RFC 5246 ® 1.3: 2018: RFC 8446 © André
    [Show full text]
  • ROADS and BRIDGES: the UNSEEN LABOR BEHIND OUR DIGITAL INFRASTRUCTURE Preface
    Roads and Bridges:The Unseen Labor Behind Our Digital Infrastructure WRITTEN BY Nadia Eghbal 2 Open up your phone. Your social media, your news, your medical records, your bank: they are all using free and public code. Contents 3 Table of Contents 4 Preface 58 Challenges Facing Digital Infrastructure 5 Foreword 59 Open source’s complicated relationship with money 8 Executive Summary 66 Why digital infrastructure support 11 Introduction problems are accelerating 77 The hidden costs of ignoring infrastructure 18 History and Background of Digital Infrastructure 89 Sustaining Digital Infrastructure 19 How software gets built 90 Business models for digital infrastructure 23 How not charging for software transformed society 97 Finding a sponsor or donor for an infrastructure project 29 A brief history of free and public software and the people who made it 106 Why is it so hard to fund these projects? 109 Institutional efforts to support digital infrastructure 37 How The Current System Works 38 What is digital infrastructure, and how 124 Opportunities Ahead does it get built? 125 Developing effective support strategies 46 How are digital infrastructure projects managed and supported? 127 Priming the landscape 136 The crossroads we face 53 Why do people keep contributing to these projects, when they’re not getting paid for it? 139 Appendix 140 Glossary 142 Acknowledgements ROADS AND BRIDGES: THE UNSEEN LABOR BEHIND OUR DIGITAL INFRASTRUCTURE Preface Our modern society—everything from hospitals to stock markets to newspapers to social media—runs on software. But take a closer look, and you’ll find that the tools we use to build software are buckling under demand.
    [Show full text]
  • Using Frankencerts for Automated Adversarial Testing of Certificate
    Using Frankencerts for Automated Adversarial Testing of Certificate Validation in SSL/TLS Implementations Chad Brubaker ∗ y Suman Janay Baishakhi Rayz Sarfraz Khurshidy Vitaly Shmatikovy ∗Google yThe University of Texas at Austin zUniversity of California, Davis Abstract—Modern network security rests on the Secure Sock- many open-source implementations of SSL/TLS are available ets Layer (SSL) and Transport Layer Security (TLS) protocols. for developers who need to incorporate SSL/TLS into their Distributed systems, mobile and desktop applications, embedded software: OpenSSL, NSS, GnuTLS, CyaSSL, PolarSSL, Ma- devices, and all of secure Web rely on SSL/TLS for protection trixSSL, cryptlib, and several others. Several Web browsers against network attacks. This protection critically depends on include their own, proprietary implementations. whether SSL/TLS clients correctly validate X.509 certificates presented by servers during the SSL/TLS handshake protocol. In this paper, we focus on server authentication, which We design, implement, and apply the first methodology for is the only protection against man-in-the-middle and other large-scale testing of certificate validation logic in SSL/TLS server impersonation attacks, and thus essential for HTTPS implementations. Our first ingredient is “frankencerts,” synthetic and virtually any other application of SSL/TLS. Server authen- certificates that are randomly mutated from parts of real cer- tication in SSL/TLS depends entirely on a single step in the tificates and thus include unusual combinations of extensions handshake protocol. As part of its “Server Hello” message, and constraints. Our second ingredient is differential testing: if the server presents an X.509 certificate with its public key.
    [Show full text]
  • Libressl Presentatie2
    Birth of LibreSSL and its current status Frank Timmers Consutant, Snow B.V. Background What is LibreSSL • A fork of OpenSSL 1.0.1g • Being worked on extensively by a number of OpenBSD developers What is OpenSSL • OpenSSL is an open source SSL/TLS crypto library • Currently the de facto standard for many servers and clients • Used for securing http, smtp, imap and many others Alternatives • Netscape Security Services (NSS) • BoringSSL • GnuTLS What is Heartbleed • Heartbleed was a bug leaking of private data (keys) from both client and server • At this moment known as “the worst bug ever” • Heartbeat code for DTLS over UDP • So why was this also included in the TCP code? • Not the reason to create a fork Why did this happen • Nobody looked • Or at least didn’t admit they looked Why did nobody look • The code is horrible • Those who did look, quickly looked away and hoped upstream could deal with it Why was the code so horrible • Buggy re-implementations of standard libc functions like random() and malloc() • Forces all platforms to use these buggy implementations • Nested #ifdef, #ifndefs (up to 17 layers deep) through out the code • Written in “OpenSSL C”, basically their own dialect • Everything on by default Why was it so horrible? crypto_malloc • Never frees memory (Tools like Valgrind, Coverity can’t spot bugs) • Used LIFO recycling (Use after free?) • Included debug malloc by default, logging private data • Included the ability to replace malloc/free at runtime #ifdef trees • #ifdef, #elif, #else trees up to 17 layers deep • Throughout the complete source • Some of which could never be reached • Hard to see what is or not compiled in 1.
    [Show full text]
  • Hannes Tschofenig
    Securing IoT applications with Mbed TLS Hannes Tschofenig Part#2: Public Key-based authentication March 2018 © 2018 Arm Limited Munich Agenda • For Part #2 of the webinar we are moving from Pre-Shared Secrets (PSKs) to certificated-based authentication. • TLS-PSK ciphersuites have • great performance, • low overhead, • small code size. • Drawback is the shared key concept. • Public key cryptography was invented to deal with this drawback (but itself has drawbacks). 2 © 2018 Arm Limited Public Key Infrastructure and certificate configuration © 2018 Arm Limited Public Key Infrastructure Various PKI deployments in existence Structure of our PKI The client has to store: self-signed • Client certificate plus corresponding private key. CA cert • CA certificate, which serves as the trust anchor. The server has to store: Signed by CA Signed by CA • Server certificate plus corresponding private key. Client cert Server cert (Some information for authenticating the client) 4 © 2018 Arm Limited Generating certificates (using OpenSSL tools) • When generating certificates you will be prompted to enter info. You are about to be asked to enter information that will be • The CA cert will end up in the trust incorporated into your certificate request. What you are about to enter is what is called a Distinguished anchor store of the client. Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, • The Common Name used in the server If you enter '.', the field will be left blank. ----- cert needs to be resolvable via DNS Country Name (2 letter code) [AU]:.
    [Show full text]
  • Mac OS X Server Administrator's Guide
    034-9285.S4AdminPDF 6/27/02 2:07 PM Page 1 Mac OS X Server Administrator’s Guide K Apple Computer, Inc. © 2002 Apple Computer, Inc. All rights reserved. Under the copyright laws, this publication may not be copied, in whole or in part, without the written consent of Apple. The Apple logo is a trademark of Apple Computer, Inc., registered in the U.S. and other countries. Use of the “keyboard” Apple logo (Option-Shift-K) for commercial purposes without the prior written consent of Apple may constitute trademark infringement and unfair competition in violation of federal and state laws. Apple, the Apple logo, AppleScript, AppleShare, AppleTalk, ColorSync, FireWire, Keychain, Mac, Macintosh, Power Macintosh, QuickTime, Sherlock, and WebObjects are trademarks of Apple Computer, Inc., registered in the U.S. and other countries. AirPort, Extensions Manager, Finder, iMac, and Power Mac are trademarks of Apple Computer, Inc. Adobe and PostScript are trademarks of Adobe Systems Incorporated. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. Netscape Navigator is a trademark of Netscape Communications Corporation. RealAudio is a trademark of Progressive Networks, Inc. © 1995–2001 The Apache Group. All rights reserved. UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company, Ltd. 062-9285/7-26-02 LL9285.Book Page 3 Tuesday, June 25, 2002 3:59 PM Contents Preface How to Use This Guide 39 What’s Included
    [Show full text]
  • Open Source Documentation Used in WAP4410N, Version 2.0.5.X
    Open Source Used In WAP4410N 2.0.5.x This document contains the licenses and notices for open source software used in this product. With respect to the free/open source software listed in this document, if you have any questions or wish to receive a copy of the source code to which you are entitled under the applicable free/open source license(s) (such as the GNU Lesser/General Public License) , please contact us at http://www.cisco.com/go/smallbiz_opensource_request. In your requests please include the following reference number 78EE117C99-24342489 En ce qui a trait au logiciel gratuit ou à exploitation libre figurant dans ce document, si vous avez des questions ou souhaitez recevoir une copie du code source, auquel vous avez droit en vertu des licences gratuites ou d'exploitation libre applicables (telles que licences GNU Lesser/General Public), veuillez communiquer avec nous à l'adresse http://www.cisco.com/go/smallbiz_opensource_request. Dans vos demandes, veuillez inclure le numéro de référence 78EE117C99-24342489 Contents 1.1 ag7100 1.0 1.1.1 Available under license 1.2 binutils 2.16.1 1.2.1 Available under license 1.3 busybox 1.1.0 1.3.1 Available under license 1.4 ccache 2.4 78-20798-01 Open Source Used In WAP4410N 2.0.5.x 1 1.4.1 Available under license 1.5 dhcp 0.1 1.5.1 Available under license 1.6 gcc 3.4.4 1.6.1 Available under license 1.7 genext2fs 1.3 1.7.1 Available under license 1.8 hostapd 0.5.9 1.8.1 Available under license 1.9 libiconv 1.8 1.9.1 Available under license 1.10 libupnp 1.2.1 1.10.1 Available under license
    [Show full text]
  • Notices Openssl/Open SSL Project
    Notices The following notices pertain to this software license. OpenSSL/Open SSL Project This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/). This product includes cryptographic software written by Eric Young ([email protected]). This product includes software written by Tim Hudson ([email protected]). License Issues The OpenSSL toolkit stays under a dual license, i.e. both the conditions of the OpenSSL License and the original SSLeay license apply to the toolkit. See below for the actual license texts. Actually both licenses are BSD-style Open Source licenses. In case of any license issues related to OpenSSL please contact [email protected]. OpenSSL License: Copyright © 1998-2007 The OpenSSL Project. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions, and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. All advertising materials mentioning features or use of this software must display the following acknowledgment: “This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/)”. 4. The names “OpenSSL Toolkit” and “OpenSSL Project” must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact [email protected].
    [Show full text]
  • Post-Quantum Authentication in Openssl with Hash-Based Signatures
    Recalling Hash-Based Signatures Motivations for Cryptographic Library Integration Cryptographic Libraries OpenSSL & open-quantum-safe XMSS Certificate Signing in OpenSSL / open-quantum-safe Conclusions Post-Quantum Authentication in OpenSSL with Hash-Based Signatures Denis Butin, Julian Wälde, and Johannes Buchmann TU Darmstadt, Germany 1 / 26 I Quantum computers are not available yet, but deployment of new crypto takes time, so transition must start now I Well established post-quantum signature schemes: hash-based cryptography (XMSS and variants) I Our goal: make post-quantum signatures available in a popular security software library: OpenSSL Recalling Hash-Based Signatures Motivations for Cryptographic Library Integration Cryptographic Libraries OpenSSL & open-quantum-safe XMSS Certificate Signing in OpenSSL / open-quantum-safe Conclusions Overall Motivation I Networking requires authentication; authentication is realized by cryptographic signature schemes I Shor’s algorithm (1994): most public-key cryptography (RSA, DSA, ECDSA) breaks once large quantum computers exist I Post-quantum cryptography: public-key algorithms thought to be secure against quantum computer attacks 2 / 26 Recalling Hash-Based Signatures Motivations for Cryptographic Library Integration Cryptographic Libraries OpenSSL & open-quantum-safe XMSS Certificate Signing in OpenSSL / open-quantum-safe Conclusions Overall Motivation I Networking requires authentication; authentication is realized by cryptographic signature schemes I Shor’s algorithm (1994): most public-key
    [Show full text]
  • Using Unsniff Network Analyzer to Analyze SSL / TLS
    Whitepaper – SSL / TLS Analysis using Unsniff Network Analyzer Whitepaper : Using Unsniff Network Analyzer to analyze SSL / TLS A number of applications today use SSL and TLS as a security layer. Unsniff allows authorized users to analyze these applications by decrypting the SSL/TLS streams in real time. This is done without interrupting the SSL streams in any way. Unsniff can also strip out the SSL/TLS layer completely and analyze the application protocols as if the security layer never existed. For example: If you are working with a secure web server, you can analyze the HTTPS protocol, including the ability to reconstruct complete web pages. References : RFC2246 (TLS 1.0), RFC2459 (X.509v3), PKCS Standards (RSA Website) Feature overview Working with PDUs and Streams Decrypting SSL/TLS Analyzing upper layer protocols Howto : Analyzing a secure Microsoft IIS web server Howto : Analyzing a secure Apache web server Howto : Analyzing protocols tunneled via stunnel FAQ 1/12 © Unleash Networks, All rights reserved Whitepaper – SSL / TLS Analysis using Unsniff Network Analyzer Feature Overview Unsniff shows SSL/TLS records as separate entities in the PDU sheet irrespective of SSL records how they were carried at the link layer. Stream Monitor entire SSL / TLS sessions in real time via the Streams sheet. analysis Provided you have the servers private key material you can decrypt SSL / TLS Decryption sessions in real time. Most of the popular ciphers are supported. Advanced Unsniff supports SSL / TLS features such as session reuse and cipher renegotiation. Decryption SSL/TLS only acts as a transport layer for higher layer protocols. Ultimately we are interested in the analysis of higher layer protocols such as HTTP, LDAP etc.
    [Show full text]
  • Securing Mysql with a Focus on SSL
    Securing MySQL! With a Focus on SSL http://www.yassl.com (206) 369-4800 About Me Chris Conlon So#ware Developer at yaSSL Bozeman, MT © Copyright 2011 FishEyeGuyPhotography © Copyright 2011 yaSSL SSL Statistics Ivan Ristic: Internet SSL Survey 2010 http://www.ssllabs.com SSL Survey 2010 Valid SSL – 0.42% •" Sample of 119 Million Domain Names 0.60%, Certificate Name Matches 0.42%, Counting only valid ones Alexa Top 1M •" Alexa Top 1M Sites Use SSL – 12% 120,000 Use SSL (12%) © Copyright 2011 yaSSL Presentation Outline Part I: MySQL Security 1." Common Attacks & Vulnerabilities 2." Good Security Practices for MySQL Part II: SSL/TLS 1." Overview of SSL and TLS 2." Configuring and Building MySQL with SSL 3." MySQL SSL Command Options 4." SSL Certificate Creation 5." Performance Comparison Part III: Additional Security Concerns 1." Data Storage and Encryption Part IV: Wrap-Up 1." Licensing 2." yaSSL 3." Conclusion © Copyright 2011 yaSSL MySQL Updates Part I Account Passwords Test Databases mysqld MySQL Security Privileges © Copyright 2011 yaSSL Common Attacks and Vulnerabilities Do we really need to secure our MySQL database? YES! MySQL is Susceptible to Many Attacks: - Basic Attacks (empty password, etc.) - SQL Injection Attacks - Known MySQL Bugs and Vulnerabilities - Trojanning MySQL © Copyright 2011 yaSSL Good Security Practices for MySQL A. Keeping MySQL Version Up to Date An easy way to stay better protected: - New MySQL Patches, Bug Fixes, etc. - You should take advantage of updates © Copyright 2011 yaSSL Good Security Practices for MySQL 'MySQL' Vulnerabili1es By Year cvedetails.com (nvd.nist.gov) 16 2000 14 2001 2002 11 2003 10 2004 9 2005 8 2006 7 2007 6 6 6 2008 5 2009 3 2010 2011 © Copyright 2011 yaSSL Good Security Practices for MySQL •" yaSSL Vulnerabilities affecting MySQL in the past: CVE-2005-3731 Certificate Chain Processing CVE-2008-0227 Denial of Service (crash) CVE-2008-0226 Allowed Execution of Arbitrary Code CVE-2009-4484 Allowed Execution of Arbitrary Code, Denial of Service Possible © Copyright 2011 yaSSL Good Security Practices for MySQL B.
    [Show full text]