Read Time:3 Second
Unspecified number of customers impacted over 2.5 years
Daily Archives: October 26, 2022
How to update your Windows driver blocklist to keep malicious drivers away
Read Time:1 Minute, 8 Second
For many years, attackers have used and abused various ways to get on our systems. From phishing to tricking us to click on websites, if an attacker can get their code on our systems they are no longer our systems. Attackers will even invest the time, energy, and expense to get their malicious drivers approved and co-designed through the Windows Hardware Compatibility Program in order to gain access to our machines. Ensuring that these malicious drivers are blocked is a key method for protecting systems.
Microsoft has long touted a means to update this master listing on our systems and, in theory, the idea was valid: using settings and security hardware on the computer, enabling hypervisor-protected code integrity (HVCI) was supposed to protect systems from malicious drivers. Attackers have used such attacks in the past ranging from RobbinHood, Uroburos, Derusbi, GrayFish, and Sauron, to campaigns by the threat actor STRONTIUM. As a Microsoft blog in 2020 pointed out, if a computer had HVCI enabled, it would be able to defend itself against vulnerable and malicious drivers. In the blog post, it was noted that “Microsoft threat research teams continuously monitor the threat ecosystem and update the list of drivers that in the Microsoft-supplied blocklist. This blocklist is pushed down to devices via Windows update.”
ICO Warns of “Immature” Biometric Tech
USN-5700-1: Linux kernel vulnerabilities
Read Time:1 Minute, 21 Second
David Bouman and Billy Jheng Bing Jhong discovered that a race condition
existed in the io_uring subsystem in the Linux kernel, leading to a use-
after-free vulnerability. A local attacker could use this to cause a denial
of service (system crash) or possibly execute arbitrary code.
(CVE-2022-2602)
Sönke Huster discovered that an integer overflow vulnerability existed in
the WiFi driver stack in the Linux kernel, leading to a buffer overflow. A
physically proximate attacker could use this to cause a denial of service
(system crash) or possibly execute arbitrary code. (CVE-2022-41674)
Sönke Huster discovered that a use-after-free vulnerability existed in the
WiFi driver stack in the Linux kernel. A physically proximate attacker
could use this to cause a denial of service (system crash) or possibly
execute arbitrary code. (CVE-2022-42719)
Sönke Huster discovered that the WiFi driver stack in the Linux kernel did
not properly perform reference counting in some situations, leading to a
use-after-free vulnerability. A physically proximate attacker could use
this to cause a denial of service (system crash) or possibly execute
arbitrary code. (CVE-2022-42720)
Sönke Huster discovered that the WiFi driver stack in the Linux kernel did
not properly handle BSSID/SSID lists in some situations. A physically
proximate attacker could use this to cause a denial of service (infinite
loop). (CVE-2022-42721)
Sönke Huster discovered that the WiFi driver stack in the Linux kernel
contained a NULL pointer dereference vulnerability in certain situations. A
physically proximate attacker could use this to cause a denial of service
(system crash). (CVE-2022-42722)
USN-5688-2: Libksba vulnerability
Read Time:17 Second
USN-5688-1 fixed vulnerabilities in Libksba. This update provides
the corresponding update for Ubuntu 22.10.
Original advisory details:
It was discovered that an integer overflow could be triggered in Libksba
when decoding certain data. An attacker could use this issue to cause a
denial of service (application crash) or possibly execute arbitrary code.
php-8.1.12-1.fc36
Read Time:47 Second
FEDORA-2022-1ecc10276e
Packages in this update:
php-8.1.12-1.fc36
Update description:
PHP version 8.1.12 (27 Oct 2022)
Core:
Fixes segfault with Fiber on FreeBSD i386 architecture. (David Carlier)
Fileinfo:
Fixed bug GH-8805 (finfo returns wrong mime type for woff/woff2 files). (Anatol)
GD:
Fixed bug php#81739: OOB read due to insufficient input validation in imageloadfont(). (CVE-2022-31630) (cmb)
Hash:
Fixed bug php#81738: buffer overflow in hash_update() on long parameter. (CVE-2022-37454) (nicky at mouha dot be)
MBString:
Fixed bug GH-9683 (Problem when ISO-2022-JP-MS is specified in mb_ encode_mimeheader). (Alex Dowad)
Opcache:
Added indirect call reduction for jit on x86 architectures. (wxue1)
Session:
Fixed bug GH-9583 (session_create_id() fails with user defined save handler that doesn’t have a validateId() method). (Girgias)
Streams:
Fixed bug GH-9590 (stream_select does not abort upon exception or empty valid fd set). (Arnaud)
php-8.1.12-1.fc37
Read Time:47 Second
FEDORA-2022-f204e1d0ed
Packages in this update:
php-8.1.12-1.fc37
Update description:
PHP version 8.1.12 (27 Oct 2022)
Core:
Fixes segfault with Fiber on FreeBSD i386 architecture. (David Carlier)
Fileinfo:
Fixed bug GH-8805 (finfo returns wrong mime type for woff/woff2 files). (Anatol)
GD:
Fixed bug php#81739: OOB read due to insufficient input validation in imageloadfont(). (CVE-2022-31630) (cmb)
Hash:
Fixed bug php#81738: buffer overflow in hash_update() on long parameter. (CVE-2022-37454) (nicky at mouha dot be)
MBString:
Fixed bug GH-9683 (Problem when ISO-2022-JP-MS is specified in mb_ encode_mimeheader). (Alex Dowad)
Opcache:
Added indirect call reduction for jit on x86 architectures. (wxue1)
Session:
Fixed bug GH-9583 (session_create_id() fails with user defined save handler that doesn’t have a validateId() method). (Girgias)
Streams:
Fixed bug GH-9590 (stream_select does not abort upon exception or empty valid fd set). (Arnaud)
java-11-openjdk-11.0.17.0.8-1.fc37
Read Time:5 Minute, 23 Second
FEDORA-2022-945d2996cd
Packages in this update:
java-11-openjdk-11.0.17.0.8-1.fc37
Update description:
New in release OpenJDK 11.0.17 (2022-10-18)
Release announcement
Full release notes
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-8286533, CVE-2022-21626: Key X509 usages
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
JDK-8293429: [11u] minor update in attribute style
Major Changes
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.
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: 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: 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.
JDK-8267880: Upgrade the default PKCS12 MAC algorithm
The default MAC algorithm used in a PKCS #12 keystore has been updated. The new algorithm is based on SHA-256 and is stronger than the old one based on SHA-1. See the security properties starting with keystore.pkcs12 in the java.security file for detailed information.
The new SHA-256 based MAC algorithms were introduced in the 11.0.12 release. Keystores created using this newer, stronger, MAC algorithm cannot be opened in versions of OpenJDK 11 earlier than 11.0.12. A ‘java.security.NoSuchAlgorithmException’ exception will be thrown in such circumstances.
For compatibility, use the keystore.pkcs12.legacy system property, which will revert the algorithms to use the older, weaker
algorithms. There is no value defined for this property.
JDK-8261160: JDK Flight Recorder Event for Deserialization
It is now possible to monitor deserialization of objects using JDK Flight Recorder (JFR). When JFR is enabled and the JFR configuration includes deserialization events, JFR will emit an event whenever the running program attempts to deserialize an object. The deserialization event is named jdk.Deserialization, and it is disabled by default. The deserialization event contains information that is used by the serialization filter mechanism; see the ObjectInputFilter API specification for details.
Additionally, if a filter is enabled, the JFR event indicates whether the filter accepted or rejected deserialization of the object. For
further information about how to use the JFR deserialization event, see the article “Monitoring Deserialization to Improve Application Security“.
For reference information about using and configuring JFR, see the “JFR Runtime Guide” and “JFR Command Reference” sections of the JDK Mission Control documentation.
JDK-8139348: Deprecate 3DES and RC4 in Kerberos
The des3-hmac-sha1 and rc4-hmac Kerberos encryption types (etypes) are now deprecated and disabled by default. Users can set allow_weak_crypto = true in the krb5.conf configuration file to re-enable them (along with other weak etypes including des-cbc-crc and des-cbc-md5) at their own risk. To disable a subset of the weak etypes, users can list preferred etypes explicitly in any of the default_tkt_enctypes, default_tgs_enctypes, or permitted_enctypes settings.
java-11-openjdk-11.0.17.0.8-2.fc36
Read Time:5 Minute, 23 Second
FEDORA-2022-d989953883
Packages in this update:
java-11-openjdk-11.0.17.0.8-2.fc36
Update description:
New in release OpenJDK 11.0.17 (2022-10-18)
Release announcement
Full release notes
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-8286533, CVE-2022-21626: Key X509 usages
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
JDK-8293429: [11u] minor update in attribute style
Major Changes
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.
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: 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: 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.
JDK-8267880: Upgrade the default PKCS12 MAC algorithm
The default MAC algorithm used in a PKCS #12 keystore has been updated. The new algorithm is based on SHA-256 and is stronger than the old one based on SHA-1. See the security properties starting with keystore.pkcs12 in the java.security file for detailed information.
The new SHA-256 based MAC algorithms were introduced in the 11.0.12 release. Keystores created using this newer, stronger, MAC algorithm cannot be opened in versions of OpenJDK 11 earlier than 11.0.12. A ‘java.security.NoSuchAlgorithmException’ exception will be thrown in such circumstances.
For compatibility, use the keystore.pkcs12.legacy system property, which will revert the algorithms to use the older, weaker
algorithms. There is no value defined for this property.
JDK-8261160: JDK Flight Recorder Event for Deserialization
It is now possible to monitor deserialization of objects using JDK Flight Recorder (JFR). When JFR is enabled and the JFR configuration includes deserialization events, JFR will emit an event whenever the running program attempts to deserialize an object. The deserialization event is named jdk.Deserialization, and it is disabled by default. The deserialization event contains information that is used by the serialization filter mechanism; see the ObjectInputFilter API specification for details.
Additionally, if a filter is enabled, the JFR event indicates whether the filter accepted or rejected deserialization of the object. For
further information about how to use the JFR deserialization event, see the article “Monitoring Deserialization to Improve Application Security“.
For reference information about using and configuring JFR, see the “JFR Runtime Guide” and “JFR Command Reference” sections of the JDK Mission Control documentation.
JDK-8139348: Deprecate 3DES and RC4 in Kerberos
The des3-hmac-sha1 and rc4-hmac Kerberos encryption types (etypes) are now deprecated and disabled by default. Users can set allow_weak_crypto = true in the krb5.conf configuration file to re-enable them (along with other weak etypes including des-cbc-crc and des-cbc-md5) at their own risk. To disable a subset of the weak etypes, users can list preferred etypes explicitly in any of the default_tkt_enctypes, default_tgs_enctypes, or permitted_enctypes settings.
java-11-openjdk-11.0.17.0.8-2.fc35
Read Time:5 Minute, 23 Second
FEDORA-2022-1c07902a5e
Packages in this update:
java-11-openjdk-11.0.17.0.8-2.fc35
Update description:
New in release OpenJDK 11.0.17 (2022-10-18)
Release announcement
Full release notes
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-8286533, CVE-2022-21626: Key X509 usages
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
JDK-8293429: [11u] minor update in attribute style
Major Changes
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.
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: 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: 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.
JDK-8267880: Upgrade the default PKCS12 MAC algorithm
The default MAC algorithm used in a PKCS #12 keystore has been updated. The new algorithm is based on SHA-256 and is stronger than the old one based on SHA-1. See the security properties starting with keystore.pkcs12 in the java.security file for detailed information.
The new SHA-256 based MAC algorithms were introduced in the 11.0.12 release. Keystores created using this newer, stronger, MAC algorithm cannot be opened in versions of OpenJDK 11 earlier than 11.0.12. A ‘java.security.NoSuchAlgorithmException’ exception will be thrown in such circumstances.
For compatibility, use the keystore.pkcs12.legacy system property, which will revert the algorithms to use the older, weaker
algorithms. There is no value defined for this property.
JDK-8261160: JDK Flight Recorder Event for Deserialization
It is now possible to monitor deserialization of objects using JDK Flight Recorder (JFR). When JFR is enabled and the JFR configuration includes deserialization events, JFR will emit an event whenever the running program attempts to deserialize an object. The deserialization event is named jdk.Deserialization, and it is disabled by default. The deserialization event contains information that is used by the serialization filter mechanism; see the ObjectInputFilter API specification for details.
Additionally, if a filter is enabled, the JFR event indicates whether the filter accepted or rejected deserialization of the object. For
further information about how to use the JFR deserialization event, see the article “Monitoring Deserialization to Improve Application Security“.
For reference information about using and configuring JFR, see the “JFR Runtime Guide” and “JFR Command Reference” sections of the JDK Mission Control documentation.
JDK-8139348: Deprecate 3DES and RC4 in Kerberos
The des3-hmac-sha1 and rc4-hmac Kerberos encryption types (etypes) are now deprecated and disabled by default. Users can set allow_weak_crypto = true in the krb5.conf configuration file to re-enable them (along with other weak etypes including des-cbc-crc and des-cbc-md5) at their own risk. To disable a subset of the weak etypes, users can list preferred etypes explicitly in any of the default_tkt_enctypes, default_tgs_enctypes, or permitted_enctypes settings.