Protect yourself against future threats.
-----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-----