6

I have this problem, I'm trying to see if a group of servers are vulnerable to the CVE CVE-2024-1086 so what I do in the server is rpm -qa --changelog kernel | grep 2024-1086, and I get this as output:

- netfilter: nf_tables: reject QUEUE/DROP verdict parameters (Florian Westphal) [RHEL-24009 2262126] {CVE-2024-1086}, which I think means that the cve has been mitigated in that system. However, the client says that their scan that they are using to check if the system is vulnerable is still showing that the server is vulnerable, do you know if with that output I can say that their scan is giving them a false positive or is there any other way to confirm for sure that the system is not vulnerable anymore to that CVE?

Improve this question
5
  • 2
    The fix to CVE-2024-1086 is in the form of a kernel patch, so a reboot is required after installing the updated kernel to let the fix take effect. Has this been done? Your rpm command strongly suggests the patch has been installed; the next step is to run uname -r and verify that the kernel version that is actually running matches or exceeds the version of the kernel package that brought the patch.
    – telcoM
    Commented Jun 28 at 18:18
  • 2
    You might also ask the client what package they are using in the scan. I have worked with multiple scanners that look at only the version number of an installed package. If the kernel major/minor version numbers have not changed, the scanner will report the system as vulnerable. The minor version numbers that are incremented by REL then the package is patched are not taken into account.
    – doneal24
    Commented Jun 28 at 18:21
  • @telcoM reboot has been done, I have been executing uname -r and I see the kernel version is 4.18.0-477.55.1.el8_8.x86_64 but not sure if this kernel version is vulnerable or not, or how to check that.
    – VaTo
    Commented Jun 28 at 18:21
  • @doneal24 what I want to show them is that yes, the patch has been applied and the vulnerability has been fixed, if they are using a scanner that doesn't give accurate results, that would be their problem.
    – VaTo
    Commented Jun 28 at 18:23
  • You would want to look at the client's detection message, and possibly the source for their tool, to see what, exactly, are they testing, and how. I've seen false positives from a tool failing to parse a version number, and deciding that version 5.0.2 was older than the required 4.7.
    – waltinator
    Commented Jun 28 at 18:52

1 Answer 1

Reset to default
11

First, go to RedHat CVE database and search for CVE-2024-1086. It will lead you to this page, which lists the errata that fixed the CVE in each RHEL release.

For basic RHEL 8.x (i.e. the latest patch level), that'll be RHSA-2024-1607, and for RHEL 8.8 Extended Update Support, that'll be RHSA-2024-1404.

Since you are apparently running RHEL 8.8 by your kernel version number, look at the Updated Packages tab on RHSA-2024-1404 page.

It tells you that the kernel package that first contained the patch for your release is kernel-4.18.0-477.51.1.el8_8.x86_64.rpm.

You are running kernel release 4.18.0-477.55.1.el8_8.x86_64. The patch level 477.55.1.el8_8 is greater than 477.51.1.el8_8, so yes, your kernel is patched and you are not vulnerable.

The client's scanner might be unaware of RHEL 8.8 Extended Support, and so would "want" to see kernel version 4.18.0-513.24.1.el8_9.x86_64 or greater, which would be the answer if you had updated to RHEL 8.9 or greater. But if you are using RHEL 8.8 Extended Support, the most common reason for that is that there is an expensive application that either doesn't support RHEL 8.9 yet, or simply the app is not certified for it and the client wants/needs the application in a certified state.

A kernel version should not be considered a single incrementing line, but a tree graph, as there can be several special-purpose kernel sub-series. As you can see in the RedHat CVE database page linked above, RHEL 8.x series includes at least:

  • the RHEL 8.x "main" kernel series
  • -rt (real-time enhanced) kernels
  • 8.2 Advanced Update Support kernels
  • 8.4 Advanced Mission Critical kernels
  • 8.4 Telecommunications kernels
  • 8.4 and 8.6 for SAP kernels
  • 8.6 and 8.8 Extended Update kernels

All of these have their own kernel RPMs, with their own patch level numbers. If you use any of the special-purpose kernel series, your client should verify that their vulnerability scanner also knows about that particular kernel series, or you will get false positives.

If there is doubt whether a vulnerability is patched or not, it is important to check the latest applicable patch level information in the vendor's CVE database.

Checking just the RPM changelog may indicate that a vulnerability has been patched, but it won't tell you if the security researchers later realized "oops, it turned out the initial patch won't provide complete protection, here's a better patch". In situations like that, the vendor's CVE database should point you straight to the later patch.

And so, you can be confident that if your RPM patch level is equal or greater than the level reported as fixed in the CVE database, and that version is actually running, then the vulnerability is well and truly fixed according to the best available information.

Improve this answer
7
  • Thank you for your reply! it does make sense what you said, however, I do see that there are some servers that have other versions of kernels and they have the same output as the other ones with the older kernel, for example I have servers with the kernel versions: 4.18.0-477.55.1.el8_8.x86_64 and 4.18.0-477.43.1.el8_8.x86_64 and 4.18.0-477.27.1.el8_8.x86_64, and they all have the same output: - netfilter: nf_tables: reject QUEUE/DROP verdict parameters (Florian Westphal) [RHEL-24009 2262126] {CVE-2024-1086, then I should ignore the output and just focus on the kernel versions?
    – VaTo
    Commented Jun 30 at 23:23
  • Sorry for not being clear, to clarify, I don't have any output of the scanner, my client just tells me that his scanner is telling him that the output is saying that the servers are vulnerable but I don't know what the output of the scanner says, that's all the information that I have from that, so then the output I was referring to is the output from the rpm command you correctly posted.
    – VaTo
    Commented Jul 1 at 0:18
  • The CVE database clearly says that for RHEL 8.8 Extended Update, you want patch level 477.51.1.el8_8 or greater. The fact that patch levels 477.43.1.el8_8 and 477.27.1.el8_8 also show the same changelog entry suggest exactly the sort of situation I covered in my edit above: the initial security patch that produced the changelog entry may have been less than perfect, and only 477.51.1.el8_8 and above will provide complete protection for this vulnerability.
    – telcoM
    Commented Jul 1 at 0:29
  • Thank you very much for your help @telcoM
    – VaTo
    Commented Jul 3 at 14:58
  • 1
    The user namespaces are used in container technologies, and disabling them either makes the use of e.g. Docker or Podman on that system outright impossible, or at the very least blocks their major features you would usually use them for. If you use the system for classical unix-like applications or J2EE without any containerization, the second mitigation option would be a good fit.
    – telcoM
    Commented Jul 9 at 23:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .