Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Security Linux

Nasty Linux Netfilter Firewall Security Hole Found (zdnet.com) 53

Posted by BeauHD from the lost-and-found dept.
Sophos threat researcher Nick Gregory discovered a hole in Linux's netfilter firewall program that's "exploitable to achieve kernel code execution (via ROP [return-oriented programming]), giving full local privilege escalation, container escape, whatever you want." ZDNet reports: Behind almost all Linux firewalls tools such as iptables; its newer version, nftables; firewalld; and ufw, is netfilter, which controls access to and from Linux's network stack. It's an essential Linux security program, so when a security hole is found in it, it's a big deal. [...] This problem exists because netfilter doesn't handle its hardware offload feature correctly. A local, unprivileged attacker can use this to cause a denial-of-service (DoS), execute arbitrary code, and cause general mayhem. Adding insult to injury, this works even if the hardware being attacked doesn't have offload functionality! That's because, as Gregory wrote to a security list, "Despite being in code dealing with hardware offload, this is reachable when targeting network devices that don't have offload functionality (e.g. lo) as the bug is triggered before the rule creation fails."

This vulnerability is present in the Linux kernel versions 5.4 through 5.6.10. It's listed as Common Vulnerabilities and Exposures (CVE-2022-25636), and with a Common Vulnerability Scoring System (CVSS) score of 7.8), this is a real badie. How bad? In its advisory, Red Hat said, "This flaw allows a local attacker with a user account on the system to gain access to out-of-bounds memory, leading to a system crash or a privilege escalation threat." So, yes, this is bad. Worse still, it affects recent major distribution releases such as Red Hat Enterprise Linux (RHEL) 8.x; Debian Bullseye; Ubuntu Linux, and SUSE Linux Enterprise 15.3. While the Linux kernel netfilter patch has been made, the patch isn't available yet in all distribution releases.
This discussion has been archived. No new comments can be posted.

Nasty Linux Netfilter Firewall Security Hole Found More

Nasty Linux Netfilter Firewall Security Hole Found

