{"vuid":"VU#234971","idnumber":"234971","name":"mod_ssl and Apache_SSL modules contain a buffer overflow in the implementation of the OpenSSL \"i2d_SSL_SESSION\" routine","keywords":["OpenSSL","mod_ssl","buffer overflow","i2d_SSL_SESSION"],"overview":"There is a remotely exploitable buffer overflow in two modules that implement the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocol. This can be used to execute arbitrary code.","clean_desc":"The Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols are used to provide a secure connection between a client and server for higher level protocols such as HTTP. Apache_SSL and mod_ssl are two modules for Apache that both call an OpenSSL routine i2d_SSL_SESSION() to help create an SSL/TLS session. This routine converts the SSL/TLS session data into a format that can be stored in the session cache. The OpenSSL d2i_SSL_SESSION.pod document states that the routine should be called to first determine the size of the buffer needed to store the session data. Then the appropriately sized buffer should be allocated and finally the routine should be called again to convert the data. These two modules fail to follow this procedure, and use a statically defined buffer to store the results of the i2d_SSL_SESSION() routine. By establishing an SSL Session, with a large crafted client certificate signed by a trusted CA, an attacker may be able to execute arbitrary code. If the target server trusts multiple CAs, then the target server's risk of receiving a malicious certificate is increased. Client certificates are generated when a Certificate Signature Request (CSR) is made of a Certificate Authority (CA). The CA signs the CSR  with their server certificate and the resulting certificate is sent back to the client. Since some of the data in the CSR is entered by the person making the request, it is possible to submit a large crafted CSR for signature and have the CA sign it without suspicion. It should be noted that for testing purposes mod_ssl ships a static \"snakeoil\" CA server certificate. It is clearly stated that this certificate should not be used for production environments, and steps are given to dynamically generate a server certificate for the CA. If, however, a system uses this static \"snakeoil\" server certificate as their own CA signing certificate, then it is trivial for an attacker to craft and sign their own client side certificate that would be accepted by the victim site as being signed by the trusted CA. The MD5 checksum for these static certificates from mod_ssl version 2.8.4 for Apache version 1.3.20 are as follows: 9bd1d1069c69fafed5a86ea931ae45f9  ca-bundle.crt\nb21689366a43829d83728b023b6d04b8  Makefile.crl\n0de94cb2a39ed0fc158edd053b425255  Makefile.crt\nfbb7ae5d7e39607a39b1e36d30048683  README.CRL\n84bfd413a53d6a8036311b57faa8f0c8  README.CRT\na3351dacc96ebc615d986dfdb371c856  README.CSR\n2284a70fae1cb3c1101494cff135f1f7  README.KEY\n9a611f57078e624b672222197b8ff377  README.PRM\nb269a8269073c62bd83e6635d56ec11b  server.crt\n4ff42eeddd6571a29e0a7682d06137e4  server.csr\nad5dc80749418c15c3d99962f00eb2b1  server.key\n3c392576b27d8f79ab92eb39fce681f3  snakeoil-ca-dsa.crt\n05cc51fdcc3c8ef6ed6a777f460e675a  snakeoil-ca-dsa.key\n3c9bf8ebd0586ce0633e7c6a85ed345a  snakeoil-ca-dsa.prm\ne76c1653eb00e4c2168a9c590fcf4ed7  snakeoil-ca-rsa.crt\na55527f1b3ad826052b8f6395d0da3e4  snakeoil-ca-rsa.key\nd1701e1c69a9867943ad61432f1f44b1  snakeoil-dsa.crt\nbc6e0ae4c628088f78e22c7287647b0a  snakeoil-dsa.key\n3c9bf8ebd0586ce0633e7c6a85ed345a  snakeoil-dsa.prm\n6c7a7d92f67c8dbd6ca57a30da7bc3bb  snakeoil-rsa.crt\nec09a963da45ee792d5eb284568894da  snakeoil-rsa.key\nc98761828d8f030f973894f73e751e80  sslcfg.patch According to the timestamps, it appears that most of these test files have not changed since 1998-1999.","impact":"An attacker may be able to execute arbitrary code on the system with the privileges of the ssl module.","resolution":"Upgrade to mod_ssl 2.8.7 or Apache_SSL 1.3.22+1.47, or apply the patch provided by your vendor.","workarounds":"","sysaffected":"","thanks":"Ed Moyle discovered and analyzed this vulnerability.","author":"This document was written by Jason Rafail with assistance from Roman Danyliw, Sean Levy, and Jeff Havrilla.","public":["http://archives.neohapsis.com/archives/bugtraq/2002-02/0313.html","http://www.apache-ssl.org/advisory-20020301.txt","http://www.trustix.net/errata/misc/2002/TSL-2002-0034-apache.asc.txt","http://www.linuxsecurity.com/advisories/other_advisory-1923.html","http://www.apacheweek.com/issues/02-03-01.html#security"],"cveids":["CVE-2002-0082"],"certadvisory":"","uscerttechnicalalert":null,"datecreated":"2002-03-01T21:04:22Z","publicdate":"2002-02-27T00:00:00Z","datefirstpublished":"2002-03-01T22:52:19Z","dateupdated":"2002-04-22T20:44:45Z","revision":26,"vrda_d1_directreport":"","vrda_d1_population":"","vrda_d1_impact":"","cam_widelyknown":"16","cam_exploitation":"0","cam_internetinfrastructure":"13","cam_population":"15","cam_impact":"19","cam_easeofexploitation":"10","cam_attackeraccessrequired":"10","cam_scorecurrent":"15.496875","cam_scorecurrentwidelyknown":"17.634375","cam_scorecurrentwidelyknownexploited":"28.321875","ipprotocol":"","cvss_accessvector":"","cvss_accesscomplexity":"","cvss_authentication":null,"cvss_confidentialityimpact":"","cvss_integrityimpact":"","cvss_availabilityimpact":"","cvss_exploitablity":null,"cvss_remediationlevel":"","cvss_reportconfidence":"","cvss_collateraldamagepotential":"","cvss_targetdistribution":"","cvss_securityrequirementscr":"","cvss_securityrequirementsir":"","cvss_securityrequirementsar":"","cvss_basescore":"","cvss_basevector":"","cvss_temporalscore":"","cvss_environmentalscore":"","cvss_environmentalvector":"","metric":15.496875,"vulnote":null}