Note: This is an archival copy of Security Sun Alert 201390 as previously published on
Latest version of this security advisory is available from as Sun Alert 1001063.1.
Article ID : 1001063.1
Article Type : Sun Alerts (SURE)
Last reviewed : 2007-02-21
Audience : PUBLIC
Copyright Notice: Copyright © 2010, Oracle Corporation and/or its affiliates.

Security Vulnerability With RSA Signature Affects Solaris Applications Utilizing the libike Library


Release Phase

Solaris 9 Operating System
Solaris 10 Operating System

Bug Id

Date of Workaround Release

Date of Resolved Release


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:

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:


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)



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


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=Vulnerable 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.


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

Modification History
Date: 28-NOV-2006
  • Updated Contributing Factors and Relief/Workaround sections

Date: 25-JAN-2007


  • Updated Relief/Workaround section

Date: 13-FEB-2007
  • Updated Contributing Factors, Relief/Workaround, and Resolution sections

Date: 22-FEB-2007
  • State: Resolved
  • Updated Contributing Factors and Resolution sections



This solution has no attachment