-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

===========================================================================
             AUSCERT External Security Bulletin Redistribution

                        ESB-2006.0872 -- [Solaris]
         Security Vulnerability With RSA Signature Affects Solaris
                 Applications Utilizing the libike Library
                             27 February 2007

===========================================================================

        AusCERT Security Bulletin Summary
        ---------------------------------

Product:              libike
Publisher:            Sun Microsystems
Operating System:     Solaris 10
                      Solaris 9
Impact:               Inappropriate Access
                      Reduced Security
Access:               Remote/Unauthenticated
CVE Names:            CVE-2006-4339

Ref:                  AL-2006.0074
                      ESB-2006.0728

Original Bulletin:    
  http://sunsolve.sun.com/search/printfriendly.do?assetkey=1-26-102722-1

Revision History:  February 27 2007: Solaris 10 patches released
                   February 15 2007: Standard patches are available.
                    January 29 2006: Preliminary T-patches are now available
                   November 29 2006: Initial Release

- --------------------------BEGIN INCLUDED TEXT--------------------

Sun(sm) Alert Notification
     * Sun Alert ID: 102722
     * Synopsis: Security Vulnerability With RSA Signature Affects
       Solaris Applications Utilizing the libike Library
     * Category: Security
     * Product: Solaris 9 Operating System, Solaris 10 Operating System
     * BugIDs: 6469236
     * Avoidance: Patch, Workaround
     * State: Resolved
     * Date Released: 27-Nov-2006, 22-Feb-2007
     * Date Closed: 22-Feb-2007
     * Date Modified: 28-Nov-2006, 25-Jan-2007, 13-Feb-2007, 22-Feb-2007

1. Impact

   A security vulnerability in the libike library may cause applications
   which link against this library to incorrectly verify certain forged
   RSA signatures. The exact impact of this vulnerability depends on the
   individual application and the system configuration.

   The in.iked(1M) daemon, which is shipped with Solaris 9 and 10, uses
   the libike library for signature verification, and is affected by this
   vulnerability.

   In addition, the following applications which are shipped with Solaris
   10 only, also make use of the libike library and are affected by this
   vulnerability:
     * elfsign(1)
     * kcfd(1M)

   The in.iked(1M) daemon can be configured to rely on RSA signature
   verification for authenticating remote hosts during IKE phase 1
   exchanges. This vulnerability may allow a remote privileged user to
   complete an IKE phase 1 exchange using a forged identity, which may
   eventually lead to the possibility of gaining unauthorized access to
   private networks.

   elfsign(1M) uses certificates for signing and verification of ELF
   binaries. This security vulnerability may allow signatures made with
   certain certificates to be forged, causing elfsign(1M) to incorrectly
   verify a signed binary. System configurations which depend on the
   output of elfsign(1M), such as a configuration which forbids execution
   of unsigned binaries, may therefore be circumvented.

   kcfd(1M), which is running by default on Solaris 10 systems, uses
   certificates for verification of kernel cryptographic modules. An
   untrusted privileged user could forge the signature of a cryptographic
   module and therefore load a module which would otherwise be rejected
   by kcfd(1M). However, the loading of kernel modules is limited to
   privileged users.

   This issue is also described in the following documents:
     * CERT VU#845620 at: http://www.kb.cert.org/vuls/id/845620
     * CVE-2006-4339 at:
       http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4339

   Note 1: The issue described in this Sun Alert is specific to libike
   library. Multiple Sun products are affected by this issue. For more
   details please see Sun Alert 102648 at:
     * http://sunsolve.sun.com/search/document.do?assetkey=1-26-102648
       -1

2. Contributing Factors

   This issue can occur in the following releases:

   SPARC Platform
     * Solaris 9 without patch 113451-12
     * Solaris 10 without patch 118371-08

   x86 Platform
     * Solaris 9 without patch 114435-11
     * Solaris 10 without patch 118372-08

   Note: Solaris 8 is not affected by this issue.

   Systems are affected by these vulnerabilities if any of the above
   applications are being used to verify data which is signed with an RSA
   signature with an exponent of 3.

   To determine if in.iked(1M) is running on the system, the following
   command can be used:
    $ pgrep in.iked

   To get a list of certificates which can be used by in.iked(1M), the
   ikecert(1M) command can be used:
    $ ikecert certdb -l -v

   The output will contain a list of certificates. Each certificate will
   have the key type displayed. For RSA certificates, there will be a
   public exponent value printed.

   If a certificate has a RSA public key stored in it, the key type will
   be of value "rsa":
    Certificate Slot Name: cert_authority_name.der   Key Type: rsa

   If the following line is in the properties of this certificate, then
   the certificate is vulnerable to the attack described in this
   document:
    Public Exponent (e) (   8 bits): 03

   It may be possible to forge signatures based on this certificate, for
   example, if the certificate belongs to a certification authority it
   may be possible to create certificates which incorrectly appear to be
   signed by this authority.

   The forgery is possible only in cases where the affected host is
   configured to accept IKE exchanges from arbitrary hosts or in the case
   where the attacker is able to spoof the traffic to make it appear to
   come from a host from which the affected system is configured to
   receive IKE exchanges.

   elfsign(1) uses certificates which are passed by the "-c" command line
   option or are located in the "/etc/crypto/certs/"directory. kcfd(1M)
   also uses certificates from this directory.

   To verify if a certificate in X509 format that is being used with
   elfsign or kcfd, (either by being stored in the above mentioned
   directory or by being passed to elfsign with the "-c" option) has an
   RSA key that is vulnerable to this attack, run the following command
   against the certificate:
    $ /usr/sfw/bin/openssl x509 -in <cert_file_name> -text

   If the output contains the following lines, then it is possible to
   forge the signature of binaries using this certificate:
    Public Key Algorithm: rsaEncryption
    Exponent: 3 (0x3)


