drovorun in the wild - applicable for redhat?

Latest response

There is a newly discovered exploit called "drovorub" that allows linux kernels to be infiltrated. If we are downloading genuine kernels thru Satellite, do we need to be concerned?

Recommendation from NSA to to upgrade to kernel 3.7 minimum and
/ or implement UEFI secureboot with signed kernels. Does this mean BIOS boot systems are a risk now?

Responses

Hi Ian,

An official answer can only be provided by a Red Hat employee.

You may consider opening a support case

Based on the NSA recommendation and the Red Hat article Red Hat Enterprise Linux Release Dates I would conclude: RHEL 6 and older might be vulnerable. RHEL 7 and newer probably not

I opened a support to get an answer, could you open one too so it may get a higher priority?

Regards,

Jan Gerrit Kootstra

Please do contact our Product Security Team at secalert@redhat.com to get an official analysis and answer.

We have an article published now at https://access.redhat.com/articles/5320961

Reading the article it states that it is not a kernel vulnerability.

To my understanding, it is malware that needs to be installed (maybe by accident) by someone who has access to the system already.

They could also be exploiting unknown or known vulnerabilities in systems that have failed to upgrade to versions that include the patch solving the problem..

5320961 should provide answers and links for the following, which is really the main point of the DHS alert

  1. Which Red Hat OS versions support the signed kernel module protection (SKMP) enabled? I believe this to be RHEL7+ only

  2. Does Red Hat have any plans to back port SKMP feature into to Red Hat 5 (extend life ends 11/30/2020) or Red Hat 6 (extend life starts 12/1/2020). I'd bet this answer is no.

  3. Which RH articles can be used by sysadmins to confirm SKMP is properly enabled or not on their systems?

  4. Which Red Hat OS versions support Secure Boot / UEFI? I believe this to be RHEL7+ only

  5. Which RH articles can be used by sysadmins to confirm Secure Boot / UEFI is properly enabled or not?

  6. Which articles provide RH best-practices on implementing this Secure Boot / UEFI feature?

  7. Can you safely convert from BIOS to UEFI/Secure Boot on existing systems? Which articles provide those details?

  8. Does Red Hat have any plans to back port UEFI/Secure Boot feature into to Red Hat 5 (extend life ends 11/30/2020) or Red Hat 6 (extend life starts 12/1/2020). I'd bet this answer is no.

Answering these basic yes/no questions for customers should help most people get over the hump of answering their internal CSIRT teams on this topic.

Edit: formatting.

I think a lot of these questions are quite good, I'll do my best to answer them below. They probably could be broken off into articles

Q > Answering these basic yes/no questions for customers should help most people get over the hump of answering their internal CSIRT teams on this topic.

I would love if they were as simple as yes/no. I'll answer inline.

The NSA and other reports neglect the point that ksmp or secureboot do not protect you from the the originating attack that both 'allowed' local access to the system, then escalated this to a root/privileged user. Neither secureboot OR signed kernel module loading will prevent these vectors. The NSA document does not outline either of these attack vectors in their paper. If they do, I can't seem to find it. So, the recommendation to enable secureboot is good practice, it will not prevent whatever exploit mechanism they are using to elevate privileges.

From gaining the foothold as root, an attacker would be able to both disable secure boot, and load their own kernel modules. Presenting additional 'secureboot' validation metrics such as TPM values to userspace at that point on would require the attacker to write a module to emulate the Trusted Platform Module, but none of this is above what a state sponsored attacker would be considered unacceptable in terms of workload.

Preventing the initial foothold along with privilege escalation minimises the attackers ability to do damage, the kernel module loading allows for a better method of hiding their tracks.

Q> Which Red Hat OS versions support the signed kernel module protection (SKMP) enabled? I believe this to be RHEL7+ only

