************************************************************************** Security Bulletin 9813 DISA Defense Communications System June 25, 1998 Published by: DISN Security Coordination Center (SCC@NIC.MIL) 1-(800) 365-3642 DEFENSE INFORMATION SYSTEM NETWORK SECURITY BULLETIN The DISN SECURITY BULLETIN is distributed by the DISN SCC (Security Coordination Center) under DISA contract as a means of communicating information on network and host security exposures, fixes, and concerns to security and management personnel at DISN facilities. Back issues may be obtained via FTP from NIC.MIL [207.132.116.5] using login= "anonymous" and password="guest". The bulletin pathname is scc/sec-yynn (where "yy" is the year the bulletin is issued and "nn" is a bulletin number, e.g. scc/sec-9705.txt). These are also available at our WWW site, http://nic.mil. ************************************************************************** + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + ! ! ! The following important advisory was issued by the Computer ! ! Emergency Response Team (CERT) and is being relayed unedited ! ! via the Defense Information Systems Agency's Security ! ! Coordination Center distribution system as a means of ! ! providing DISN subscribers with useful security information. ! ! ! + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + ============================================================================= -----BEGIN PGP SIGNED MESSAGE----- ============================================================================= CERT* Advisory CA-98.07 Original issue date: June 26, 1998 Topic: Vulnerability in Some Usages of PKCS#1 - ----------------------------------------------------------------------------- The CERT Coordination Center has received a report regarding a vulnerability in some implementations of products utilizing RSA Laboratories' Public-Key Cryptography Standard #1 (PKCS#1). Under some situations, a sophisticated intruder may be able to use the vulnerability in PKCS#1 to recover information from SSL-encrypted sessions. The CERT/CC team recommends that sites install patches immediately as described in Appendix A. Appendix A also contains pointers to web pages containing additional information maintained by some vendors. We will update this advisory as we receive additional information. Please check our advisory files regularly for updates that relate to your site. - ----------------------------------------------------------------------------- I. Description PKCS#1 is a standard for encrypting data using the RSA public-key cryptosystem. Its intended use is in the construction of digital signatures and digital envelopes. One use for the digital envelopes constructed using PKCS#1 is to provide confidentiality during the session key negotiation of an SSL-encrypted session. The SSL protocol is widely used to encrypt traffic to and from web servers to protect the privacy of information such as personal data or a credit card number, as it traverses the internet. A sophisticated intruder may be able to use the vulnerability in PKCS#1 to recover information from an SSL-encrypted session. Web pages employing SSL are accessed using the HTTPS protocol, rather than the HTTP protocol. More information about PKCS#1 can be found at http://www.rsa.com/rsalabs/pubs/PKCS/ Additional information regarding this vulnerability will be available at http://www.bell-labs.com This vulnerability does not affect all PKCS#1-enabled products. The attack is not effective against protocols in which there is not an interactive session setup, or where the error messages returned by the server do not distinguish among the types of failures. In particular, this vulnerability does not affect S/MIME or SET. II. Impact Under some circumstances, an intruder who is able to observe an SSL-encrypted session, and subsequently interrogate the server involved in the session, may be able to recover the session key used in that session, and then recover the encrypted data from that session. The vulnerability can only be exploited if the intruder is able to make repeated session-establishment attempts to the same vulnerable web server which was involved in the original session. In addition, the server must return error messages that distinguish between several modes of failure. Although the number of session-establishment requests is large, it is significantly more efficient than a brute-force attack against the session key. Note that, although web servers comprise the majority of vulnerable servers, other PKCS#1-enabled servers may be vulnerable. Note that the server's public and private key are not at risk from this vulnerability, and that an intruder is only able to recover data from a single session per attack. Compromising a single session does not give an intruder any additional ability to compromise subsequent sessions. Further, as mentioned above, this vulnerability does not affect all PKCS#1-enabled products. III. Solution A. Obtain and install a patch for this problem. Appendix A contains input from vendors who have provided information for this advisory. We will update the appendix as we receive more information. If you do not see your vendor's name, the CERT/CC did not hear from that vendor. Please contact your vendor directly. B. Although applying vendor patches is the recommended course of action, you may wish to consider some of the following steps to reduce your exposure to this vulnerability: -- Examine your log files for repeated error messages indicating failed requests for session-establishment. For example, sites using C2Net's Stronghold server would see error messages of the form [Tue Jun 23 22:08:17 1998] SSL accept error 1575:error:0407006B:rsa routines:RSA_padding_check_PKCS1_type_2:block type is not 02:rsa_pk1.c:207 1575:error:04064072:rsa routines:RSA_EAY_PRIVATE_DECRYPT:padding check failed:rsa_eay.c:330 1575:error:1408B076:SSL routines:SSL3_GET_CLIENT_KEY_EXCHANGE:bad rsa decrypt:s3_srvr.c:1259 -- If you are unable to upgrade for an extended period of time, you may wish to consider obtaining a new public/private key pair for servers. Changing the key pair only protects those sessions which may have been previously recorded by an intruder. This does not prevent an intruder from launching attacks against newly-recorded sessions. This should only be considered in those cases where upgrading is infeasible. Again, note that the public/private key pair is not at risk from this vulnerability. -- Avoid using the same public/private key pair across multiple servers. -- A large increase in CPU utilization or network traffic may accompany an attack. If your web server does not provide sufficient detail in its logs to detect failures, you may wish to look for substantial deviation from established usage patterns, which may be indicative of an attack. Implementors and researchers should consult RSA Laboratories Bulletin Number 7 for additional measures to reduce the effectiveness of this attack. This document will be available at http://www.rsa.com/rsalabs/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Appendix A - Vendor Information Below is a list of the vendors who have provided information for this advisory. We will update this appendix as we receive additional information. If you do not see your vendor's name, the CERT/CC did not hear from that vendor. Please contact the vendor directly. C2Net Software, Inc. ------------------- C2Net has developed a patch and is deploying new builds to combat this problem. More information is available at http://www.c2.net Microsoft Corporation --------------------- The Microsoft Product Security Response Team has produced an update for the following affected Microsoft Internet server software: - Microsoft Internet Information Server 3.0 and 4.0 - Microsoft Site Server 3.0, Commerce Edition - Microsoft Site Server, Enterprise Edition - Microsoft Exchange 5.0 and 5.5 (for SSL-enabled POP3 and SMTP) Microsoft's Internet server software provides SSL 2.0, SSL 3.0, PCT 1.0, and TLS 1.0 for securing Internet-based communications. These protocols are all implemented in a single file called SCHANNEL.DLL, which is shared by the Microsoft Internet server software listed above. Updating this single file will resolve this vulnerability for these Microsoft server products. No updates are required for Internet client software, such as Internet Explorer. This update is now available. Microsoft strongly recommends that customers using secure SSL Internet services with any of the Microsoft products listed above should update to the latest version of SCHANNEL.DLL. Please visit the Microsoft Security Advisor web site for more information, or link directly to our Microsoft security bulletin MS98-002 at http://www.microsoft.com/security/bulletins/ms98-002.htm Netscape Communications Corporation ----------------------------------- Netscape recommends that all customers running Netscape Enterprise Server software, Netscape Proxy Server, Netscape Messaging Server and Netscape Collabra Server download and install a simple patch before an attack ever happens. Product updates and full information about the countermeasures are available immediately from the Netscape Internet site at: http://help.netscape.com/products/server/ssldiscovery/index.html Open Market, Inc. ----------------- Some of Open Market's products are affected by this vulnerability. Patches are available. For more information, go to http://www.openmarket.com/security RSA Data Security, Inc. ----------------------- Information from RSA regarding this vulnerability is available at http://www.rsa.com/rsalabs/ SSLeay ------ Information and SSLeay source patches related to this vulnerability are available at: http://www.ssleay.org/announce/ - ----------------------------------------------------------------------------- This vulnerability was originally discovered by Daniel Bleichenbacher of the Secure Systems Research Department of Bell Labs, the research and development arm of Lucent Technologies. The CERT Coordination Center thanks Scott Schnell of RSA and Jason Garms of Microsoft for reporting this problem to us and providing technical advice and other valuable input into the construction of this advisory. In addition, our thanks goes to Simona Nass, Douglas Barnes, and Tim Hudson of C2Net and David Wagner of the University of California at Berkeley for the example log files contained herein as well as additional technical advice and clarification during the production of this advisory. - ----------------------------------------------------------------------------- If you believe that your system has been compromised, contact the CERT Coordination Center or your representative in the Forum of Incident Response and Security Teams (see http://www.first.org/team-info/). CERT/CC Contact Information - ---------------------------- Email cert@cert.org Phone +1 412-268-7090 (24-hour hotline) CERT personnel answer 8:30-5:00 p.m. EST(GMT-5) / EDT(GMT-4) and are on call for emergencies during other hours. Fax +1 412-268-6989 Postal address CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh PA 15213-3890 USA Using encryption We strongly urge you to encrypt sensitive information sent by email. We can support a shared DES key or PGP. Contact the CERT/CC for more information. Location of CERT PGP key ftp://ftp.cert.org/pub/CERT_PGP.key Getting security information CERT publications and other security information are available from http://www.cert.org/ ftp://ftp.cert.org/pub/ CERT advisories and bulletins are also posted on the USENET newsgroup comp.security.announce To be added to our mailing list for advisories and bulletins, send email to cert-advisory-request@cert.org In the subject line, type SUBSCRIBE your-email-address - --------------------------------------------------------------------------- Copyright 1998 Carnegie Mellon University. Conditions for use, disclaimers, and sponsorship information can be found in http://www.cert.org/legal_stuff/legal_stuff.html and ftp://ftp.cert.org/pub/legal_stuff . If you do not have FTP or web access, send mail to cert@cert.org with "copyright" in the subject line. *CERT is registered in the U.S. Patent and Trademark Office. - --------------------------------------------------------------------------- This file: ftp://ftp.cert.org/pub/cert_advisories/CA-98.07.PKCS http://www.cert.org/nav/alerts.html ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Revision history -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNZNy/HVP+x0t4w7BAQEtWwP/czdc+MJTXvh6PYrevcvva0MXpBAzeJEQ OzAl2//oA0BQJjnf+OY/Oof1fv6VyjrpGCt2trrMgb1xElBGA8fyCIX7P8uHN7bM 8d7Nyf/YuxdTmjPMMN87W3fwlAJGJX+Lh3ut5W6bVs8MZ4DKYtYwz1v47sxDRRRD AGy9+WJJO0U= =PzDb -----END PGP SIGNATURE----- **************************************************************************** * * * The point of contact for NIPRNET security-related incidents is the * * ASSIST: * * * * E-mail address: ASSIST@ASSIST.MIL * * * * Telephone: 1-(800)-357-4231 (24 hours/day) * * * * You may also contact the Security Coordination Center (SCC) at the * * NIC: * * * * E-mail address: SCC@NIC.MIL * * * * Telephone: 1-(800)-365-3642 * * * * NIC Help Desk personnel are available from 7:00 a.m.-7:00 p.m. EST, * * Monday through Friday except on federal holidays. * * * **************************************************************************** PLEASE NOTE: Some users outside of the DOD computing communities may receive DISN Security Bulletins. If you are not part of the DOD community, please contact your agency's incident response team to report incidents. Your agency's team will coordinate with DOD. The Forum of Incident Response and Security Teams (FIRST) is a world-wide organization. A list of FIRST member organizations and their constituencies can be obtained by sending email to docserver@first.org with an empty subject line and a message body containing the line: send first-contacts. This document was prepared as an service to the DOD community. Neither the United States Government nor any of their employees, makes any warranty, expressed or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by the United States Government. The opinions of the authors expressed herein do not necessarily state or reflect those of the United States Government, and shall not be used for advertising or product endorsement purposes.