Comments Filter:
  • I'm curious about the claim Debian 11 "Bullseye" is affected. The kernels listed as affected are 5.4 through 5.6.10. Debian 11 shipped with 5.10, so why would it be affected? Is the summary of kernel versions incorrect or the list of distros affected?

    • Re: (Score:2)

      by jmccue ( 834797 )

      This vulnerability is present in the Linux kernel versions 5.4 through 5.6.10.

      It isn't, you should be fine (assuming the above quote is correct :)

      But how hard would it be for zdnet to say "This bug was fixed on kernel 5.6.11 and above" ? It is serious but the article was written by zdnet for sensationalism, as par for the course for them.

      • I hate ZDNet. "it affects recent major distribution releases such as Red Hat Enterprise Linux (RHEL) 8.x; Debian Bullseye; Ubuntu Linux, and SUSE Linux Enterprise 15.3."

        RHEL 8: 4.18
        SLES 15: 5.3.18

        the flaw is serious - ZDnet is cr*p.

      • This isn't the only overinflated linux issue in the last few weeks "the most severe in years" blah blah. Both are local escalation which is actually a pretty common class of vulnerability and both are rapidly patched. I think most people forget that the vast majority of linux deployments don't even have local interactive users without privileges because most are server or embedded. An attacker needs to first get a foot in the door before they can attempt to employ these vulnerabilities.

    • Re:Debian Bullseye (Score:4, Informative)

      by Haegar ( 1160 ) on Tuesday March 15, 2022 @09:22PM (#62361535) Homepage

      The quote is wrong - it should have said 5.16.11, Debian Bullseye (if unupdated) is affected.

      https://seclists.org/oss-sec/2... [seclists.org] references git commit https://git.kernel.org/pub/scm... [kernel.org] as the fix, originally part of 5.17-rc4, and backported in 5.16.12 (and 5.10.103, and more stable trees).

      The (as of now) latest Debian Bullseye kernel security update 5.10.103-1 contains the fix, so if you got that and rebooted after the install you are safe.

      • Re: (Score:2)

        by jmccue ( 834797 )
        Thanks, that makes sense to me, cannot give you mods, but hopefully others will.

        • Re: (Score:2)

          by Striek ( 1811980 )

          Good luck with that, moderation here has been broken for a couple of weeks now...

          • Works fine for me. I have no mod points.

            • Re: (Score:2)

              by caseih ( 160668 )

              If you've had mod points in the last couple of weeks, that's rare. Almost no one has mod points these last few weeks. If you set your comment level to 2, there're very few comments visible as there's nearly no moderation happening. I've also seen spam posts lately sitting at 1, and there's no one to mod them down. I've seen no +5 comments in a long time either. No troll or flamebait moderations that I've seen either. Weirdly, there is at least one user I saw recently whose posts are all -1. But I'm pret

  • All major OSes are vulnerable to privilege escalation exploits. It's just a matter of looking for them. Don't make your security model depend on them not existing.

  • All of these exploits usually require local unprivileged accounts. So it's a good reminder to keep local accounts to a minimum and use external authentication methods with 2FA where possible.

    • yea. it's not like anyone has ever injected PHP or Python into an HTTP request and had limited access to a 'nobody' account in a chroot or container. ... which you can now escape through yet another major escalation bug.

  • Both Linux and Greg K-H have always been dismissive of security vulnerabilities, and insist on treating them as though they were just typical bugs. This is a naive, amateurish, dangerous and unprofessional attitude, not much better than early 2000s Microsoft's approach.

    Linux is *full* of security bugs, and the 'many eyes' theorem means little when people are not really looking. This is part of why I switched to NetBSD (FreeBSD is too 'busy', OpenBSD has too much posturing).

    Linux development ought to include

    • Linux development ought to include consistent scheduled secure code reviews and audits, because security vulnerabilities are not on the same level as other bugs as kernel maintainers insist.

      There's nothing stopping you from doing that. Post your findings!

      • Why would I waste the effort when the development community has no interest in responding?

        • Do you have an example of the development community not responding to security flaws?

          • I never claimed that was the case. The problem is that they don't prioritize vulnerabilities over other bugs.

            • Sure you did:

              Why would I waste the effort when the development community has no interest in responding?

              This implies you would not consider the effort a waste, if the community had an interest in responding.
              Since we can't very well judge interest other than by judging their behavior, I'm asking you if you have any evidence of the development community not responding.

              Your pet OS has had some pretty mid-blowing security vulnerabilities as well.
              Does Linux have more? Absolutely. But Linux is also used in somewhere around a few trillion percent more devices. This means the eyes looking for problem

              • Sure you did:

                No, I didn't. Twisting my words makes you seem desperate.

                This implies you would not consider the effort a waste, if the community had an interest in responding.

                In the context of my previous statements, it was clear I meant respond *in a timely fashion*.

                Your pet OS has had some pretty mid-blowing security vulnerabilities as well.

                Sure, every OS does or has had. But the NetBSD team are very quick to fix. I don't have a link handy but I recall reading a paper written, presentation given at BSDCon or something, that the NetBSD team were by far the fastest to patch vulns they were made aware of, patching many in the same night.

                This means the eyes looking for problems is much higher.

                Not really, it just means people are working on it. People cont

                • No, I didn't. Twisting my words makes you seem desperate.

                  Denying what you wrote makes you seem stupid.

                  In the context of my previous statements, it was clear I meant respond *in a timely fashion*.

                  Citation needed. Nowhere in any of our interaction have you alluded anything to the timeliness of any response.

                  Sure, every OS does or has had. But the NetBSD team are very quick to fix. I don't have a link handy but I recall reading a paper written, presentation given at BSDCon or something, that the NetBSD team were by far the fastest to patch vulns they were made aware of, patching many in the same night.

                  Of course. That's easy for them. They have the simplest and least featureful OS, with the least amount of users.
                  Plenty of linux bugs are patched same-day too. What's your point? Average is a silly metric when we're taking into account the fact that very few NetBSD vulnerabilities are ever even found due to the lack of people looking for them.

                  The only

                  • Denying what you wrote makes you seem stupid.

                    Sure, but I'm not doing that. Accusing someone of doing that because you can't follow the conversation certainly makes you seem stupid, which is in line with the rest of your zealous argument.

                    Citation needed. Nowhere in any of our interaction have you alluded anything to the timeliness of any response.

                    You have the citation, you just want to ignore it. You're clearly one of those fools that just wants to argue for the sake of arguing because you think it makes you seem smart.

                    Of course. That's easy for them. They have the simplest and least featureful OS, with the least amount of users.

                    Patently untrue. There are other OSes used far less. NetBSD is used pretty extensively, just not in domains you would be familiar with. Nor is N

            • Yes they do, it's not the handling or priority of the security vulnerabilities that they equate with normal bugs, it's how they report them in the changelog. AKA they don't make a huge fanfare every time they fix a vulnerability. They are prioritized above all other bugs.

    • I'm sure if ipchains was still around it would be affected too. My point is, I think the issue has been with stack usage and how some processes should not have such authority. Yet we live in a application driven world where they get what they want.

    • Both Linux and Greg K-H have always been dismissive of security vulnerabilities, and insist on treating them as though they were just typical bugs. This is a naive, amateurish, dangerous and unprofessional attitude, not much better than early 2000s Microsoft's approach.

      The curious thing about Linux anyone can scratch their itch and contribute what they fancy to the project. Those who care about security are not powerless.

      Linux is *full* of security bugs, and the 'many eyes' theorem means little when people are not really looking. This is part of why I switched to NetBSD (FreeBSD is too 'busy', OpenBSD has too much posturing).

      So is everything else...
      https://www.netbsd.org/support... [netbsd.org]

      This is why people are using hypervisors for security because securing a general purpose operating system is a fools errand.

      Linux development ought to include consistent scheduled secure code reviews and audits, because security vulnerabilities are not on the same level as other bugs as kernel maintainers insist.

      If you want a secure operating system you will have to design one to be that from scratch. Nobody in their right mind would even attempt such a feat with a monolithic kernel.

      • The curious thing about Linux anyone can scratch their itch and contribute what they fancy to the project. Those who care about security are not powerless.

        You realize that's a bullshit opinion right? Like sure it's an advantage of open source software, but it's not an excuse to let maintainers off the hook for shitty practices.

        So is everything else...

        Not the point, the point is how security is handled and prioritized. In the BSD's it's a priority, in Linux not so much.

        This is why people are using hypervisors for security because securing a general purpose operating system is a fools errand.

        You might think that being loyal to Linux which as such a slack attitude toward security, but it isn't the case.

  • It says RHEL 8 is affected, but RHEL 8 comes with kernel 4.18, and according to https://seclists.org/oss-sec/2... [seclists.org] the bug was introduced in 5.4-rc1, so I believe RHEL based systems (at least on stable version 8-based distros, like RHEL, Rocky or Alma) are not affected.

  • how bad? (Score:2)

    by Tom ( 822 )

    and with a Common Vulnerability Scoring System (CVSS) score of 7.8), this is a real badie.

    Don't be fooled by that. I've been trying for years to find any study, whitepaper or other research that shows a correlation between CVSS score and real-world impact, and I've come up empty. None of the other people I've asked know any such thing, either. We're actually thinking about finding a bachelor or master student who'd like to do more extensive research into this as a thesis.

    IMHO, CVSS scores have little value, and they especially don' tell you how bad something is.

  • It's bad because it's MIKKKROSOFT!

    Linux? Oh, this vulnerability affects Linux?. Well, then it doesn't count as a bad thing.

  • I checked the CVE link in TFA and found this message at the top of the page:

    CVE-2022-25636 Detail

    Undergoing Reanalysis

    This vulnerability has been modified and is currently undergoing reanalysis. Please check back soon to view the updated vulnerability summary.

    And this I found this near the bottom of the page: (some editing required to keep /. filters happy)

    Known Affected Software Configurations

    Configuration 1

    cpe:2.3:o:linux:linux_kernel:

    From (including) 5.4 Up to (including) 5.6.10

Slashdot Top Deals

"Engineering without management is art." -- Jeff Johnson

Close