Information Exposure Affecting kernel-zfcpdump-devel package, versions <0:4.18.0-193.el8
Threat Intelligence
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk ID SNYK-RHEL8-KERNELZFCPDUMPDEVEL-3702592
- published 26 Jul 2021
- disclosed 15 Jul 2019
Introduced: 15 Jul 2019
CVE-2019-10639 Open this link in a new tabHow to fix?
Upgrade RHEL:8
kernel-zfcpdump-devel
to version 0:4.18.0-193.el8 or higher.
This issue was patched in RHSA-2020:1769
.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-zfcpdump-devel
package and not the kernel-zfcpdump-devel
package as distributed by RHEL
.
See How to fix?
for RHEL:8
relevant fixed versions and status.
The Linux kernel 4.x (starting from 4.1) and 5.x before 5.0.8 allows Information Exposure (partial kernel address disclosure), leading to a KASLR bypass. Specifically, it is possible to extract the KASLR kernel image offset using the IP ID values the kernel produces for connection-less protocols (e.g., UDP and ICMP). When such traffic is sent to multiple destination IP addresses, it is possible to obtain hash collisions (of indices to the counter array) and thereby obtain the hashing key (via enumeration). This key contains enough bits from a kernel address (of a static variable) so when the key is extracted (via enumeration), the offset of the kernel image is exposed. This attack can be carried out remotely, by the attacker forcing the target device to send UDP or ICMP (or certain other) traffic to attacker-controlled IP addresses. Forcing a server to send UDP traffic is trivial if the server is a DNS server. ICMP traffic is trivial if the server answers ICMP Echo requests (ping). For client targets, if the target visits the attacker's web page, then WebRTC or gQUIC can be used to force UDP traffic to attacker-controlled IP addresses. NOTE: this attack against KASLR became viable in 4.1 because IP ID generation was changed to have a dependency on an address associated with a network namespace.
References
- https://seclists.org/bugtraq/2019/Aug/18
- https://security.netapp.com/advisory/ntap-20190806-0001/
- https://support.f5.com/csp/article/K32804955
- https://support.f5.com/csp/article/K32804955?utm_source=f5support&utm_medium=RSS
- https://access.redhat.com/security/cve/CVE-2019-10639
- https://www.debian.org/security/2019/dsa-4497
- https://arxiv.org/pdf/1906.10478.pdf
- https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.0.8
- https://github.com/torvalds/linux/commit/355b98553789b646ed97ad801a619ff898471b92
- https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=355b98553789b646ed97ad801a619ff898471b92
- https://www.oracle.com/security-alerts/cpuApr2021.html
- https://lists.debian.org/debian-lts-announce/2019/07/msg00022.html
- https://lists.debian.org/debian-lts-announce/2019/08/msg00017.html
- https://access.redhat.com/errata/RHSA-2020:1769
- http://lists.opensuse.org/opensuse-security-announce/2019-07/msg00014.html
- http://lists.opensuse.org/opensuse-security-announce/2019-07/msg00025.html
- https://usn.ubuntu.com/4115-1/
- https://usn.ubuntu.com/4118-1/
- https://support.f5.com/csp/article/K32804955?utm_source=f5support&%3Butm_medium=RSS