Initial support for signed module exists in el6 (and it seems some in RHEL5, although not documented and I haven't tested) which can be enabled when enforcemodulesig=1 is set as kernel boot time parameter. For more information see Documentation/module-signing.txt in the relevant kernel doc rpm. Newer versions have different parameters, check the guide for more details, its a bit much for me to type out here.

Q> Does Red Hat have any plans to back port SKMP feature into to Red Hat 5 (extend life ends 11/30/2020) or Red Hat 6 (extend life starts 12/1/2020). I'd bet this answer is no.

Upfront, KSMP is not a protection, at least in my understanding, it is a hardening method used raise the bar to make attackers lives harder. By requiring signed modules under a secureboot environment it requires the attacker defeat secureboot to continue to load the kernel modules. This may sound like semantics but being clear on this is important as there is misinformation available on the internet about this feature.

Any new changes would be very disruptive to backport in this stage in the lifecycle, although you can always request this through support for an official answer from the decision makers. See previous answer for additional information.

Q> Which RH articles can be used by sysadmins to confirm SKMP is properly enabled or not on their systems?

This is documented in the administration Guide for example, check each release for the relevant commands.

Most of the kernel-doc packages for the relevant release will have a kernel-module-signing.txt file outlining the current state of kernel module signing support. I could make this into a KCS article, but its also documented in the releases admin guides.

Q> Which Red Hat OS versions support Secure Boot / UEFI? I believe this to be RHEL7+ only

I see basic EUFI 2.0 in RHEL6. As of 6.9 secureboot wasn't enabled due to the mismatch of secureboot support in available hardware at the time mentioned here.

We have documented support for RHEL-7, RHEL-7-alt (for architectures that support it) and RHEL-8.

Q> Which RH articles can be used by sysadmins to confirm Secure Boot / UEFI is properly enabled or not?

Confirming secureboot is enabled is covered in the Admin guide , but I think that mokutil is the easiest method:

Running the mokutil command as root:

# mokutil --sb-state
Failed to read SecureBoot

Will let you know the current secureboot state.

Q> Which articles provide RH best-practices on implementing this Secure Boot / UEFI feature?

Not all UEFI-based systems include support for Secure Boot, even today. There is a number of articles that talk about secureboot which should work for RHEL7 and RHEL8.

Q> Can you safely convert from BIOS to UEFI/Secure Boot on existing systems? Which articles provide those details?

Changing boot from BIOS to UEFI probably is an involved situation and likely requires additional steps depending on the vendor. I would strongly recommend using the installer (reinstall) it and letting the installer deal with the multi stage steps required to get this working correctly as it seems somewhat involved.

Q> Does Red Hat have any plans to back port UEFI/Secure Boot feature into to Red Hat 5 (extend life ends 11/30/2020) or Red Hat 6 (extend life starts 12/1/2020). I'd bet this answer is no.

Not many of the RHEL5 certified hardware have good UEFI support ( see this article for example) some of the early implementations have been known buggy . Changes this late in the product lifecycle would be deemed too disruptive, but you can always contact support and lodge a feature request for an official answer.

The missing question that I think you may have is 'how do i sign third party modules' as many systems have kernel modules not shipped by Red Hat as part of their boot configuration which is outlined https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/kernel_administration_guide/chap-documentation-kernel_administration_guide-working_with_kernel_modules#sect-signing-kernel-modules-for-secure-boot

I don't regularly check back here for responses, please hit up support for any more specific support questions.

Thanks.

I had originally thought to link many of these style articles to the original, but there is no evidence that secureboot/signed kernel modules prevent the attack from working.

Thanks Wade, very good details that we can collate on our end back in internal CSIRT. My team knows it doesn't stop the malware, only makes life harder to get started but the NSA/FBI reports are taking things at the surface level.

We do have a support case open on this topic but kept getting circled back to the generic Drovorub 5320961 which changes daily, but I'm still lacks details to reference articles for compliance checking. This forum thread is now the most documented that I can find.

These same features apply in a virtualized environment also which helps eliminate some of the hardware compatibility things, provided your hypervisor vendor fully supports UEFI properly.

In our case SElinux is disabled. Is there any related with application if we enable SElinux? We have various different application and most of them are required to disable firewall.