Closed savujevi closed 4 years ago
I see the same thing for a lot of the redhat provided images like ruby, python, etc... It actually can become very confusing seeing all these high vulnerabilities that seem to be potential false positives.
Hello developers, is there any solution or workaround for this ? In the moment our checks fail and can't be used in our pipeline for our images in production.
Thank you for your help.
Best regards, Sascha Vujevic
Our logfile:
{
"Name": "kernel-headers",
"NamespaceName": "centos:7",
"VersionFormat": "rpm",
"Version": "3.10.0-862.3.2.el7",
"Vulnerabilities": [
{
"Name": "RHSA-2018:0180",
"NamespaceName": "centos:7",
"Description": "The kernel-alt packages provide the Linux kernel version 4.x. Security Fix(es): * A flaw was found in the patches used to fix the 'dirtycow' vulnerability (CVE-2016-5195). An attacker, able to run local code, can exploit a race condition in transparent huge pages to modify usually read-only huge pages. (CVE-2017-1000405) Red Hat would like to thank Eylon Ben Yaakov and Daniel Shapiro for reporting this issue. Bug Fix(es): * Previously, Red Hat Enterprise Linux 7.4 with the kernel version provided by the kernel-alt package, did not support turning off transactional memory (TM) on the POWER9 systems. With this update it is now possible to turn off TM on the POWER9 systems. (BZ#1509974) * Due to a bug in the ixgbe and i40e drivers, the socket buffer list (skb list) in some cases got corrupted when running Red Hat Enterprise Linux 7.4 with the kernel version provided by the kernel-alt package on the POWER9 systems. Consequently, a kernel panic occurred. This update fixes ixgbe and i40e, and the kernel no longer panics due to this behavior. (BZ#1518412) * Users can lower the max_sectors_kb setting in the sysfs file system to accommodate certain workloads. Previously, users needed to set the maximum I/O size to either the block layer default or the optional preferred I/O size reported by the device. This update fixes the scsi driver to keep the current heuristic function for the initial setting of max_sectors_kb. As a result, for subsequent invocations, the driver now only updates the current queue limit if it exceeds the capabilities of the hardware. (BZ#1518432) * When performing full-bootme tests on Boston ESS systems running Red Hat Enterprise Linux 7.4 with the kernel version provided in the kernel-alt package, a kernel panic occurred and the operating system dropped into the XMON software. This update fixes the Multi-Queue Block IO Queueing Mechanism (blk-mq), and the kernel no longer panics in these circumstances. (BZ#1518433) * When running the stress test on the file system with the gssstress command, and pulling one disk from one recovery group, \"kernel I/O error\" was reported, and gssstress became unresponsive. Gssstress now works as expected under the described circumstances. (BZ#1522645) * When using the fwupdate_xl710 utility to apply updates for NVM Intel Ethernet Converged Network Adapter XL710 on machines running Red Hat Enterpise Linux 7.4 with the kernel version provided in the kernel-alt package, a deadlock sometimes occurred when the i40e driver was acquiring access to the Non-Volatile Memory (NVM) of the device. Consequently, NVM acquire timeouts occurred, the firmware update failed with the following error message: \"Failed Acquiring NVM resource for read err=-53 status=0xa\", and left the device's memory in a corrupted state. This update fixes the i40e driver, and the firmware updates no longer fail due to this behavior. (BZ#1522843) * Previously, on POWER9 systems with more than 100 Pstates, the cpufreq driver did not handle the cases when the NxN matrix denominated transition table (trans_table) overflowed beyond the PAGE_SIZE boundary correctly. Consequently, reading trans_table for any of the CPUs failed with the following error: \"fill_read_buffer: show+0x0/0xa0 returned bad count\" With this update reading trans_table for any of the CPUs now proceeds as expected under the described circumstances. (BZ#1522844) * Previously, the /sys/firmware/opal/exports directory did not contain an export node. Consequently, a range of memory in the Open Power Abstraction Layer (OPAL) that the operating system attempted to export to user space for debugging purposes was not available. With this update the sysfs file under /sys/firmware/opal/exports is now available for each property found there, and this file can be used for debugging purposes. (BZ#1522845)",
"Link": "https://access.redhat.com/errata/RHSA-2018:0180",
"Severity": "High",
"FixedBy": "0:4.11.0-44.4.1.el7a"
},
{
"Name": "RHSA-2018:0502",
"NamespaceName": "centos:7",
"Description": "The kernel-alt packages provide the Linux kernel version 4.x. Security Fix(es): * hw: cpu: speculative execution permission faults handling (CVE-2017-5754, Important)(ppc only) * kernel: Race condition in raw_sendmsg function allows denial-of-service or kernel addresses leak (CVE-2017-17712, Important) * kernel: mm/pagewalk.c:walk_hugetlb_range function mishandles holes in hugetlb ranges causing information leak (CVE-2017-16994, Moderate) Bug Fix(es): * When changing the Maximum Transmission Unit (MTU) size on Broadcom BCM5717, BCM5718 and BCM5719 chipsets, the tg3 driver sometimes lost synchronization with the device. Consequently, the device became unresponsive. With this update, tg3 has been fixed, and devices no longer hang due to this behavior. (BZ#1533478) * Previously, the perf tool used strict string matching to provide related events to a particular CPUID instruction. Consequently, the events were not available on certain IBM PowerPC systems. This update fixes perf to use regular expressions instead of string matching of the entire CPUID string. As a result, the perf tool now supports events on IBM PowerPC architectures as expected. (BZ#1536567) * Previously, the kernel debugfs file system implemented removal protection based on sleepable read-copy-update (SRCU), which slowed down the drivers relying on the debugfs_remove_recursive() function. Consequently, a decrease in performance or a deadlock sometimes occurred. This update implements per-file removal protection in debugfs. As a result, the performance of the system has improved significantly. (BZ#1538030) * When running the 'perf test' command on a PowerKVM guest multiple times, the branch instructions recorded in Branch History Rolling Buffer (BHRB) entries were sometimes unmapped before the kernel processed the entries. Consequently, the operating system terminated unexpectedly. This update fixes the bug, and the operating system no longer crashes in the described situation. (BZ#1538031)",
"Link": "https://access.redhat.com/errata/RHSA-2018:0502",
"Severity": "High",
"FixedBy": "0:4.11.0-44.6.1.el7a"
},
{
"Name": "RHSA-2017:0372",
"NamespaceName": "centos:7",
"Description": "The kernel-aarch64 package contain the Linux kernel, the core of any Linux operating system. Security Fix(es): * A race condition was found in the way the Linux kernel's memory subsystem handled the copy-on-write (COW) breakage of private read-only memory mappings. An unprivileged, local user could use this flaw to gain write access to otherwise read-only memory mappings and thus increase their privileges on the system. (CVE-2016-5195, Important) * Linux kernel built with the 802.1Q/802.1ad VLAN(CONFIG_VLAN_8021Q) OR Virtual eXtensible Local Area Network(CONFIG_VXLAN) with Transparent Ethernet Bridging(TEB) GRO support, is vulnerable to a stack overflow issue. It could occur while receiving large packets via GRO path, as an unlimited recursion could unfold in both VLAN and TEB modules, leading to a stack corruption in the kernel. (CVE-2016-7039, Important) Red Hat would like to thank Phil Oester for reporting CVE-2016-5195. Bug Fix(es): * Previously, the operating system did not support the Mellanox ConnectX-4 PCIe Network Interface Controllers (NIC) in Ethernet mode. This update enables Ethernet support in the mlx5 driver. As a result, the Mellanox ConnectX-4 PCIe NICs now work in Ethernet mode as expected. (BZ#1413108) * On the Qualcomm Datacenter Technologies server platform with Qualcomm Datacenter Technologies Centriq 2400 CPU (QDF2400v1) memory accesses sometimes allocated Translation Lookaside Buffer (TLB) entries using an incorrect Address Space ID (ASID). This could consequently result in memory corruption and crashes under certain conditions. The underlying source code has been modified to handle the TTBRx_EL1[ASID] and TTBRx_EL1[BADDR] fields separately using a reserved ASID, and the described problem no longer occurs. (BZ#1421765)",
"Link": "https://access.redhat.com/errata/RHSA-2017:0372",
"Severity": "High",
"FixedBy": "0:4.5.0-15.2.1.el7"
},
{
"Name": "RHSA-2018:0654",
"NamespaceName": "centos:7",
"Description": "The kernel-alt packages provide the Linux kernel version 4.x. The following packages have been upgraded to a later upstream version: kernel-alt (4.14.0). (BZ#1492717) Security Fix(es): * An industry-wide issue was found in the way many modern microprocessor designs have implemented speculative execution of instructions (a commonly used performance optimization). There are three primary variants of the issue which differ in the way the speculative execution can be exploited. Variant CVE-2017-5715 triggers the speculative execution by utilizing branch target injection. It relies on the presence of a precisely-defined instruction sequence in the privileged code as well as the fact that memory accesses may cause allocation into the microprocessor's data cache even for speculatively executed instructions that never actually commit (retire). As a result, an unprivileged attacker could use this flaw to cross the syscall and guest/host boundaries and read privileged memory by conducting targeted cache side-channel attacks. (CVE-2017-5715, Important, ARM) Variant CVE-2017-5753 triggers the speculative execution by performing a bounds-check bypass. It relies on the presence of a precisely-defined instruction sequence in the privileged code as well as the fact that memory accesses may cause allocation into the microprocessor's data cache even for speculatively executed instructions that never actually commit (retire). As a result, an unprivileged attacker could use this flaw to cross the syscall boundary and read privileged memory by conducting targeted cache side-channel attacks. (CVE-2017-5753, Important, ARM) Variant CVE-2017-5754 relies on the fact that, on impacted microprocessors, during speculative execution of instruction permission faults, exception generation triggered by a faulting access is suppressed until the retirement of the whole instruction block. In a combination with the fact that memory accesses may populate the cache even when the block is being dropped and never committed (executed), an unprivileged local attacker could use this flaw to read privileged (kernel space) memory by conducting targeted cache side-channel attacks. (CVE-2017-5754, Important, ARM) * kernel: memory leak when merging buffers in SCSI IO vectors (CVE-2017-12190, Moderate) * kernel: net: double-free and memory corruption in get_net_ns_by_id() (CVE-2017-15129, Moderate) * kernel: Incorrect updates of uninstantiated keys crash the kernel (CVE-2017-15299, Moderate) * kernel: Missing capabilities check in net/netfilter/nfnetlink_cthelper.c allows for unprivileged access to systemwide nfnl_cthelper_list structure (CVE-2017-17448, Moderate) * kernel: Missing namespace check in net/netlink/af_netlink.c allows for network monitors to observe systemwide activity (CVE-2017-17449, Moderate) * kernel: Arbitrary stack overwrite causing oops via crafted signal frame (CVE-2017-1000255, Moderate) * kernel: Stack information leak in the EFS element (CVE-2017-1000410, Moderate) * kernel: Race condition in sound system can lead to denial of service (CVE-2018-1000004, Moderate) * kernel: Buffer overflow in mp_override_legacy_irq() (CVE-2017-11473, Low) * kernel: Integer overflow in futex.c:futux_requeue can lead to denial of service or unspecified impact (CVE-2018-6927, Low) For more details about the security issue(s), including the impact, a CVSS score, and other related information, refer to the CVE page(s) listed in the References section. Red Hat would like to thank Google Project Zero for reporting CVE-2017-5715, CVE-2017-5753, and CVE-2017-5754; Vitaly Mayatskih for reporting CVE-2017-12190; Kirill Tkhai for reporting CVE-2017-15129; Michael Ellerman, Gustavo Romero, Breno Leitao, Paul Mackerras, and Cyril Bur for reporting CVE-2017-1000255; and Armis Labs for reporting CVE-2017-1000410. Additional Changes: See the Red Hat Enterprise Linux 7.5 Release Notes linked from References.",
"Link": "https://access.redhat.com/errata/RHSA-2018:0654",
"Severity": "High",
"FixedBy": "0:4.14.0-49.el7a"
},
{
"Name": "RHSA-2018:1374",
"NamespaceName": "centos:7",
"Description": "The kernel-alt packages provide the Linux kernel version 4.x. Security Fix(es): * kernel: ptrace() incorrect error handling leads to corruption and DoS (CVE-2018-1000199) For more details about the security issue(s), including the impact, a CVSS score, and other related information, refer to the CVE page(s) listed in the References section. Red Hat would like to thank Andy Lutomirski for reporting this issue. Bug Fix(es): * Previously, the nfs_commit_inode() function did not respect the FLUSH_SYNC argument and exited even if there were already the in-flight COMMIT requests. As a consequence, the mmap() system call occasionally returned the EBUSY error on NFS, and CPU soft lockups occurred during a writeback on NFS. This update fixes nfs_commit_inode() to respect FLUSH_SYNC. As a result, mmap() does not return EBUSY, and the CPU soft lockups no longer occur during NFS writebacks. (BZ#1559869) * Recent IBM z Systems hardware contains an extension to the time-of-day clock that ensures it will be operational after the year 2042 by avoiding an overflow that would happen without it. However, the KVM hypervisor was previously unable to handle the extension correctly, which lead to guests freezing if their kernel supported the time-of-day clock extension. This update adds support for the extension to the KVM hypervisor, and KVM guests which support it no longer freeze. (BZ#1559871) * This update provides the ability to disable the \"RFI Flush\" mitigation mechanism for the Meltdown vulnerability (CVE-2017-5754) in the kernel. The patches that mitigate the effect of Meltdown may have negative impact on performance when the mechanism they provide is enabled, and at the same time your systems may not need this mitigation if they are secured by other means. The vulnerability mitigation remains enabled by default and must be disabled manually; this restores system performance to original levels, but the system then also remains vulnerable to Meltdown. Instructions describing how to disable RFI Flush, as well as additional information, is provided in the following Red Hat Knowledgebase article: https://access.redhat.com/articles/3311301 (BZ#1561463)",
"Link": "https://access.redhat.com/errata/RHSA-2018:1374",
"Severity": "High",
"FixedBy": "0:4.14.0-49.2.2.el7a"
}
],
"AddedBy": "605d09f9ccfab314ba7d5bd1b8c90c9b5e145818fe7180d05e667c75096ecb8592783d467c55a22632e64724518f9dff51645b9520c1d019a5d39a23c3ba2f56"
}
It seems there are duplicates.
Thank you for your help.
Hello developers,
is it right, that cve from rhel are imported from https://www.redhat.com/security/data/oval/com.redhat.rhsa-RHEL7.xml
for the namespace centos:7 ?
There is no hint according to RHSA-2018:0180 in the xml-file about the architecture. Could you please tell me how the imorted cve from redhat are categorized by the architecture in clair ?
Thank you for your help.
I am seeing a similar problem with a RHEL 7.5 image (kernel version 3.10). Clair is flagging a series of vulnerabilities for Linux kernel-alt version 4.x The recommended security fix is not compatible with RHEL 7.5
RHSA-2018:1967: [High]
Found in: kernel-headers
The kernel-alt packages provide the Linux kernel version 4.x. Security Fix(es):
RHSA-2018:1967: [High]
Found in: kernel-debug-devel
The kernel-alt packages provide the Linux kernel version 4.x. Security Fix(es)
Soo this is actually not so much in relation to multiple architectures itself. kernel-headers packages in the images are coming from "kernel" srpm. However, it seems that Clair actually just uses binary RPM name to match. And so it assumes that kernel-headers from kernel-alt SRPM package should be considered an update to the one from "kernel" SRPM. However the 3.x kernel line got a separate backported fix.
FWIW I am not sure there's an easy and 100% correct fix. It would probably be an improvement to just use SRPM names to match. The metadata in OVAL might seem to be with RPM granularity but they are really SRPM granularity (it will always list all binary RPMs)
This thread is conflating multiple things, so I changed the title to clarify that this issue is specifically tracking just the fix for the architecture.
@jzelinskie Hello, I was wondering if you might be able to give a status update on work on this issue. As I understand it, this work is slated for completion by February and is expected to be included in the next release. Is this still the case?
@arcrose v3 is moving away from OVAL in general because of numerous issues. I'm on the fence about accepting some extra code in v2 in order to filter non x86 results, because there's a lot of misinformation about OVAL and I struggle to confirm whether or not we'd be filtering valid results because they are unlabelled with architecture information.
The alternative to OVAL to support content sets, which will require new functionality in v3. There is ongoing work by @KeyboardNerd and @Allda to get this work done over the next few months. v3 has many considerable changes, like a brand new API, which would also require migration work for yourself.
Is there any way to get involved with this work, or is the transition to v3 more of a personal undertaking for @KeyboardNerd and @Allda?
Our goal is to replace Oval security data with VMaaS for Red Hat images. Unfortunately there is one missing piece which is still blocking us from using VMaaS data. https://github.com/RedHatInsights/vmaas/issues/453
I hope this issue could be resolved in next few weeks and then we will switch to VMaaS.
Hello developers, is there any further approach ? Thank you.
Hello developers,
as I can see the issue https://github.com/RedHatInsights/vmaas/issues/453https://github.com/RedHatInsights/vmaas/issues/453 has been closed.
Is there a possibility to solve this issue in clair ?
Thank you for your help.
Best regards.
Hi @savujevi, things have changed a bit since my last update and VMaaS API is not going to be used in Clair since it is missing a few other important things. We are going to use Oval v2 for getting Red Hat RHSA. Oval provides enough detail about vulnerable packages and its architecture, but unfortunately, the Clair data model is not aware of the package arch. Because of this issue, we will probably filter-out non x86_64 packages to avoid false positives.
There is also Clair v4 in the active development phase (I don't know much about it) so maybe @ldelossa should consider supporting arch-specific vulnerabilities.
@savujevi @Allda ClairCore (the library which will back ClairV4) has initial support for architecture. https://github.com/quay/claircore/blob/master/distribution.go#L31 https://github.com/quay/claircore/blob/master/vulnerability.go#L22
We haven't applied it's filtering yet, but it all the pieces are in place or this to work out of the box in ClairV4.
We’re declaring bug bankruptcy as part of the release process for a new major version of Clair. Please open a ticket in our issue tracker if you feel this still needs to be addressed, and we'll triage as part of our v4 development process. Thanks!
Description of Problem: I have a finding (https://access.redhat.com/errata/RHSA-2018:0180) in image nodejs-8-rhel7 version 1 from redhat which says that it is for affected products:
The image nodejs-8-rhel7 is only for AMD64 (https://access.redhat.com/containers/?tab=overview#/registry.access.redhat.com/rhscl/nodejs-8-rhel7)
Expected Outcome:
Actual Outcome: see attachment clair_finding.txt
Environment:
uname -a
): 3.10.0-693.21.1.el7.x86_64 #1 SMP Fri Feb 23 18:54:16 UTC 2018 x86_64 x86_64 x86_64 GNU/Linuxkubectl version
): Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.1+5115d708d7", GitCommit:"fff65cf", GitTreeState:"clean", BuildDate:"2018-03-01T14:27:17Z", GoVersion:"go1.7.6", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.1+5115d708d7", GitCommit:"fff65cf", GitTreeState:"clean", BuildDate:"2018-03-01T14:27:17Z", GoVersion:"go1.7.6", Compiler:"gc", Platform:"linux/amd64"}helm version
):