Oracle Solaris 11.3.36.24.0 Limited Support Update README

Contents

• Why Apply Oracle Solaris 11.3.36.24.0
• Before Installing Oracle Solaris 11.3.36.24.0
• Bugs Fixed
• Packages Updated
• Superseded IDRs
• About Oracle Solaris 11 Limited Support Updates
• Determining the Oracle Solaris Version Installed on Your System
• Managing the Repository
• How to Update Your Local Repository
• Oracle Solaris Repository Reorganization
• Further Assistance

Why Apply Oracle Solaris 11.3.36.24.0

• FreeType has been updated to 2.10.4, and addresses a security issue (Bugs 32047869, 32047894)
• OpenSSL has been updated to 1.0.2x, and addresses security issues (Bugs 32247243, 31899422, 32247269)

Before Installing Oracle Solaris 11.3.36.24.0

• ssh-dss Keys Disabled by Default
  
  The ssh-dss and ssh-dss-cert-* host and user key types are inherently weak and are disabled by default at run time.
  
  If the ssh-rsa and ssh-dss host keys are not already present, use the svc:/network/ssh:default to create both the keys. It is unusual for Oracle Solaris servers to have the ssh-dss host keys but not the ssh-rsa keys.
  
  If you have been using ssh-dss keys for public key authentication, you should create new ssh-rsa keys and remove the existing ssh-dss keys from all authorized_keys files. For information about creating new keys, see the ssh-keygen(1) man page.
  
  
