The remote Fedora 35 host has a package installed that is affected by multiple vulnerabilities as referenced in the FEDORA-2022-5d494ab9ab advisory.

    # New in release OpenJDK 17.0.5 (2022-10-18)

    * [Release announcement](https://bit.ly/openjdk1705)
    * [Full release notes](https://builds.shipilev.net/backports-monitor/release-notes-17.0.5.html)

    ## Security Fixes
      - JDK-8282252: Improve BigInteger/Decimal validation
      - JDK-8285662: Better permission resolution
      - JDK-8286077, CVE-2022-21618: Wider MultiByte conversions
      - JDK-8286511: Improve macro allocation
      - JDK-8286519: Better memory handling
      - JDK-8286526, CVE-2022-21619: Improve NTLM support
      - JDK-8286910, CVE-2022-21624: Improve JNDI lookups
      - JDK-8286918, CVE-2022-21628: Better HttpServer service
      - JDK-8287446: Enhance icon presentations
      - JDK-8288508: Enhance ECDSA usage
      - JDK-8289366, CVE-2022-39399: Improve HTTP/2 client usage
      - JDK-8289853: Update HarfBuzz to 4.4.1
      - JDK-8290334: Update FreeType to 2.12.1

    ## Major Changes

    ### [JDK-8278067](https://bugs.openjdk.org/browse/JDK-8278067): Make HttpURLConnection Default Keep Alive     Timeout Configurable     Two system properties have been added which control the keep alive behavior of HttpURLConnection in the     case where the server does not specify a keep alive time. Two properties are defined for controlling     connections to servers and proxies separately. They are:

    * `http.keepAlive.time.server`
    * `http.keepAlive.time.proxy`

    respectively. More information about them can be found on the [Networking Properties     page](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/net/doc-files/net-     properties.html).

    ### JDK-8286918: Better HttpServer service     The HttpServer can be optionally configured with a maximum connection limit by setting the     jdk.httpserver.maxConnections system property. A value of `0` or a negative integer is ignored and     considered to represent no connection limit. In the case of a positive integer value, any newly accepted     connections will be first checked against the current count of established connections and, if the     configured limit has been reached, then the newly accepted connection will be closed immediately.

    ### [JDK-8281181](https://bugs.openjdk.org/browse/JDK-8281181): CPU Shares Ignored When Computing Active     Processor Count     Previous JDK releases used an incorrect interpretation of the Linux cgroups parameter cpu.shares. This     might cause the JVM to use fewer CPUs than available, leading to an under utilization of CPU resources     when the JVM is used inside a container.

    Starting from this JDK release, by default, the JVM no longer considers cpu.shares when deciding the     number of threads to be used by the various thread pools. The `-XX:+UseContainerCpuShares` command-line     option can be used to revert to the previous behaviour. This option is deprecated and may be removed in a     future JDK release.

    ### [JDK-8269039](https://bugs.openjdk.org/browse/JDK-8269039): Disabled SHA-1 Signed JARs     JARs signed with SHA-1 algorithms are now restricted by default and treated as if they were unsigned. This     applies to the algorithms used to digest, sign, and optionally timestamp the JAR. It also applies to the     signature and digest algorithms of the certificates in the certificate chain of the code signer and the     Timestamp Authority, and any CRLs or OCSP responses that are used to verify if those certificates have     been revoked. These restrictions also apply to signed JCE providers.

    To reduce the compatibility risk for JARs that have been previously timestamped, there is one exception to     this policy:

    - Any JAR signed with SHA-1 algorithms and timestamped prior to January 01, 2019 will not be restricted.

    This exception may be removed in a future JDK release. To determine if your signed JARs are affected by     this change, run:
    ~~~     $ jarsigner -verify -verbose -certs`     ~~~     on the signed JAR, and look for instances of SHA1 or SHA-1 and disabled and a warning that the JAR     will be treated as unsigned in the output.

    For example:
    ~~~        Signed by CN=Signer        Digest algorithm: SHA-1 (disabled)        Signature algorithm: SHA1withRSA (disabled), 2048-bit key

       WARNING: The jar will be treated as unsigned, because it is signed with a weak algorithm that is now     disabled by the security property:

       jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA keySize < 1024, SHA1 denyAfter 2019-01-01     ~~~     JARs affected by these new restrictions should be replaced or re-signed with stronger algorithms.

    Users can, *at their own risk*, remove these restrictions by modifying the `java.security` configuration     file (or override it by using the `java.security.properties` system property) and removing SHA1 usage     SignedJAR & denyAfter 2019-01-01 from the     `jdk.certpath.disabledAlgorithms` security property and SHA1 denyAfter 2019-01-01 from the     `jdk.jar.disabledAlgorithms` security property.


Tenable has extracted the preceding description block directly from the Fedora security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

Detections

Analytics

Fedora 35 : java-17-openjdk (2022-5d494ab9ab)

medium Nessus Plugin ID 169172

Version 1.2