3. Symptoms

   There are no predictable symptoms that would indicate the described
   issue has been exploited. 

4. Relief/Workaround

   Workaround for in.iked(1M):

   Until patches can be applied, sites may wish to disable verification
   of RSA signatures or only verification of RSA signatures created with
   RSA keys with an exponent of 3.

   Using the ikecert(1M) command described above an administrator is able
   to identify certificates with RSA keys and a public exponent of 3.
   These certificates can be removed by making use of the ikecert(1M)
   command, for example:
    $ ikecert certdb -r "C=US, O=Vulnerable Certification Authority, OU=Vulnera
ble Certification Certification Authority class 1"

   Success will be reported by following message:
    certdb: certificate file successfully removed.

   Note: With the removal of the certificate, it is no longer possible to
   establish IKE communication with entities using certificates signed by
   that certification authority. This could lead to disruption of network
   service.

   Workaround for elfsign(1) and kcfd(1M):

   All vulnerable certificates passed to elfsign(1) via the "-c" command
   line option or which are present in the "/etc/crypto/certs/"
   directory, as used by elfsign and kcfd, can be removed by using the
   rm(1) command, for example:
    # rm /etc/crypto/certs/Custom_cert

   Note: This can lead to the inability to execute signed binaries if the
   there are third-party applications installed on the system which do
   the verification via elfsign(1), or to the inability to load kernel
   modules which have been signed by one of the removed certificates.

5. Resolution

   This issue is addressed in the following releases:

   SPARC Platform
     * Solaris 9 with patch 113451-12 or later
     * Solaris 10 with patch 118371-08 or later

   x86 Platform
     * Solaris 9 with patch 114435-11 or later
     * Solaris 10 with patch 118372-08 or later

Change History

   28-Nov-2006:
     * Updated Contributing Factors and Relief/Workaround sections

   25-Jan-2007:
     * Updated Relief/Workaround section

   13-Feb-2007:
     * Updated Contributing Factors, Relief/Workaround, and Resolution
       sections

   22-Feb-2007:
     * State: Resolved
     * Updated Contributing Factors and Resolution sections

   This Sun Alert notification is being provided to you on an "AS IS"
   basis. This Sun Alert notification may contain information provided by
   third parties. The issues described in this Sun Alert notification may
   or may not impact your system(s). Sun makes no representations,
   warranties, or guarantees as to the information contained herein. ANY
   AND ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION
   WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR
   NON-INFRINGEMENT, ARE HEREBY DISCLAIMED. BY ACCESSING THIS DOCUMENT
   YOU ACKNOWLEDGE THAT SUN SHALL IN NO EVENT BE LIABLE FOR ANY DIRECT,
   INDIRECT, INCIDENTAL, PUNITIVE, OR CONSEQUENTIAL DAMAGES THAT ARISE
   OUT OF YOUR USE OR FAILURE TO USE THE INFORMATION CONTAINED HEREIN.
   This Sun Alert notification contains Sun proprietary and confidential
   information. It is being provided to you pursuant to the provisions of
   your agreement to purchase services from Sun, or, if you do not have
   such an agreement, the Sun.com Terms of Use. This Sun Alert
   notification may only be used for the purposes contemplated by these
   agreements.

   Copyright 2000-2006 Sun Microsystems, Inc., 4150 Network Circle, Santa
   Clara, CA 95054 U.S.A. All rights reserved

- --------------------------END INCLUDED TEXT--------------------

You have received this e-mail bulletin as a result of your organisation's
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to auscert@auscert.org.au
and we will forward your request to the appropriate person.

NOTE: Third Party Rights
This security bulletin is provided as a service to AusCERT's members.  As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to follow or act on information or advice
contained in this security bulletin is the responsibility of each user or
organisation, and should be considered in accordance with your organisation's
site policies and procedures. AusCERT takes no responsibility for consequences
which may arise from following or acting on information or advice contained in
this security bulletin.

NOTE: This is only the original release of the security bulletin.  It may
not be updated when updates to the original are made.  If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the author's website to ensure that the information is still current.

Contact information for the authors of the original document is included
in the Security Bulletin above.  If you have any questions or need further
information, please contact them directly.

Previous advisories and external security bulletins can be retrieved from:

        http://www.auscert.org.au/render.html?cid=1980

If you believe that your computer system has been compromised or attacked in 
any way, we encourage you to let us know by completing the secure National IT 
Incident Reporting Form at:

        http://www.auscert.org.au/render.html?it=3192

===========================================================================
Australian Computer Emergency Response Team
The University of Queensland
Brisbane
Qld 4072

Internet Email: auscert@auscert.org.au
Facsimile:      (07) 3365 7031
Telephone:      (07) 3365 4417 (International: +61 7 3365 4417)
                AusCERT personnel answer during Queensland business hours
                which are GMT+10:00 (AEST).
                On call after hours for member emergencies only.
===========================================================================

-----BEGIN PGP SIGNATURE-----
Comment: http://www.auscert.org.au/render.html?it=1967

iQCVAwUBRePOuih9+71yA2DNAQI2fwQAkqOCEDjkyi/bCAvXHc5SUmKpxT6LCAfc
Qil/awko5ud6DY7U01vgp5A8GtOkXhAjvc0bUXgWVdfPOdotsWEcNRI5DEVD6lUK
qEftU21v3vv2uX5l2BGg3ZCQFpTNmD+T3zTLd7R9AQ0zC5xQdlAMbN4IPKsnOJn1
AEe3aCWsjyE=
=RptB
-----END PGP SIGNATURE-----