430 lines
52 KiB
JSON
430 lines
52 KiB
JSON
[
|
|
{
|
|
"id": 16923675,
|
|
"rule": {
|
|
"id": 46,
|
|
"created_at": "2019-02-07T14:02:34.379375-05:00",
|
|
"updated_at": "2019-03-12T11:45:28.804999-04:00",
|
|
"ruleset": {
|
|
"created_at": "2018-12-20T20:33:00-05:00",
|
|
"updated_at": "2018-12-20T20:33:00-05:00",
|
|
"rule_source": "https://$REDACTED$/insights-open-source/insights-security",
|
|
"description": "Security"
|
|
},
|
|
"rule_id": "CVE_2017_5715_cpu_virt|VIRT_CVE_2017_5715_CPU_3_ONLYKERNEL",
|
|
"description": "Kernel vulnerable to side-channel attacks in modern microprocessors (CVE-2017-5715/Spectre)",
|
|
"active": true,
|
|
"category": {
|
|
"id": 2,
|
|
"name": "Security"
|
|
},
|
|
"impact": {
|
|
"name": "Information Disclosure",
|
|
"impact": 3
|
|
},
|
|
"likelihood": 2,
|
|
"node_id": "3244101",
|
|
"tags": "security kernel CVE",
|
|
"reboot_required": true,
|
|
"publish_date": "2018-01-17T12:00:00-05:00",
|
|
"summary": "A vulnerability was discovered in modern microprocessors supported by the kernel, whereby an unprivileged attacker can use this flaw to bypass restrictions to gain read access to privileged memory.\nThe issue was reported as [CVE-2017-5715 / Spectre](https://access.redhat.com/security/cve/CVE-2017-5715).\n",
|
|
"generic": "An industry-wide issue was found in the manner many modern microprocessors have implemented speculative execution of instructions. There are three primary variants of the issue which differ in the way the speculative execution can be exploited.\n\nAll three rely upon the fact that modern high performance microprocessors implement both speculative execution, and utilize VIPT (Virtually Indexed, Physically Tagged) level 1 data caches that may become allocated with data in the kernel virtual address space during such speculation.\n\nAn unprivileged attacker could use these to read privileged memory by conducting targeted cache side-channel attacks, including memory locations that cross the syscall boundary or the guest/host boundary, or potentially arbitrary host memory addresses.\n",
|
|
"reason": "{{? pydata.error_key == \"VIRT_CVE_2017_5715_CPU_3_VIRTKERNEL\" || pydata.error_key == \"VIRT_CVE_2017_5715_CPU_3_DRACUTKERNEL\" }}This machine is vulnerable, because it runs a vulnerable kernel and has the following vulnerable packages installed:\n\n{{~ pydata.PACKAGES :value:index}}\n* `{{= value }}`{{~}}\n{{?}}{{? pydata.error_key == \"VIRT_CVE_2017_5715_CPU_3_ONLYKERNEL\" }}This machine is vulnerable, because it runs a vulnerable kernel.\n{{?}}{{? pydata.error_key == \"VIRT_CVE_2017_5715_CPU_3_ONLYVIRT\" || pydata.error_key == \"VIRT_CVE_2017_5715_CPU_3_ONLYDRACUT\" }}This machine is vulnerable, because it has the following vulnerable packages installed:\n\n{{~ pydata.PACKAGES :value:index}}\n* `{{= value }}`{{~}}\n{{?}}\n\n<!--\n\nThe information about dracut is displayed only when the list of vulnerable packages is limited to solely dracut-related packages. Even though the message is applicable also to all other cases where a dracut-related package is vulnerable, it is not displayed in those cases, because it is clear that this Insights rule informs about the vulnerability that is specifically relevant to virtualization. After the prescribed actions would be taken, the potentially detected Dracut version would be updated with it, and the paragraph about Dracut might be more of a noise than relevant information, given the presumed presence of virtualization-related packages with more complex changes and impact in that particual report. However, in a case where no virtualization-related packages are detected as vulnerable, it ceases to be so clear that the Dracut update might help resolve the Variant 2 of the issue, which also affects any virtualization that might be used on the system, even though Dracut itself has little to do with virtualization. \n\nAlso note that the dracut-related packages are detected as vulnerable for the particular machine only if the machine has CPU of the particular applicable AMD family, as the relevant dracut update fixes behavior only for a limited set of AMD families.\n\n-->\n{{? pydata.error_key == \"VIRT_CVE_2017_5715_CPU_3_DRACUTKERNEL\" || pydata.error_key == \"VIRT_CVE_2017_5715_CPU_3_ONLYDRACUT\" }}This machine has a particular family of an AMD processor for which there exists an updated version of Dracut. Dracut is a low-level software for generating an initramfs/initrd image that, among other tasks, selects the appropriate processor microcode to use. It is possible, but not guaranteed, that after updating the affected Dracut packages, the appropriate microcode will be selected to enable the protections for Variant 2 of this issue.\n\n{{?}}\nAn unprivileged attacker could use the vulnerability to read privileged memory by conducting targeted cache side-channel attacks, including memory locations that cross the syscall boundary or the guest/host boundary, or potentially arbitrary host memory addresses.\n",
|
|
"more_info": "* For more information about the flaw, see [Kernel Side-Channel Attacks](https://access.redhat.com/security/vulnerabilities/speculativeexecution) and [CVE-2017-5715](https://access.redhat.com/security/cve/CVE-2017-5715).\n* For possible performance impact of kernel updates, see [Speculative Execution Exploit Performance Impacts](https://access.redhat.com/articles/3307751)\n* Extensive details can be found at the [Project Zero blog](https://googleprojectzero.blogspot.ca/2018/01/reading-privileged-memory-with-side.html) and [Meltdown and Spectre Attack webpage](https://meltdownattack.com/).\n* The Customer Portal page for the [Red Hat Security Team](https://access.redhat.com/security/) contains more information about policies, procedures, and alerts for Red Hat products.\n* The Security Team also maintains a frequently updated blog at [securityblog.redhat.com](https://securityblog.redhat.com).\n",
|
|
"resolution_set": [
|
|
{
|
|
"system_type": 105,
|
|
"resolution": "{{? pydata.error_key == \"VIRT_CVE_2017_5715_CPU_3_VIRTKERNEL\" || pydata.error_key == \"VIRT_CVE_2017_5715_CPU_3_DRACUTKERNEL\" }}Red Hat recommends that you update the kernel and the packages and restart the system:\n\n~~~~\n# yum update{{~ pydata.PACKAGE_NAMES :value:index}} {{= value }}{{~}}\n# yum update {{=pydata.kernel_pkg_name}}\n# reboot\n~~~~\n\nIf additional steps to update the kernel are necessary, they are detailed in the separate insights rule *Kernel vulnerable to side-channel attacks in modern microprocessors (CVE-2017-5753/Spectre, CVE-2017-5715/Spectre, CVE-2017-5754/Meltdown)*.\n{{?}}{{? pydata.error_key == \"VIRT_CVE_2017_5715_CPU_3_ONLYKERNEL\" }}Red Hat recommends that you update the kernel:\n\n~~~~\n# yum update {{=pydata.kernel_pkg_name}}\n# reboot\n~~~~\n\nIf additional steps to update the kernel are necessary, they are detailed in the separate insights rule *Kernel vulnerable to side-channel attacks in modern microprocessors (CVE-2017-5753/Spectre, CVE-2017-5715/Spectre, CVE-2017-5754/Meltdown)*.\n{{?}}{{? pydata.error_key == \"VIRT_CVE_2017_5715_CPU_3_ONLYVIRT\" || pydata.error_key == \"VIRT_CVE_2017_5715_CPU_3_ONLYDRACUT\" }}Red Hat recommends that you update the packages and restart the system:\n\n~~~~\n# yum update{{~ pydata.PACKAGE_NAMES :value:index}} {{= value }}{{~}}\n# reboot\n~~~~\n{{?}}\n\nFixes require CPU microcode/firmware to activate.\n\n**In addition:**\n\nSubscribers are advised to contact their hardware OEM to receive the appropriate microcode/firmware for their processor. Red Hat may be providing `microcode_ctl` and `linux_firmware` packages that will cover the limited subset of chipsets we were able to test, but this will **not** address many CPUs that you may have in use in your server fleet. Again, contacting your hardware vendor will ensure you have the appropriate software to enable the protections for Variant 2 of this issue.\n",
|
|
"resolution_risk": {
|
|
"name": "Upgrade Kernel",
|
|
"risk": 3
|
|
},
|
|
"has_playbook": true
|
|
}
|
|
],
|
|
"total_risk": 2
|
|
},
|
|
"details": {
|
|
"type": "rule",
|
|
"cves_fail": [
|
|
"CVE-2017-5715"
|
|
],
|
|
"cves_pass": [],
|
|
"error_key": "VIRT_CVE_2017_5715_CPU_3_ONLYKERNEL",
|
|
"kernel_pkg_name": "kernel",
|
|
"affected_amd_family": false
|
|
},
|
|
"resolution": {
|
|
"system_type": 105,
|
|
"resolution": "{{? pydata.error_key == \"VIRT_CVE_2017_5715_CPU_3_VIRTKERNEL\" || pydata.error_key == \"VIRT_CVE_2017_5715_CPU_3_DRACUTKERNEL\" }}Red Hat recommends that you update the kernel and the packages and restart the system:\n\n~~~~\n# yum update{{~ pydata.PACKAGE_NAMES :value:index}} {{= value }}{{~}}\n# yum update {{=pydata.kernel_pkg_name}}\n# reboot\n~~~~\n\nIf additional steps to update the kernel are necessary, they are detailed in the separate insights rule *Kernel vulnerable to side-channel attacks in modern microprocessors (CVE-2017-5753/Spectre, CVE-2017-5715/Spectre, CVE-2017-5754/Meltdown)*.\n{{?}}{{? pydata.error_key == \"VIRT_CVE_2017_5715_CPU_3_ONLYKERNEL\" }}Red Hat recommends that you update the kernel:\n\n~~~~\n# yum update {{=pydata.kernel_pkg_name}}\n# reboot\n~~~~\n\nIf additional steps to update the kernel are necessary, they are detailed in the separate insights rule *Kernel vulnerable to side-channel attacks in modern microprocessors (CVE-2017-5753/Spectre, CVE-2017-5715/Spectre, CVE-2017-5754/Meltdown)*.\n{{?}}{{? pydata.error_key == \"VIRT_CVE_2017_5715_CPU_3_ONLYVIRT\" || pydata.error_key == \"VIRT_CVE_2017_5715_CPU_3_ONLYDRACUT\" }}Red Hat recommends that you update the packages and restart the system:\n\n~~~~\n# yum update{{~ pydata.PACKAGE_NAMES :value:index}} {{= value }}{{~}}\n# reboot\n~~~~\n{{?}}\n\nFixes require CPU microcode/firmware to activate.\n\n**In addition:**\n\nSubscribers are advised to contact their hardware OEM to receive the appropriate microcode/firmware for their processor. Red Hat may be providing `microcode_ctl` and `linux_firmware` packages that will cover the limited subset of chipsets we were able to test, but this will **not** address many CPUs that you may have in use in your server fleet. Again, contacting your hardware vendor will ensure you have the appropriate software to enable the protections for Variant 2 of this issue.\n",
|
|
"resolution_risk": {
|
|
"name": "Upgrade Kernel",
|
|
"risk": 3
|
|
},
|
|
"has_playbook": true
|
|
}
|
|
},
|
|
{
|
|
"id": 16923676,
|
|
"rule": {
|
|
"id": 49,
|
|
"created_at": "2019-02-07T14:02:34.410515-05:00",
|
|
"updated_at": "2019-03-12T11:45:28.875932-04:00",
|
|
"ruleset": {
|
|
"created_at": "2018-12-20T20:33:00-05:00",
|
|
"updated_at": "2018-12-20T20:33:00-05:00",
|
|
"rule_source": "https://$REDACTED$/insights-open-source/insights-security",
|
|
"description": "Security"
|
|
},
|
|
"rule_id": "CVE_2017_5753_4_cpu_kernel|KERNEL_CVE_2017_5753_4_CPU_ERROR_3",
|
|
"description": "Kernel vulnerable to side-channel attacks in modern microprocessors (CVE-2017-5753/Spectre, CVE-2017-5715/Spectre, CVE-2017-5754/Meltdown)",
|
|
"active": true,
|
|
"category": {
|
|
"id": 2,
|
|
"name": "Security"
|
|
},
|
|
"impact": {
|
|
"name": "Information Disclosure",
|
|
"impact": 3
|
|
},
|
|
"likelihood": 2,
|
|
"node_id": "3244101",
|
|
"tags": "security kernel CVE",
|
|
"reboot_required": true,
|
|
"publish_date": "2018-01-22T12:00:00-05:00",
|
|
"summary": "A vulnerability was discovered in modern microprocessors supported by the kernel, whereby an unprivileged attacker can use this flaw to bypass restrictions to gain read access to privileged memory.\nThe issue was reported as [CVE-2017-5753 / CVE-2017-5715 / Spectre](https://access.redhat.com/security/cve/CVE-2017-5753) and [CVE-2017-5754 / Meltdown](https://access.redhat.com/security/cve/CVE-2017-5754).\n",
|
|
"generic": "An industry-wide issue was found in the manner many modern microprocessors have implemented speculative execution of instructions. There are three primary variants of the issue which differ in the way the speculative execution can be exploited.\n\nAll three rely upon the fact that modern high performance microprocessors implement both speculative execution, and utilize VIPT (Virtually Indexed, Physically Tagged) level 1 data caches that may become allocated with data in the kernel virtual address space during such speculation.\n\nAn unprivileged attacker could use these to read privileged memory by conducting targeted cache side-channel attacks, including memory locations that cross the syscall boundary or the guest/host boundary, or potentially arbitrary host memory addresses.\n\nMitigations for these vulnerabilities additionally require firmware/microcode updates from hardware vendors.\n",
|
|
"reason": "This system is vulnerable to the following variant(s):\n\n{{? pydata.problems.v1_vulnerable}}* Variant 1 (Spectre/CVE-2017-5753)\n{{?}}{{? pydata.problems.v2_vulnerable}}* Variant 2 (Spectre/CVE-2017-5715)\n{{?}}{{? pydata.problems.v3_vulnerable}}* Variant 3 (Meltdown/CVE-2017-5754)\n{{?}}\n\n{{ var factors_contributing_displayed = (!pydata.problems.kernel_supports_features || !pydata.problems.firmware_supports_features || pydata.problems.pti_cmdline_disabled || pydata.problems.ibpb_cmdline_disabled || pydata.problems.ibpb_cmdline_spectre_v2_disabled || pydata.problems.ibrs_cmdline_disabled || pydata.problems.ibrs_cmdline_spectre_v2_disabled || pydata.problems.rfi_flush_cmdline_disabled) ; }}{{? factors_contributing_displayed }}Factors contributing to these vulnerabilities are:\n\n{{? !pydata.problems.kernel_supports_features}}* This system's kernel needs updating.\n{{?}}{{? !pydata.problems.firmware_supports_features}}* This system needs a firmware update.\n{{?}}{{? pydata.problems.pti_cmdline_disabled}}* PTI has been disabled by the `nopti` kernel argument.\n{{?}}{{? pydata.problems.ibpb_cmdline_disabled}}* IBPB has been disabled by the `noibpb` kernel argument.\n{{?}}{{? pydata.problems.ibpb_cmdline_spectre_v2_disabled}}* IBPB has been disabled by the `{{=pydata.problems.spectre_v2_disabling_cmdline}}` kernel argument.\n{{?}}{{? pydata.problems.ibrs_cmdline_disabled}}* IBRS has been disabled by the `noibrs` kernel argument.\n{{?}}{{? pydata.problems.ibrs_cmdline_spectre_v2_disabled}}* IBRS has been disabled by the `{{=pydata.problems.spectre_v2_disabling_cmdline}}` kernel argument.\n{{?}}{{? pydata.problems.rfi_flush_cmdline_disabled}}* RFI flush has been disabled by the `no_rfi_flush` kernel argument.\n{{?}}{{?}}\n\n{{? ( pydata.sysfs_vuln_md && (pydata.sysfs_vuln_md.indexOf(\"Vulnerable\") != -1)) || ( pydata.sysfs_vuln_s2 && (/Vulnerable: Minimal.*ASM retpoline/.test(pydata.sysfs_vuln_s2) || pydata.sysfs_vuln_s2.indexOf(\"Vulnerable: Retpoline without IBPB\") != -1 || pydata.sysfs_vuln_s2.indexOf(\"Vulnerable: Retpoline on Skylake\") != -1 || pydata.sysfs_vuln_s2.indexOf(\"Vulnerable: Retpoline with unsafe module\") != -1)) }}{{? factors_contributing_displayed }}Additional details:{{??}}Factors contributing to these vulnerabilities are:{{?}}\n\n{{? pydata.sysfs_vuln_md }}{{? pydata.sysfs_vuln_md.indexOf(\"Vulnerable\") != -1 }}* The CPU is vulnerable to Variant 3 (Meltdown/CVE-2017-5754) and PTI is disabled.\n{{?}}{{?}}{{? pydata.sysfs_vuln_s2 }}{{? /Vulnerable: Minimal.*ASM retpoline/.test(pydata.sysfs_vuln_s2) }}* The kernel has been compiled with an old version of the `gcc` compiler that doesn't support retpolines, so the kernel is vulnerable to Variant 2 (Spectre/CVE-2017-5715).\n{{?}}{{? pydata.sysfs_vuln_s2.indexOf(\"Vulnerable: Retpoline without IBPB\") != -1 }}* The CPU has vulnerable microcode, so the kernel can't use IBPB to mitigate Variant 2 (Spectre/CVE-2017-5715).\n{{?}}{{? pydata.sysfs_vuln_s2.indexOf(\"Vulnerable: Retpoline on Skylake\") != -1 }}* The CPU is Intel Skylake with updated microcode or newer, but retpolines are enabled. This type of CPU requires that IBRS is enabled and retpolines are disabled. The system is vulnerable to Variant 2 (Spectre/CVE-2017-5715) as a result.\n{{?}}{{? pydata.sysfs_vuln_s2.indexOf(\"Vulnerable: Retpoline with unsafe module\") != -1 }}* A kernel module is loaded that has been compiled with a compiler without retpoline support. As a result, the kernel is vulnerable to Variant 2 (Spectre/CVE-2017-5715).\n{{?}}{{?}}{{?}}\n\n{{? !pydata.debugfs_available || pydata.retpo_kernel_but_no_sys_cpu_vuln }}Some diagnostic information was unavailable to Insights.{{?}}\n{{? !pydata.debugfs_available }}* `debugfs` information was not available. {{? pydata.dmesg_available }}Feature settings were inferred from `dmesg` and known vendor defaults.{{??}}`dmesg` information is also unavailable, so it isn't possible to determine which mitigations are available.{{?}}\n{{?}}{{? pydata.retpo_kernel_but_no_sys_cpu_vuln }}* `/sys/devices/system/cpu/vulnerabilities` was not available to Insights, even though the kernel provides it.\n{{?}}\n\n",
|
|
"more_info": "* For more information about the flaws, see [Kernel Side-Channel Attacks](https://access.redhat.com/security/vulnerabilities/speculativeexecution), [CVE-2017-5754](https://access.redhat.com/security/cve/CVE-2017-5754), [CVE-2017-5753](https://access.redhat.com/security/cve/CVE-2017-5753), and [CVE-2017-5715](https://access.redhat.com/security/cve/CVE-2017-5715).\n* For possible performance impact of kernel updates, see [Speculative Execution Exploit Performance Impacts](https://access.redhat.com/articles/3307751).\n* For information related to VMs, see [How do I enable Markdown/Spectre mitigations in my virtualised machines?](https://access.redhat.com/articles/3331571)\n* Extensive details can be found at the [Project Zero blog](https://googleprojectzero.blogspot.ca/2018/01/reading-privileged-memory-with-side.html) and [Meltdown and Spectre Attack webpage](https://meltdownattack.com/).\n* More information about performance impact of the mitigations can be found in the [Speculative Execution Exploit Performance Impacts](https://access.redhat.com/articles/3307751) knowledgebase article.\n* The Customer Portal page for the [Red Hat Security Team](https://access.redhat.com/security/) contains more information about policies, procedures, and alerts for Red Hat products.\n* The Security Team also maintains a frequently updated blog at [securityblog.redhat.com](https://securityblog.redhat.com).\n",
|
|
"resolution_set": [
|
|
{
|
|
"system_type": 105,
|
|
"resolution": "{{? pydata.dmesg_wrapped || !pydata.debugfs_available || pydata.retpo_kernel_but_no_sys_cpu_vuln }}**To improve detection reliability:**{{?}}\n{{? pydata.dmesg_wrapped}}* The kernel ring buffer has wrapped, making some information from `dmesg` unreliable. See [How do I increase the kernel log ring buffer size?](https://access.redhat.com/solutions/47276) for further information. Rebooting the system may also overcome this issue.\n{{?}}{{? !pydata.debugfs_available}}* Kernel debug information was not available. Mount `debugfs` as follows: \n{{? pydata.release >= 7 }}\n ~~~\n # systemctl restart sys-kernel-debug.mount\n ~~~\n{{??}}\n ~~~\n # mount -t debugfs nodev /sys/kernel/debug\n ~~~\n{{?}}{{?}}{{? pydata.retpo_kernel_but_no_sys_cpu_vuln}}* Allow Insights to collect `/sys/devices/system/cpu/vulnerabilities`.\n{{?}}\n\n**To mitigate the vulnerability:**\n{{? ( pydata.dmesg_wrapped || !pydata.dmesg_available ) && !pydata.debugfs_available && (!pydata.sysfs_vuln_s1 && !pydata.sysfs_vuln_s2 && !pydata.sysfs_vuln_md) }}* It might be necessary to improve detection reliability before we can offer more concrete mitigation steps.{{? !pydata.problems.kernel_supports_features}} If it is not possible, update the kernel package and reboot:\n ~~~\n # yum update {{=pydata.package_name}}\n # reboot\n ~~~\n{{?}}\n{{?}}{{? pydata.dmesg_available && !pydata.problems.kernel_supports_features }}* This system is running a vulnerable kernel. Update the kernel package and reboot:\n ~~~\n # yum update {{=pydata.package_name}}\n # reboot\n ~~~\n{{?}}{{? ((pydata.debugfs_available || pydata.dmesg_available) && !pydata.problems.firmware_supports_features) || (pydata.sysfs_vuln_s2 && (pydata.sysfs_vuln_s2.indexOf(\"Vulnerable: Retpoline without IBPB\") != -1)) }}* This system needs a firmware update. Contact your system hardware vendor for more information.\n{{?}}{{? pydata.problems.pti_cmdline_disabled }}* Remove the `nopti` kernel argument:\n ~~~\n # grubby --update-kernel=ALL --remove-args=nopti\n ~~~\n{{?}}{{? pydata.problems.ibpb_cmdline_disabled }}* Remove the `noibpb` kernel argument:\n ~~~\n # grubby --update-kernel=ALL --remove-args=noibpb\n ~~~\n{{?}}{{? pydata.problems.ibrs_cmdline_disabled }}* Remove the `noibrs` kernel argument:\n ~~~\n # grubby --update-kernel=ALL --remove-args=noibrs\n ~~~\n{{?}}{{? ( pydata.problems.ibpb_cmdline_spectre_v2_disabled || pydata.problems.ibrs_cmdline_spectre_v2_disabled ) && ( pydata.problems.spectre_v2_disabling_cmdline.indexOf(\"v2=\") != -1 ) }}* Remove the `spectre_v2` kernel argument:\n ~~~\n # grubby --update-kernel=ALL --remove-args=spectre_v2\n ~~~\n{{?}}{{? ( pydata.problems.ibpb_cmdline_spectre_v2_disabled || pydata.problems.ibrs_cmdline_spectre_v2_disabled ) && ( pydata.problems.spectre_v2_disabling_cmdline.indexOf(\"nospectre\") != -1 ) }}* Remove the `nospectre_v2` kernel argument:\n ~~~\n # grubby --update-kernel=ALL --remove-args=nospectre_v2\n ~~~\n{{?}}{{? pydata.problems.rfi_flush_cmdline_disabled }}* Remove the `no_rfi_flush` kernel argument:\n ~~~\n # grubby --update-kernel=ALL --remove-args=no_rfi_flush\n ~~~\n{{?}}{{? pydata.sysfs_vuln_s2 }}{{? /Vulnerable: Minimal.*ASM retpoline/.test(pydata.sysfs_vuln_s2) }}* This system is running a custom kernel that has been compiled with outdated `gcc`. Either recompile the kernel with retpoline-enabled `gcc` or update the kernel package and reboot:\n ~~~\n # yum update {{=pydata.package_name}}\n # reboot\n ~~~\n{{?}}{{? pydata.sysfs_vuln_s2.indexOf(\"Vulnerable: Retpoline on Skylake\") != -1 }}* Enable IBRS and disable retpolines. Retpolines are disabled automatically when IBRS is enabled:\n ~~~\n # echo 1 > /sys/kernel/debug/x86/ibrs_enabled\n ~~~\n{{?}}{{? pydata.sysfs_vuln_s2.indexOf(\"Vulnerable: Retpoline with unsafe module\") != -1 }}* Unload the kernel modules that have been compiled without a retpoline-enabled compiler. To find the affected kernel modules:\n ~~~\n # dmesg | grep \"WARNING: module.*built without retpoline-enabled compiler\"\n ~~~\nTo unload the module:\n ~~~\n # modprobe -r module_name\n ~~~\n{{?}}{{?}}{{? pydata.problems.pti_cmdline_disabled || pydata.problems.ibpb_cmdline_disabled || pydata.problems.ibrs_cmdline_disabled || pydata.problems.ibpb_cmdline_spectre_v2_disabled || pydata.problems.ibrs_cmdline_spectre_v2_disabled || pydata.problems.rfi_flush_cmdline_disabled }}\n ~~~\n # reboot\n ~~~\n {{?}}\n\n{{? !pydata.virtual == false || pydata.virtual === null }}**Note about virtualization**\n\nIn virtualized environment, there are more steps to mitigate the issue, including:\n* Host needs to have updated kernel and CPU microcode\n* Host needs to have updated virtualization software\n* Guest needs to have updated kernel\n* Hypervisor needs to propagate new CPU features correctly\n\nFor more details about mitigations in virtualized environment see: [https://access.redhat.com/articles/3331571](https://access.redhat.com/articles/3331571){{?}}\n\n{{? pydata.virtual == \"vmware\" }}For help with setting VMWare to propagate CPU features correctly, refer to the following knowledge-base article: [https://kb.vmware.com/s/article/52085](https://kb.vmware.com/s/article/52085){{?}}\n",
|
|
"resolution_risk": {
|
|
"name": "Upgrade Kernel",
|
|
"risk": 3
|
|
},
|
|
"has_playbook": true
|
|
}
|
|
],
|
|
"total_risk": 2
|
|
},
|
|
"details": {
|
|
"mfr": "Intel",
|
|
"type": "rule",
|
|
"virtual": "kvm",
|
|
"problems": {
|
|
"v1_vulnerable": false,
|
|
"v2_vulnerable": true,
|
|
"v3_vulnerable": false,
|
|
"pti_cmdline_disabled": false,
|
|
"ibpb_cmdline_disabled": false,
|
|
"ibrs_cmdline_disabled": false,
|
|
"kernel_supports_features": true,
|
|
"firmware_supports_features": false,
|
|
"rfi_flush_cmdline_disabled": false,
|
|
"spectre_v2_disabling_cmdline": null,
|
|
"ibpb_cmdline_spectre_v2_disabled": false,
|
|
"ibrs_cmdline_spectre_v2_disabled": false
|
|
},
|
|
"cves_fail": [
|
|
"CVE-2017-5715"
|
|
],
|
|
"cves_pass": [
|
|
"CVE-2017-5753",
|
|
"CVE-2017-5754"
|
|
],
|
|
"error_key": "KERNEL_CVE_2017_5753_4_CPU_ERROR_3",
|
|
"package_name": "kernel",
|
|
"dmesg_wrapped": false,
|
|
"release_major": "7",
|
|
"sysfs_vuln_md": "Mitigation: PTI",
|
|
"sysfs_vuln_s1": "Mitigation: Load fences, __user pointer sanitization",
|
|
"sysfs_vuln_s2": "Vulnerable: Retpoline without IBPB",
|
|
"running_kernel": "3.10.0-862.14.4.el7.x86_64",
|
|
"dmesg_available": true,
|
|
"debugfs_available": true,
|
|
"old_specs_on_client": false,
|
|
"retpo_kernel_but_no_sys_cpu_vuln": false
|
|
},
|
|
"resolution": {
|
|
"system_type": 105,
|
|
"resolution": "{{? pydata.dmesg_wrapped || !pydata.debugfs_available || pydata.retpo_kernel_but_no_sys_cpu_vuln }}**To improve detection reliability:**{{?}}\n{{? pydata.dmesg_wrapped}}* The kernel ring buffer has wrapped, making some information from `dmesg` unreliable. See [How do I increase the kernel log ring buffer size?](https://access.redhat.com/solutions/47276) for further information. Rebooting the system may also overcome this issue.\n{{?}}{{? !pydata.debugfs_available}}* Kernel debug information was not available. Mount `debugfs` as follows: \n{{? pydata.release >= 7 }}\n ~~~\n # systemctl restart sys-kernel-debug.mount\n ~~~\n{{??}}\n ~~~\n # mount -t debugfs nodev /sys/kernel/debug\n ~~~\n{{?}}{{?}}{{? pydata.retpo_kernel_but_no_sys_cpu_vuln}}* Allow Insights to collect `/sys/devices/system/cpu/vulnerabilities`.\n{{?}}\n\n**To mitigate the vulnerability:**\n{{? ( pydata.dmesg_wrapped || !pydata.dmesg_available ) && !pydata.debugfs_available && (!pydata.sysfs_vuln_s1 && !pydata.sysfs_vuln_s2 && !pydata.sysfs_vuln_md) }}* It might be necessary to improve detection reliability before we can offer more concrete mitigation steps.{{? !pydata.problems.kernel_supports_features}} If it is not possible, update the kernel package and reboot:\n ~~~\n # yum update {{=pydata.package_name}}\n # reboot\n ~~~\n{{?}}\n{{?}}{{? pydata.dmesg_available && !pydata.problems.kernel_supports_features }}* This system is running a vulnerable kernel. Update the kernel package and reboot:\n ~~~\n # yum update {{=pydata.package_name}}\n # reboot\n ~~~\n{{?}}{{? ((pydata.debugfs_available || pydata.dmesg_available) && !pydata.problems.firmware_supports_features) || (pydata.sysfs_vuln_s2 && (pydata.sysfs_vuln_s2.indexOf(\"Vulnerable: Retpoline without IBPB\") != -1)) }}* This system needs a firmware update. Contact your system hardware vendor for more information.\n{{?}}{{? pydata.problems.pti_cmdline_disabled }}* Remove the `nopti` kernel argument:\n ~~~\n # grubby --update-kernel=ALL --remove-args=nopti\n ~~~\n{{?}}{{? pydata.problems.ibpb_cmdline_disabled }}* Remove the `noibpb` kernel argument:\n ~~~\n # grubby --update-kernel=ALL --remove-args=noibpb\n ~~~\n{{?}}{{? pydata.problems.ibrs_cmdline_disabled }}* Remove the `noibrs` kernel argument:\n ~~~\n # grubby --update-kernel=ALL --remove-args=noibrs\n ~~~\n{{?}}{{? ( pydata.problems.ibpb_cmdline_spectre_v2_disabled || pydata.problems.ibrs_cmdline_spectre_v2_disabled ) && ( pydata.problems.spectre_v2_disabling_cmdline.indexOf(\"v2=\") != -1 ) }}* Remove the `spectre_v2` kernel argument:\n ~~~\n # grubby --update-kernel=ALL --remove-args=spectre_v2\n ~~~\n{{?}}{{? ( pydata.problems.ibpb_cmdline_spectre_v2_disabled || pydata.problems.ibrs_cmdline_spectre_v2_disabled ) && ( pydata.problems.spectre_v2_disabling_cmdline.indexOf(\"nospectre\") != -1 ) }}* Remove the `nospectre_v2` kernel argument:\n ~~~\n # grubby --update-kernel=ALL --remove-args=nospectre_v2\n ~~~\n{{?}}{{? pydata.problems.rfi_flush_cmdline_disabled }}* Remove the `no_rfi_flush` kernel argument:\n ~~~\n # grubby --update-kernel=ALL --remove-args=no_rfi_flush\n ~~~\n{{?}}{{? pydata.sysfs_vuln_s2 }}{{? /Vulnerable: Minimal.*ASM retpoline/.test(pydata.sysfs_vuln_s2) }}* This system is running a custom kernel that has been compiled with outdated `gcc`. Either recompile the kernel with retpoline-enabled `gcc` or update the kernel package and reboot:\n ~~~\n # yum update {{=pydata.package_name}}\n # reboot\n ~~~\n{{?}}{{? pydata.sysfs_vuln_s2.indexOf(\"Vulnerable: Retpoline on Skylake\") != -1 }}* Enable IBRS and disable retpolines. Retpolines are disabled automatically when IBRS is enabled:\n ~~~\n # echo 1 > /sys/kernel/debug/x86/ibrs_enabled\n ~~~\n{{?}}{{? pydata.sysfs_vuln_s2.indexOf(\"Vulnerable: Retpoline with unsafe module\") != -1 }}* Unload the kernel modules that have been compiled without a retpoline-enabled compiler. To find the affected kernel modules:\n ~~~\n # dmesg | grep \"WARNING: module.*built without retpoline-enabled compiler\"\n ~~~\nTo unload the module:\n ~~~\n # modprobe -r module_name\n ~~~\n{{?}}{{?}}{{? pydata.problems.pti_cmdline_disabled || pydata.problems.ibpb_cmdline_disabled || pydata.problems.ibrs_cmdline_disabled || pydata.problems.ibpb_cmdline_spectre_v2_disabled || pydata.problems.ibrs_cmdline_spectre_v2_disabled || pydata.problems.rfi_flush_cmdline_disabled }}\n ~~~\n # reboot\n ~~~\n {{?}}\n\n{{? !pydata.virtual == false || pydata.virtual === null }}**Note about virtualization**\n\nIn virtualized environment, there are more steps to mitigate the issue, including:\n* Host needs to have updated kernel and CPU microcode\n* Host needs to have updated virtualization software\n* Guest needs to have updated kernel\n* Hypervisor needs to propagate new CPU features correctly\n\nFor more details about mitigations in virtualized environment see: [https://access.redhat.com/articles/3331571](https://access.redhat.com/articles/3331571){{?}}\n\n{{? pydata.virtual == \"vmware\" }}For help with setting VMWare to propagate CPU features correctly, refer to the following knowledge-base article: [https://kb.vmware.com/s/article/52085](https://kb.vmware.com/s/article/52085){{?}}\n",
|
|
"resolution_risk": {
|
|
"name": "Upgrade Kernel",
|
|
"risk": 3
|
|
},
|
|
"has_playbook": true
|
|
}
|
|
},
|
|
{
|
|
"id": 16923673,
|
|
"rule": {
|
|
"id": 72,
|
|
"created_at": "2019-02-07T14:02:34.653624-05:00",
|
|
"updated_at": "2019-03-12T11:45:29.372525-04:00",
|
|
"ruleset": {
|
|
"created_at": "2018-12-20T20:33:00-05:00",
|
|
"updated_at": "2018-12-20T20:33:00-05:00",
|
|
"rule_source": "https://$REDACTED$/insights-open-source/insights-security",
|
|
"description": "Security"
|
|
},
|
|
"rule_id": "CVE_2018_3639_cpu_kernel|CVE_2018_3639_CPU_BAD_MICROCODE",
|
|
"description": "Kernel vulnerable to side-channel attacks in modern microprocessors using Speculative Store Bypass when CPU microcode is outdated (CVE-2018-3639)",
|
|
"active": true,
|
|
"category": {
|
|
"id": 2,
|
|
"name": "Security"
|
|
},
|
|
"impact": {
|
|
"name": "Local Privilege Escalation",
|
|
"impact": 2
|
|
},
|
|
"likelihood": 2,
|
|
"node_id": "3448801",
|
|
"tags": "security",
|
|
"reboot_required": true,
|
|
"publish_date": "2018-05-21T21:00:00-04:00",
|
|
"summary": "An industry-wide issue was found in the manner in which many modern microprocessors have implemented speculative execution of instructions. It has been assigned [CVE-2018-3639](https://access.redhat.com/security/cve/CVE-2018-3639). Mitigations for this vulnerability require firmware/microcode updates from hardware vendors.\n\nAn unprivileged attacker can use this flaw to bypass restrictions in order to gain read access to privileged memory that would otherwise be inaccessible.\n",
|
|
"generic": "An industry-wide issue was found in the manner in which many modern microprocessors have implemented speculative execution of instructions. The flaw is similar to CVE-2017-5753 (aka \"Spectre v1\"), except it leverages Speculative Store Bypass memory optimization in place of the Branch Misprediction used by Spectre v1.\n\nAn unprivileged attacker can use this flaw to bypass restrictions in order to gain read access to privileged memory that would otherwise be inaccessible, e.g. to memory outside of a sandboxed environments like web browsers or JIT execution runtimes.\n\nMitigations for this vulnerability require firmware/microcode updates from hardware vendors.\n\nRed Hat recommends that you update the kernel and update firmware.\n",
|
|
"reason": "The system is vulnerable because:\n\n* CPU microcode requires an update\n",
|
|
"more_info": "* For more information about the flaw, see [the vulnerability article](https://access.redhat.com/security/vulnerabilities/ssbd).\n* To learn how to upgrade packages, see [What is yum and how do I use it?](https://access.redhat.com/solutions/9934).\n* The Customer Portal page for the [Red Hat Security Team](https://access.redhat.com/security/) contains more information about policies, procedures, and alerts for Red Hat products.\n* The Security Team also maintains a frequently updated blog at [securityblog.redhat.com](https://securityblog.redhat.com).\n",
|
|
"resolution_set": [
|
|
{
|
|
"system_type": 105,
|
|
"resolution": "This system needs a firmware update. Contact your system hardware vendor for more information.\n\n{{? !pydata.virtual == false || pydata.virtual === null}}**Note about virtualization**\n\nIn virtualized environment, there are more steps to mitigate the issue, including:\n* Host needs to have updated kernel and CPU microcode\n* Host needs to have updated virtualization software\n* Guest needs to have updated kernel\n* Hypervisor needs to propagate new CPU features correctly\n\nFor more details about mitigations in virtualized environment see: [https://access.redhat.com/articles/3331571](https://access.redhat.com/articles/3331571){{?}}\n\n{{? pydata.virtual == \"vmware\" }}For help with setting VMWare to propagate CPU features correctly, refer to the following knowledge-base article: [https://kb.vmware.com/s/article/52085](https://kb.vmware.com/s/article/52085){{?}}\n",
|
|
"resolution_risk": {
|
|
"name": "Hardware Vendor Firmware Update",
|
|
"risk": 3
|
|
},
|
|
"has_playbook": false
|
|
}
|
|
],
|
|
"total_risk": 2
|
|
},
|
|
"details": {
|
|
"rt": false,
|
|
"type": "rule",
|
|
"virtual": "kvm",
|
|
"cmd_avail": true,
|
|
"cves_fail": [
|
|
"CVE-2018-3639"
|
|
],
|
|
"cves_pass": [],
|
|
"error_key": "CVE_2018_3639_CPU_BAD_MICROCODE",
|
|
"running_kernel": "3.10.0-862.14.4.el7.x86_64",
|
|
"vuln_file_present": true
|
|
},
|
|
"resolution": {
|
|
"system_type": 105,
|
|
"resolution": "This system needs a firmware update. Contact your system hardware vendor for more information.\n\n{{? !pydata.virtual == false || pydata.virtual === null}}**Note about virtualization**\n\nIn virtualized environment, there are more steps to mitigate the issue, including:\n* Host needs to have updated kernel and CPU microcode\n* Host needs to have updated virtualization software\n* Guest needs to have updated kernel\n* Hypervisor needs to propagate new CPU features correctly\n\nFor more details about mitigations in virtualized environment see: [https://access.redhat.com/articles/3331571](https://access.redhat.com/articles/3331571){{?}}\n\n{{? pydata.virtual == \"vmware\" }}For help with setting VMWare to propagate CPU features correctly, refer to the following knowledge-base article: [https://kb.vmware.com/s/article/52085](https://kb.vmware.com/s/article/52085){{?}}\n",
|
|
"resolution_risk": {
|
|
"name": "Hardware Vendor Firmware Update",
|
|
"risk": 3
|
|
},
|
|
"has_playbook": false
|
|
}
|
|
},
|
|
{
|
|
"id": 16923678,
|
|
"rule": {
|
|
"id": 193,
|
|
"created_at": "2019-02-07T14:02:35.803497-05:00",
|
|
"updated_at": "2019-02-07T14:02:35.803513-05:00",
|
|
"ruleset": {
|
|
"created_at": "2018-12-20T20:33:00-05:00",
|
|
"updated_at": "2018-12-20T20:33:00-05:00",
|
|
"rule_source": "https://$REDACTED$/insights-open-source/insights-security",
|
|
"description": "Security"
|
|
},
|
|
"rule_id": "hardening_httpd_pci_dss|HARDENING_HTTPD_PCI_DSS",
|
|
"description": "Decreased security in httpd when using deprecated TLS protocol version (PCI DSS)",
|
|
"active": true,
|
|
"category": {
|
|
"id": 2,
|
|
"name": "Security"
|
|
},
|
|
"impact": {
|
|
"name": "Hardening",
|
|
"impact": 1
|
|
},
|
|
"likelihood": 1,
|
|
"node_id": "",
|
|
"tags": "httpd hardening security",
|
|
"reboot_required": false,
|
|
"publish_date": "2018-10-20T00:00:00-04:00",
|
|
"summary": "PCI Data Security Standard [mandates disabling](https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls) TLS versions older than 1.1 for safeguarding payment data.\n",
|
|
"generic": "These hosts are running httpd with legacy SSL or TLS versions enabled and might be non-compliant with the PCI Data Security Standard.\n\nRed Hat recommends that you change your httpd/Apache configuration files. Select a host to see the host-specific details that need to be updated within the httpd/Apache configuration.\n",
|
|
"reason": "This host is running httpd with legacy SSL or TLS versions enabled and might be non-compliant with the PCI Data Security Standard.\n",
|
|
"more_info": "* For more information about the new PCI DSS rules, see [the article](https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls)\n* [How do I globally disable TLSv1.0 on my RHEL server?](https://access.redhat.com/solutions/2157131)\n* The Customer Portal page for the [Red Hat Security Team](https://access.redhat.com/security/) contains more information about policies, procedures, and alerts for Red Hat Products.\n* The Security Team also maintains a frequently updated blog at [securityblog.redhat.com](https://securityblog.redhat.com).\n",
|
|
"resolution_set": [
|
|
{
|
|
"system_type": 19,
|
|
"resolution": "Red Hat recommends that you disable SSLv3 and TLSv1.0.\n\n{{?pydata.ssl_protocols}}**The following SSLProtocol directive(s) in the respective Apache configuration files will need to be modified:**\n<ul>{{~pydata.ssl_protocols: ssl}}\n<li>`{{=ssl[0]}}` - `{{=ssl[1]}}`</li>\n{{~}}</ul>\n\nRed Hat recommends that either of these `SSLProtocol` configurations is used:\n* `SSLProtocol -all +TLSv1.1 +TLSv1.2`\n* `SSLProtocol all -SSLv2 -SSLv3 -TLSv1`\n\nFor additional hardening, to use TLS 1.2 only, use either of these `SSLProtocol` configurations:\n* `SSLProtocol -all +TLSv1.2`\n* `SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1`\n{{?}}\n\n{{?pydata.nss_protocols}}**The following NSSProtocol directive(s) in the respective Apache configuration files will need to be modified:**\n<ul>{{~pydata.nss_protocols: nss}}\n<li>`{{=nss[0]}}` - `{{=nss[1]}}`</li>\n{{~}}</ul>\n\nRed Hat recommends that this `NSSProtocol` configuration is used:\n* `NSSProtocol TLSv1.1,TLSv1.2`\n\nFor additional hardening, to use TLS 1.2 only, use the following `NSSProtocol` configuration:\n* `NSSProtocol TLSv1.2`\n{{?}}\n\nThen restart httpd:\n\n # service httpd restart\n\nMake the changes permanent in the container image by using the **docker commit** command at the next container shutdown.\n\n{{?pydata.scl_installed}}You have installed httpd from Software Collections, which uses a different configuration files path from the default httpd. Some of the detected configuration files might be applicable only if the respective httpd package is used. Red Hat recommends resolving all listed issues to prevent inadvertent exposure to the vulnerability in case the httpd you use changes in the future.\n{{?}}\n",
|
|
"resolution_risk": {
|
|
"name": "Update Service Configuration",
|
|
"risk": 3
|
|
},
|
|
"has_playbook": false
|
|
},
|
|
{
|
|
"system_type": 105,
|
|
"resolution": "Red Hat recommends that you disable SSLv3 and TLSv1.0.\n\n{{?pydata.ssl_protocols}}**The following SSLProtocol directive(s) in the respective Apache configuration files will need to be modified:**\n{{~pydata.ssl_protocols: ssl}}* `{{=ssl[0]}}` - {{=ssl[1]}}\n{{~}}\n\nRed Hat recommends that either of these `SSLProtocol` configurations is used:\n* `SSLProtocol -all +TLSv1.1 +TLSv1.2`\n* `SSLProtocol all -SSLv2 -SSLv3 -TLSv1`\n\nFor additional hardening, to use TLS 1.2 only, use either of these `SSLProtocol` configurations:\n* `SSLProtocol -all +TLSv1.2`\n* `SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1`\n{{?}}\n\n{{?pydata.nss_protocols}}**The following NSSProtocol directive(s) in the respective Apache configuration files will need to be modified:**\n{{~pydata.nss_protocols: nss}}* `{{=nss[0]}}` - {{=nss[1]}}\n{{~}}\n\nRed Hat recommends that this `NSSProtocol` configuration is used:\n* `NSSProtocol TLSv1.1,TLSv1.2`\n\nFor additional hardening, to use TLS 1.2 only, use the following `NSSProtocol` configuration:\n* `NSSProtocol TLSv1.2`\n{{?}}\n\nThen restart httpd:\n\n # service httpd restart\n\n{{?pydata.scl_installed}}You have installed httpd from Software Collections, which uses a different configuration files path from the default httpd. Some of the detected configuration files might be applicable only if the respective httpd package is used. Red Hat recommends resolving all listed issues to prevent inadvertent exposure to the vulnerability in case the httpd you use changes in the future.\n{{?}}\n",
|
|
"resolution_risk": {
|
|
"name": "Update Service Configuration",
|
|
"risk": 3
|
|
},
|
|
"has_playbook": false
|
|
},
|
|
{
|
|
"system_type": 29,
|
|
"resolution": "Red Hat recommends that you disable SSLv3 and TLSv1.0.\n\n{{?pydata.ssl_protocols}}**The following SSLProtocol directive(s) in the respective Apache configuration files will need to be modified:**\n<ul>{{~pydata.ssl_protocols: ssl}}\n<li>`{{=ssl[0]}}` - `{{=ssl[1]}}`</li>\n{{~}}</ul>\n\nRed Hat recommends that either of these `SSLProtocol` configurations is used:\n* `SSLProtocol -all +TLSv1.1 +TLSv1.2`\n* `SSLProtocol all -SSLv2 -SSLv3 -TLSv1`\n\nFor additional hardening, to use TLS 1.2 only, use either of these `SSLProtocol` configurations:\n* `SSLProtocol -all +TLSv1.2`\n* `SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1`\n{{?}}\n\n{{?pydata.nss_protocols}}**The following NSSProtocol directive(s) in the respective Apache configuration files will need to be modified:**\n<ul>{{~pydata.nss_protocols: nss}}\n<li>`{{=nss[0]}}` - `{{=nss[1]}}`</li>\n{{~}}</ul>\n\nRed Hat recommends that this `NSSProtocol` configuration is used:\n* `NSSProtocol TLSv1.1,TLSv1.2`\n\nFor additional hardening, to use TLS 1.2 only, use the following `NSSProtocol` configuration:\n* `NSSProtocol TLSv1.2`\n{{?}}\n\nMake the changes permanent in the image by using the **docker commit** command.\n\n{{?pydata.scl_installed}}You have installed httpd from Software Collections, which uses a different configuration files path from the default httpd. Some of the detected configuration files might be applicable only if the respective httpd package is used. Red Hat recommends resolving all listed issues to prevent inadvertent exposure to the vulnerability in case the httpd you use changes in the future.\n{{?}}\n",
|
|
"resolution_risk": {
|
|
"name": "Update Service Configuration",
|
|
"risk": 3
|
|
},
|
|
"has_playbook": false
|
|
}
|
|
],
|
|
"total_risk": 1
|
|
},
|
|
"details": {
|
|
"type": "rule",
|
|
"error_key": "HARDENING_HTTPD_PCI_DSS",
|
|
"nss_protocols": [
|
|
[
|
|
"NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2",
|
|
"/etc/httpd/conf.d/nss.conf"
|
|
]
|
|
],
|
|
"scl_installed": false,
|
|
"ssl_protocols": null
|
|
},
|
|
"resolution": {
|
|
"system_type": 105,
|
|
"resolution": "Red Hat recommends that you disable SSLv3 and TLSv1.0.\n\n{{?pydata.ssl_protocols}}**The following SSLProtocol directive(s) in the respective Apache configuration files will need to be modified:**\n{{~pydata.ssl_protocols: ssl}}* `{{=ssl[0]}}` - {{=ssl[1]}}\n{{~}}\n\nRed Hat recommends that either of these `SSLProtocol` configurations is used:\n* `SSLProtocol -all +TLSv1.1 +TLSv1.2`\n* `SSLProtocol all -SSLv2 -SSLv3 -TLSv1`\n\nFor additional hardening, to use TLS 1.2 only, use either of these `SSLProtocol` configurations:\n* `SSLProtocol -all +TLSv1.2`\n* `SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1`\n{{?}}\n\n{{?pydata.nss_protocols}}**The following NSSProtocol directive(s) in the respective Apache configuration files will need to be modified:**\n{{~pydata.nss_protocols: nss}}* `{{=nss[0]}}` - {{=nss[1]}}\n{{~}}\n\nRed Hat recommends that this `NSSProtocol` configuration is used:\n* `NSSProtocol TLSv1.1,TLSv1.2`\n\nFor additional hardening, to use TLS 1.2 only, use the following `NSSProtocol` configuration:\n* `NSSProtocol TLSv1.2`\n{{?}}\n\nThen restart httpd:\n\n # service httpd restart\n\n{{?pydata.scl_installed}}You have installed httpd from Software Collections, which uses a different configuration files path from the default httpd. Some of the detected configuration files might be applicable only if the respective httpd package is used. Red Hat recommends resolving all listed issues to prevent inadvertent exposure to the vulnerability in case the httpd you use changes in the future.\n{{?}}\n",
|
|
"resolution_risk": {
|
|
"name": "Update Service Configuration",
|
|
"risk": 3
|
|
},
|
|
"has_playbook": false
|
|
}
|
|
},
|
|
{
|
|
"id": 16923677,
|
|
"rule": {
|
|
"id": 235,
|
|
"created_at": "2019-02-07T14:02:36.236195-05:00",
|
|
"updated_at": "2019-02-11T15:21:37.409742-05:00",
|
|
"ruleset": {
|
|
"created_at": "2018-05-21T22:00:51-04:00",
|
|
"updated_at": "2018-05-21T22:00:51-04:00",
|
|
"rule_source": "https://$REDACTED$/insights-open-source/insights-plugins",
|
|
"description": "Advisor"
|
|
},
|
|
"rule_id": "httpd24_deprecated_order|DEPRECATED_ORDER_USED_INFO_V1",
|
|
"description": "Unexpected behavior when using deprecated access control directives in httpd 2.4",
|
|
"active": true,
|
|
"category": {
|
|
"id": 1,
|
|
"name": "Availability"
|
|
},
|
|
"impact": {
|
|
"name": "Invalid Configuration",
|
|
"impact": 1
|
|
},
|
|
"likelihood": 3,
|
|
"node_id": "",
|
|
"tags": "sbr_webservers webservers httpd",
|
|
"reboot_required": false,
|
|
"publish_date": "2018-05-30T20:39:00-04:00",
|
|
"summary": "The httpd service does not work as expected when using old directives in httpd-2.4.\n",
|
|
"generic": "Access control is using deprecated directives (\"Order\", \"Allow\" and \"Deny\") provided by `mod_authz_compat` which has been replaced by `mod_authz_host` in **httpd 2.4**.\n",
|
|
"reason": "This host is running **{{=pydata.ver}}** and using the following old directives (`Order`, `Allow` or `Deny`) which have been deprecated:\n\n{{ for (var _sec in pydata.dep_conf) { }}\n* Section `<{{=_sec}}>`\n {{ for (var file in pydata.dep_conf[_sec]) { }} * Configuration file `{{=file}}`\n ```text {{ for (var dir in pydata.dep_conf[_sec][file]) { }}\n {{=pydata.dep_conf[_sec][file][dir]}} {{ } }}\n ```\n {{ } }}\n{{ } }}\n",
|
|
"more_info": "",
|
|
"resolution_set": [
|
|
{
|
|
"system_type": 105,
|
|
"resolution": "Red Hat recommends that you replace the old directives (\"Order\", \"Allow\" and \"Deny\") with the new directive (\"Require\") in **httpd-2.4**. Please check the [Upgrading to 2.4 from 2.2](http://httpd.apache.org/docs/2.4/upgrading.html) guide for more information.\n",
|
|
"resolution_risk": {
|
|
"name": "Update Service Configuration",
|
|
"risk": 3
|
|
},
|
|
"has_playbook": false
|
|
}
|
|
],
|
|
"total_risk": 2
|
|
},
|
|
"details": {
|
|
"ver": "httpd-2.4.6-80.el7",
|
|
"type": "rule",
|
|
"dep_conf": {
|
|
"Location /KdcProxy": {
|
|
"/etc/httpd/conf.d/ipa-kdc-proxy.conf": [
|
|
"Order Deny,Allow",
|
|
"Allow from all"
|
|
]
|
|
},
|
|
"Directory /usr/share/fonts": {
|
|
"/etc/httpd/conf.d/ipa.conf": [
|
|
"Allow from all"
|
|
]
|
|
},
|
|
"Directory /usr/share/ipa/ui": {
|
|
"/etc/httpd/conf.d/ipa.conf": [
|
|
"Allow from all"
|
|
]
|
|
},
|
|
"Directory /usr/share/ipa/html": {
|
|
"/etc/httpd/conf.d/ipa.conf": [
|
|
"Allow from all"
|
|
]
|
|
},
|
|
"Directory /usr/share/ipa/wsgi": {
|
|
"/etc/httpd/conf.d/ipa.conf": [
|
|
"Allow from all"
|
|
]
|
|
},
|
|
"Location /ipa/session/sync_token": {
|
|
"/etc/httpd/conf.d/ipa.conf": [
|
|
"Order Deny,Allow",
|
|
"Allow from all"
|
|
]
|
|
},
|
|
"Directory /usr/share/ipa/migration": {
|
|
"/etc/httpd/conf.d/ipa.conf": [
|
|
"Allow from all"
|
|
]
|
|
},
|
|
"Location /ipa/session/login_password": {
|
|
"/etc/httpd/conf.d/ipa.conf": [
|
|
"Order Deny,Allow",
|
|
"Allow from all"
|
|
]
|
|
},
|
|
"Directory /var/lib/ipa/pki-ca/publish": {
|
|
"/etc/httpd/conf.d/ipa.conf": [
|
|
"Allow from all"
|
|
]
|
|
},
|
|
"Location /ipa/session/change_password": {
|
|
"/etc/httpd/conf.d/ipa.conf": [
|
|
"Order Deny,Allow",
|
|
"Allow from all"
|
|
]
|
|
}
|
|
},
|
|
"error_key": "DEPRECATED_ORDER_USED_INFO_V1"
|
|
},
|
|
"resolution": {
|
|
"system_type": 105,
|
|
"resolution": "Red Hat recommends that you replace the old directives (\"Order\", \"Allow\" and \"Deny\") with the new directive (\"Require\") in **httpd-2.4**. Please check the [Upgrading to 2.4 from 2.2](http://httpd.apache.org/docs/2.4/upgrading.html) guide for more information.\n",
|
|
"resolution_risk": {
|
|
"name": "Update Service Configuration",
|
|
"risk": 3
|
|
},
|
|
"has_playbook": false
|
|
}
|
|
}
|
|
]
|