• diffie-hellman-group1-sha1 Key Exchange Disabled by Default
  
  The diffie-hellman-group1-sha1 key exchange is no longer considered secure, and is disabled on both the client and the server.
  
  If systems do not have a matching kex algorithm between the server and the client, you will receive the no kex alg error.
  
  If your servers support only the diffie-hellman-group1-sha1 key exchange, you should upgrade them to support diffie-hellman-group-exchange-sha256. You can also upgrade Oracle Solaris to a version which supports the diffie-hellman-group14-sha1 key exchange.
  
  If upgrading the peer is not an option, users connecting to systems that do not support the diffie-hellman-group-exchange-sha256, the diffie-hellman-group14-sha1, or the diffie-hellman-group-exchange-sha1 key exchanges can explicitly enable the diffie-hellman-group1-sha1 as follows:
  
  root@source# ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 user@somehost
  
  The server administrator can allow logins from systems that do not support secure key exchange methods by explicitly enabling insecure key exchange methods. Add the following lines to the /etc/ssh/ssh_config file (or a user's .ssh/ssh_config file) and restart the SSH server:
  
  # Keep this file compatible with both sunssh and Openssh
IgnoreUnknown IgnoreIfUnknown
IgnoreIfUnknown IgnoreUnknown, KexAlgorithms

# Enable legacy algorithms -- remove when no longer needed.
KexAlgorithms
diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256
  
  
• SSH Protocol 1 Support Removed
  
  In Oracle Solaris 11.3.5, SSH-1 support has been removed on both the server side and the client side. Network entities that support only SSH-1 are mostly old network routers. You can no longer connect to such devices by using OpenSSH. However, you can still use SunSSH to access systems that use SSH-1.
  
  
• Unsafe Algorithms Removed
  
  The default list of enabled ciphers and MACs is reduced for sshd in OpenSSH 7.1p1 to remove unsafe algorithms, and further reduced for clients in OpenSSH 7.2p2, but the total list remains the same. Any ciphers or MACs needed can be re-enabled using the ciphers and MACs options to configure the files. For more information, see the man ssh_config(4) and man sshd_config(4) man pages.
  
  If the ciphers needed at the site are also available in sunssh, then reverting to sunssh is another workaround that can be used until peer systems can be upgraded to use stronger algorithms.
  
  The following OpenSSH ciphers are not available in sunssh:
  
  aes128-gcm@openssh.com
aes256-gcm@openssh.com
chacha20-poly1305@openssh.com
rijndael-cbc@lysator.liu.se (not used in OpenSSH 7.1p1 by default)
  
  Ciphers available in OpenSSH 7.1p1 by default. The recommended ciphers to be used are:
  
  The default Ciphers list for sshd:

chacha20-poly1305@openssh.com
aes128-ctr
aes192-ctr
aes256-ctr
aes128-gcm@openssh.com
aes256-gcm@openssh.com
  
  The default Ciphers list for ssh is the same as sshd plus:
  
  aes128-cbc
3des-cbc
aes192-cbc
aes256-cbc
  
  MACs:
  
  MACs available in OpenSSH 7.1p1 sshd (server) by default. The recommended MACs to be used are:
  
  The default MACs list for sshd:
  
  umac-64-etm@openssh.com
umac-128-etm@openssh.com
hmac-sha2-256-etm@openssh.com
hmac-sha2-512-etm@openssh.com
hmac-sha1-etm@openssh.com
umac-64@openssh.com
umac-128@openssh.com
hmac-sha2-256
hmac-sha2-512
hmac-sha1
  
  Formerly allowed ssh client additions to the above list are disabled by default in OpenSSH 7.2p2.
  
  The impact on interoperability is minimal due to the use of other popular algorithms that remain enabled by default.
  
  In particular, this change does not affect interoperability with older Oracle Solaris releases. Even SunSSH on Solaris 9 has a choice of common ciphers (aes128-cbc, 3des-cbc) and a common MAC (hmac-sha1) with the OpenSSH 7.2p2 client in default configuration.
  
  OpenSSH 7.2p2 also re-enables Ed25519 based cryptography in OpenSSH. The curve25519-sha256@libssh.org key exchange method and ssh-ed25519 key type are also newly available for use after upgrading to this SRU.
  
  You can use the following commands with OpenSSH to list all supported ciphers and MACs:
  
  root@source# ssh -Q cipher

root@source# ssh -Q mac
  
  
• Default Value of UseDNS is No.
  
  If no UseDNS value is specified in the sshd_config file, the default value of UseDNS is No. The former default value used to provide no security benefit.
  
  A UseDNS value of No means that you cannot use host names when configuring an ssh service.
  
  You have two options:
  
  

• You can explicitly specify UseDNS yes in the sshd_config file.
• You can use IP addresses instead of host names in the sshd_config file as shown in the following examples.
  
  In the Match block section of the sshd_config file, use an Address criterion instead of a Host criterion. For example, you can replace Match Host somehost.domain with Match Address 192.168.0.10.
  
  In the sshd_config entries for AllowUsers, AllowGroups, DenyUsers, and DenyGroups, use an IP address instead of the host name. For example, you can replace AllowUsers jsmith@somehost.domain with AllowUsers jsmith@192.168.0.10.
  
  In /etc/ssh/shosts.equiv or ~/.shosts entries, use an IP address instead of a host name. For example, you can replace somehost.domain with 192.168.0.10.
  
  In the ~/.ssh/authorized_keys entry, use an IP address instead of a host name if specifying the from option. For more information, see the man sshd(1M) man page. For example, you can replace from="somehost.domain" ssh-rsa AAAAB3...Q== jsmith@work with from="192.168.0.10" ssh-rsa AAAAB3...Q== jsmith@work
  
  

• TCP Wrappers such as hosts.deny and hosts.allow are not supported for OpenSSH
  
  The openssh implementation of Secure Shell no longer supports TCP wrappers. You will need to modify the sshd_config file or use a firewall to preserve a configuration that was previously enforced by TCP wrappers.
  
  (Note: The openssh implementation of Secure Shell continues to use TCP connections. However, the TCP wrapper function, libwrap, is no longer supported.)
  
  If you use TCP wrappers, you are using /etc/hosts.allow or /etc/hosts.deny to allow or deny logins. Instead, you can use the Match block in the sshd_config file to set up an equivalent configuration.
  
  For example, to allow logins only from the 10.163.0.0/16 subnet, you might have set up TCP wrappers as follows:
  
  

  root@jsmith-cz:~# cat /etc/hosts.allow
  sshd : 10.163.
  root@jsmith-cz:~# cat /etc/hosts.deny
  ALL : ALL

  
  
  In a Match block in the sshd_config file, the following entry sets an equivalent restriction:
  
  

  Match Address *,!10.163.0.0/16
  MaxAuthTries 0

  
  
  Another option is to use a firewall for access control. Settings similar to these examples can be applied on a firewall. Access control in the firewall occurs earlier, before the network connection is established in the kernel.

    | Thu Feb 11 09:32:14.2501        Starting ldap_cachemgr, logfile
    | /var/ldap/cachemgr.log
    | Thu Feb 11 09:32:14.6968        sig_ok_to_exit(): parent exiting...
    | Thu Feb 11 09:32:14.8270        Error: Unable to refresh
    | profile:XXX-tls:Session error no available conn.

    | error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh key too small

% openssl dhparam -out dhparams.pem 2048

• Delete the swap device
• Edit /etc/vfstab to add the "encrypted" option
• Reboot the system

# hotplug poweroff /pci@13c/pci@1/SYS/RCSA/PCIE11
ERROR: devices or resources are busy.

• Use "use lib '.';".
  
  This directive prepends '.' to @INC;. This means that '.' will be searched as the first directory, as it was the last directory before the fix. For more information, see '/usr/perl5/bin/perldoc lib'.
  
  
• Use the "-I ." command line parameter.
  
  This prepends the '.' to the start of @INC.
  
  
• Use "BEGIN { push @INC, '.' }".
  
  This appends '.' more closely mimicking the previous behavior.
  
  
• Use "require './module';".
  
  The 'require' directive specifies the path directly.
  
  
• Disable the fix by exporting the PERL_USE_UNSAFE_INC environment variable.
  
  

  export PERL_USE_UNSAFE_INC=1
  perl myscript.pl

  
  
• Disable the fix globally by editing /etc/perl/sitecustomize.pl and commenting out the line "pop @INC ...".
  
  

benchmark/filebench
database/mysql-51/tests
database/mysql-55/tests
database/mysql-56/tests
database/mysql-57/tests

1. /usr/benchmarks/filebench/bin/filebench
   
   You can override functionality defined in the /usr/benchmarks/filebench/config/... directory by creating a file in the current directory. This will also require you to update line 1045 in /usr/benchmarks/filebench/bin/filebench from require "$function.func"; to require "./$function.func";.
   
   
2. /usr/mysql/5.[1567]/mysql-test/mysql-test-run.pl
   
   Add "use lib '.';" before "use strict;" in mysql-test-run.pl.

aes_misc.c(83): OpenSSL internal error, assertion failed: Low level API call to cipher AES forbidden in FIPS mode!

zone '<name of zone>': hypervisor needs updating for DAX support in this zone

database/oracle/instantclient
database/oracle/instantclient/jdbc-supplement
database/oracle/instantclient/odbc-supplement
developer/oracle/instantclient/sdk

database/oracle/instantclient-121
database/oracle/instantclient/jdbc-supplement-121
database/oracle/instantclient/odbc-supplement-121
developer/oracle/instantclient/sdk-121

database/oracle/instantclient-122
database/oracle/instantclient/jdbc-supplement-122
database/oracle/instantclient/odbc-supplement-122
developer/oracle/instantclient/sdk-122

# pkg mediator instantclient
MEDIATOR      VER. SRC. VERSION IMPL. SRC. IMPLEMENTATION
instantclient local     12.1    local      vendor

$ man sqlplus

Error: invalid instruction suffix for `push`

# disable svc:/system/rad:remote
# rm /etc/rad/cert.pem
# rm /etc/rad/key.pem
# enable svc:/system/rad:remote

# openssl x509 -in /etc/rad/cert.pem -text

Bugs Fixed

• Oracle Solaris 11.3.36.3.0 ReadMe (Doc ID 2457998.1)
• Oracle Solaris 11.3.36.7.0 ReadMe (Doc ID 2492416.1)
• Oracle Solaris 11.3.36.10.0 ReadMe (Doc ID 2531260.1)
• Oracle Solaris 11.3.36.13.0 ReadMe (Doc ID 2565307.1)
• Oracle Solaris 11.3.36.15.0 ReadMe (Doc ID 2597494.1)
• Oracle Solaris 11.3.36.18.0 ReadMe (Doc ID 2628509.1)
• Oracle Solaris 11.3.36.20.0 ReadMe (Doc ID 2657274.1)
• Oracle Solaris 11.3.36.21.0 ReadMe (Doc ID 2686738.1)
• Oracle Solaris 11.3.36.23.0 ReadMe (Doc ID 2721603.1)

Packages Updated

Superseded IDRs

About Oracle Solaris 11 Limited Support Updates

• LSUs can be installed on systems covered by an appropriate Oracle support contract.
• LSUs are updates to Oracle Solaris, but are not complete images. They provide bug fixes and incremental changes that are relative to the preceding release, for example Oracle Solaris 11.3.
• The LSU repository must include the base packages for the Oracle Solaris 11 Update that they apply to.
• If a subset of the LSUs are added to a repository, only those LSUs can be installed provided that the corresponding Oracle Solaris 11 Update base packages are included in the repository.
• If the base packages for the relevant Oracle Solaris 11 Update are not included in the repository containing the LSUs, failures will occur during various packaging operations.
• LSUs are released and available for download on a quarterly basis.
• The LSU release date coincides with Oracle's quarterly Critical Patch Update (CPU). The CPU Documentation references security vulnerabilities fixed in each LSU. This Critical Patch Update Advisory lists all relevant Oracle products.
  
  To see the latest CPU, click the Critical Patch Update listed in the table. To see the security vulnerabilities that are fixed in recent Oracle Solaris LSUs, scroll down in the CPU document and click the "Oracle and Sun Systems Products Suite" link. This document also has a reference section to historical information for older Oracle Solaris SRUs and LSUs.
  
  
• LSUs must be applied during proactive maintenance to prevent issues, or when asked by Oracle Support for reactive break/fix maintenance situations. Customers should schedule such maintenance windows at least in line with the Oracle Critical Patch Update cycle, or more frequently as required by the industry and/or company compliance requirements. Note also that at times Oracle may release security vulnerability fixes outside of the normal Critical Patch Update cycle.
• If a system has an Interim Diagnostic Relief (IDR) installed, check if the issues addressed by the IDR are fixed in the LSU that you plan to install. If the issues are not fixed, you need to request a new IDR for that LSU several weeks in advance of the planned maintenance window.
• The LSU zip files on MOS provide an alternative download option to synchronize network based repository.

Determining the Oracle Solaris Version Installed on Your System

  # pkg list entire
  NAME (PUBLISHER)   VERSION
  entire             0.5.11-0.175.3.36.0.3.0

Managing the Repository

• The minimum OS level required for the system to run this repository is Oracle Solaris 11.3.
• The repository is provided as zip files. They contain only the packages that have been updated in the LSU.
• This LSU is provided in two parts: Oracle Solaris IPS Repository Installation Guide and Oracle Solaris IPS Repository. The Oracle Solaris IPS Repository Installation Guide contains the install script and readme files. The Oracle Solaris IPS Repository contains the zip files of the repository. You must download both the parts from MOS to add the packages to an existing repository that contains Oracle Solaris 11.3.35.
• The zip file associated with this README must be used in conjunction with an existing local copy of the Oracle Solaris support repository that contains Oracle Solaris 11.3.35.
• It is necessary to have a valid solaris publisher set before performing an update. For instructions to create an Oracle Solaris 11.3 package repository, see Copying and Creating Oracle Solaris 11.3 Package Repositories.

How to Update Your Local Repository

1. Become an administrator.
   
   For more information, see How to Use Your Assigned Administrative Rights in Securing Users and Processes in Oracle Solaris 11.3.
   
   
2. Run the install-repo.ksh script that is included in the IPS Repository Installation Guide patch to update your existing repository.
   
   $ install-repo.ksh [-c] [-v] -d full_path_to_existing_s11_3_repo
   
   For example:
   
   $ install-repo.ksh -c -v -d /export/support-repo
   
   
3. If the repository is managed by pkgserv, restart the appropriate service.
   
   $ svcadm restart svc:/application/pkg/server:your_repo_instance
   
   
4. If an existing repository is not set, add the repository to the system.
   
   $ pkg set-publisher -g file:///full_path_to_existing_s11_3_repo solaris
   
   
5. Update the packages.
   
   $ pkg update

• Updating and Maintaining Oracle Solaris 11
• Oracle Solaris 11 Image Packaging System (IPS) Frequently Asked Questions (FAQ)

Oracle Solaris Repository Reorganization

     http://pkg.oracle.com/solaris/legacy/release
     https://pkg.oracle.com/solaris/legacy/support

Further Assistance