Note: This is an archival copy of Security Sun Alert 201534 as previously published on http://sunsolve.sun.com.|
Latest version of this security advisory is available from http://support.oracle.com as Sun Alert 1001144.1.
Solaris 9 Operating System
Solaris 10 Operating System
Date of Workaround Release
Date of Resolved Release
Multiple vulnerabilities in the OpenSSL product impact the Solaris WAN boot software.
An RSA signature forgery vulnerability may allow an untrusted server or client to present a forged identity to the other party during remote software installation when SSL is in use with certain types of certificates. This would allow the security restrictions of that SSL configuration to be circumvented.
Additionally, security vulnerabilities in the ASN.1 parser implementation and public key handling in the OpenSSL library may allow a user who is running a client system that is able to connect to a WAN Boot installation server to cause a Denial Of Service (DoS) to that server. This could prevent the server from providing service to WAN Boot clients. Clients connecting to an untrusted server may also be impacted by this issue.
Note that the WAN Boot software uses a static version of the OpenSSL libraries, meaning that the Solaris 10 resolution for Sun Alert 102744, which corrects applications dynamically linking to the Solaris OpenSSL libraries, is not sufficient to resolve this issue for the WAN Boot software. This Sun Alert will describe the full impact and resolution for the WAN Boot software.
These issues are 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
CVE-2006-2937 at http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2937
CVE-2006-2940 at http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2940
Note: This Sun Alert is specific to the Solaris WAN Boot software. Multiple Sun products are affected by the RSA signature forgery issue; for more details please see Sun Alert 102648 at
This issue can occur in the following releases:
1. Solaris 8 does not include The WAN boot software, and is not impacted by this issue.
2. WAN Boot only supports installation to SPARC-based clients.
3. A WAN Boot remote installation will only be affected by this issue if it is configured to download the installation data by a secure SSL connection for either:
a) the initial stages of the installation when the client downloads its boot environment from the server
b) the latter stages of the installation when the JumpStart configuration and the installation media are downloaded in the form of Solaris Flash archives (which may come from a different server than that mentioned in item 'a' above).
Whether or not SSL is used in these ways during the WAN Boot installation process is determined by the configuration which is maintained by the server and distributed to the client during the installation. The server may maintain different configurations for different clients, each of which may or may not use SSL.
To determine if SSL will be used during the initial stages of the installation of a specific client according to the configuration maintained on the server, the wanboot.conf(4) file that is stored on the server and is associated with that client can be checked (taking into account that there may be multiple wanboot.conf files on the system for different clients or groups of clients). For example, to confirm if server or client authentication is in use for a certain client installation, a command such as the following can be used:
# grep _authentication /etc/netboot/<optional_net_and_client_id>/wanboot.conf server_authentication=yes client_authentication=yes
To determine if SSL is used to download the JumpStart configuration the system configuration file associated with the client being installed should be checked. The location and name of this file will be determined by the 'system_conf' setting in the wanboot.conf file. For example:
# grep https: /etc/netboot/<name_of_system_configuration_file> SsysidCF=https://18.104.22.168/flash/ SjumpsCF=https://22.214.171.124/flash/
To determine if SSL will be used to download the Solaris Flash archives, the JumpStart configuration which is stored on the installation server at a location configured in the system configuration file can be checked using a command such as the following:
# grep archive_location <path_to_jumpstart_config>/profile archive_location https://126.96.36.199/flash_archive.flar
If the returned URL begins with 'https:' the flash archive will be downloaded using SSL.
The RSA signature forgery issue only affects signatures which are made using keys based on the RSA algorithm with an exponent of 3. Tools such as openssl(1) (which is shipped with Solaris 10, Solaris 9 does not include a tool which can be used for this purpose) can be used to determine the algorithm and exponent setting associated with a certain key. The exact method will depend on the tool and the configuration. For example, to display the details of a certificate which is stored in a PKCS12 formatted file (as passed to the wanbootutil(1M)'s 'pkcs12split' subcommand during the initial WAN Boot setup), the openssl application could be used in the following way:
$ openssl pkcs12 -in <pkcs12-file> -nokeys | openssl x509 -text | egrep 'Exponent:|Public Key Algorithm:' Enter Import Password: MAC verified OK Public Key Algorithm: rsaEncryption Exponent: 65537 (0x10001)
Some parts of the WAN Boot software that are affected by this vulnerability may be installed independently from the standard locations. For example, the 'wanboot-cgi' program will be installed in a location where it can be served by the web server software that is installed on the server host. In addition, clients which do not support WAN Boot installations from the OBP may be booting from a CDROM, from where they will acquire the 'wanboot' application. All of these extra items will need to be updated for the resolution to be fully active.
There are no symptoms that would indicate that these vulnerabilities have been exploited to forge RSA signatures. If the issues mentioned above have been exploited to cause a Denial of Service, processes belonging to the affected applications will be consuming unusually large amounts of CPU time and memory, and other applications running on the system may be slow or unresponsive.
For the client side this means it could hang while booting or performing installation via WAN boot.
Commands such as prstat(1M) can be used to determine the utilization of system resources on the server side, for example:
$ prstat -s cpu [...] $ prstat -s size [...]
To workaround the RSA signature verification vulnerability it is possible that the certificates in use can be replaced with certificates which use an exponent other than 3. For more details about how this can be done, consult the documentation which accompanies the software that is used to create the certificates, or consult the organization which provides the certificates.
There is no workaround to prevent these issues from being exploited to cause a Denial of Service.
This issue is addressed in the following releases:
This solution has no attachment