13 ms·

Google discloses CentOS Linux kernel vulnerabilities citing failure to fix

159 points by jaboutboul 4y ago

awill 4y ago
This is such a poorly written article. There is an enormous difference between a vulnerability in CentOS Stream, and RHEL. The article title is about CentOS, but the body says RHEL is affected too.
- misnome 4y ago
  Exactly, I followed the CVE link through, and all affected RHEL8/9. Soo…… Red Hat isn’t patching their live, currently supported distributions? That seems bigger news than their approach to CentOS, which they are clearly trying to kill.
  - carlwgeorge 4y ago
    CVE-2023-0590 is already patched in C9, meaning the fix will likely will be shipped in RHEL 9.2. The other CVEs will probably get fixed as well (in CentOS first!), but when the RHEL maintainers are ready to, not based on some arbitrary deadline from a third party. Lower severity CVE fixes are routinely delayed until future minor versions, so this is nothing new, just an example of a security researcher not understanding how RHEL works.
    - awill 4y ago
      You're obviously a Red Hat employee. It might be worth disclosing it. I don't quite agree though. Sure, RH can decide when to patch, but a researcher isn't wrong just because they say "Hey, RHEL isn't patched". Should RHEL be patching sooner? Maybe. Though I get patches can have unintended consequences. However, I like the idea of a third part scrutinizing this stuff. Otherwise companies will do the wrong thing and claim their security posture is perfect.
jaboutboul 4y ago
From the project zero posting [1] it would seem like most of these would be relatively low scoring CVEs and hence maybe less of a reason to prioritize a fix. [1] https://bugs.chromium.org/p/project-zero/issues/detail?id=2439&can=2&q=&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary&cells=ids https://bugs.chromium.org/p/project-zero/issues/detail?id=24...
hannob 4y ago
It's a not so well guarded secret that the claims by many linux distributions that they support old systems with security fixes for many years are not really true. The number of security flaws constantly found and fixed is just too large to make this even remotely feasibile. This is just another instance of this.
- xxpor 4y ago
  OTOH, a lot of customers probably aren't too worried about low severity, local attack vector bugs.
- 77AA777 4y ago
  Can confirm this is a very real problem with a long history. Quoting from a sort of Arch-specific security hardening page[1]: > A common misconception about the Linux kernel is that it's secure, or that users can go a long time without worrying about security updates. Neither of these are even remotely true. New versions of Linux are released almost every week, often containing important security fixes among the other changes. These releases typically don't make explicit mention of which commits have security implications. As a result, many "stable" or "LTS" distributions don't know which commits should be backported to their old kernels, or even that something needs backporting at all. If the problem has a CVE assigned to it, maybe your distribution will pick it up. Maybe not. Even if a CVE exists, at least in the case of Ubuntu and Debian especially, users are often left with kernels full of known holes for months at a time. Red Hat and similar "enterprise" distros have the same problem and have been called out publicly about it on more than one occasion. Moreover, the Linux kernel security team doesn't request CVEs for any vulnerabilities, partly because there are just too many to track. Downstream's culture of trying to cherrypick security fixes in the name of stability does not work. Arch doesn't play the backporting game, instead opting to provide the newest stable kernels shortly after their upstream release. [1]: https://vez.mrsk.me/linux-hardening.html https://vez.mrsk.me/linux-hardening.html (lots of linked sources in the actual paragraph there)
  - deafpolygon 4y ago
    This is one reason why I don't mainline a Linux desktop anymore. It's just too much sysadmin work to stay on top of it, in addition to all of the desktop issues. When even the creator of the Linux kernel has a very lax approach to security, and so the culture of Linux is the same way - I consider it an issue.
kps 4y ago
There are many parts of Google that I won't rise to defend, but to preempt the inevitable: Project Zero does disclose Google issues on the same basis as anyone else's. https://bugs.chromium.org/p/project-zero/issues/list?q=label%3ADeadline-Exceeded%20vendor%3AGoogle&can=1 https://bugs.chromium.org/p/project-zero/issues/list?q=label...
- tptacek 4y ago
  It wouldn't matter if they didn't. Research and disclosure of vulnerabilities is an absolute good; they don't need to earn the right to publish bugs (it's closer to the other way around).
  - halJordan 4y ago
    This mentality is becoming passé. And frankly this article/post is a good example of the reason. It was long thought that you could name & shame people into good security, but it turns out they just purchase cyber insurance and retreat deeper into the shadows, which increases exposure to the end user. But the new reality is that malicious uptake on publicized POCs is so great, and the negligent refusal to patch is so great that a widespread culture of reporting has actually increased harm to the public. That is the reality, and until there are laws that hold companies liable for the software they choose it will remain the case.
    - tptacek 4y ago
      I came up in an era of CERT's anti-disclosure regime, with no auto-update anywhere, and there is simply no comparison. No, to all of what you said; I don't think I could disagree with anything more strongly.
- wolverine876 4y ago
  You don't know what issues they withheld.
tapoxi 4y ago
Did anyone make the jump from 8 to Stream? How has your experience been? What's different?
- Root_Denied 4y ago
  Converted my homelab media server from CentOS 8 to Stream 8 early last year, haven't noticed an appreciable difference in stability or use-case. Stream 8 is EOL next year though, so I'm considering options of what to move it to. At work an intentional decision was made to avoid migrating any prod/dev systems (previously on CentOS 7/8) to CentOS Stream.
resuresu 4y ago
Local attack vector = nothing burger
- aww_dang 4y ago
  Mainly because there are endless other local attack vectors.
CameronNemo 4y ago
What I don't see mentioned is that IBM would not have to back port anything from the 5.15 tree if they just used an LTS kernel in the first place. But instead they like to differentiate(?) their product by using non-LTS kernels and handling all the back porting themselves, rather than collaborating with distros like Debian and Ubuntu which use the LTS kernels.
- warner25 4y ago
  I've wondered about this too. Like, what's the advantage of it? It looks like they've gone back and forth on this. RHEL 7 and 6 used LTS kernels. Before that, RHEL 5 did its own thing instead of using the LTS. Of course, RHEL also supports these kernels for much longer than the original maintainers. RHEL 6 (released in 2010) still has another year of Extended Life-cycle Support into 2024, even though end-of-life for the 2.6.32 LTS kernel was in 2016. Looking at everything now, I see that Ubuntu 18.04 and 14.04 also chose non-LTS kernels. Interesting.
- kasabali 4y ago
  Reasoning I've heard for this is since they backport complete subsystems and features from mainline kernel over the years, it turns into a frankenstein and it wouldn't resemble the origin version. So it doesn't matter if they'd used LTS version or a non-LTS one.
- ladyanita22 4y ago
  Ubuntu LTS doesn't always use an LTS kernel. 22.04.02 is in 5.19 I believe.
Shakahs 4y ago
The CVEs are for CentOS Stream 9, not the RHEL derived CentOS 7 or Rocky/Alma 8/9. If the RHEL derived distributions were patched but not Stream it would seem that IBM-RedHat's promises about CentOS Stream being just as good are now provably false.
- fweimer 4y ago
  I'm not sure if such a promise ever existed. After all, before CentOS Stream, all security fixes went out with RHEL first and were imported into CentOS (non-Stream) only afterwards. And under the Stream development process, the fixes have to be merged into Stream eventually for the next minor RHEL release, otherwise they would be missing from that, too. The CVE tracking pages are here: https://access.redhat.com/security/cve/CVE-2023-0590 https://access.redhat.com/security/cve/CVE-2023-0590 https://access.redhat.com/security/cve/CVE-2023-1249 https://access.redhat.com/security/cve/CVE-2023-1249 https://access.redhat.com/security/cve/CVE-2023-1252 https://access.redhat.com/security/cve/CVE-2023-1252 Based on these data, it seems that the commercially supported versions are still unfixed (if they were impacted in the first place). Bugzilla records show that the corresponding security tracking bugs were filed publicly from the start: https://bugzilla.redhat.com/show_bug.cgi?id=2165741 https://bugzilla.redhat.com/show_bug.cgi?id=2165741 (CVE-2023-0590) https://bugzilla.redhat.com/show_bug.cgi?id=2169719 https://bugzilla.redhat.com/show_bug.cgi?id=2169719 (CVE-2023-1249) https://bugzilla.redhat.com/show_bug.cgi?id=2176140 https://bugzilla.redhat.com/show_bug.cgi?id=2176140 (CVE-2023-1252) So the Neowin headline is a bit misleading because Red Hat disclosed these issues publicly (presumably after consultation with the reporters) even before the 90-day timer expired in the Google bug tracker. (Disclaimer: I work for Red Hat, but are not involved in security anymore.)
  - mogwire 4y ago
    Additionally these are moderate CVEs and Red Hat, per their lifecycle page, patches them at their will. During the Full Support Phase, Red Hat defined Critical and Important Security errata advisories (RHSAs) and Urgent and Selected (at Red Hat discretion) High Priority Bug Fix errata advisories (RHBAs) may be released as they become available. Other errata advisories may be delivered as appropriate.
o8o8o8o 4y ago
Personally at my work I've been trying to navigate migrating our CentOS 7 production servers to EL8 (Looking at Rocky Linux) and it's been a bloody nightmare thanks to RedHat prematurely killing CentOS8. It seems like there isn't any kind of tools available on the internet to migrate off CentOS to another RHEL clone, so we may end up having to rebuild of our affected production servers before doomsday in 2024. Rocky has a bash script, but it only supports systems running EL8 or higher.
- deafpolygon 4y ago
  With RHEL, it has always been recommended to migrate your entire system to a new install of EL. They are rather notorious, historically anyways, for not providing their customers with an easy upgrade path.
  - klipklop 4y ago
    This is one of the reasons we migrated away. It's pretty easy to go from 20.04 --> 22.04 without having to reinstall your OS. I have taken long lived machines from 18.04 --> 20.04 --> 22.04. The idea that EL charges money with no in-place upgrade path is madness.
    - deafpolygon 4y ago
      I basically learned to decouple the services from the OS it's running on (back before containers and all were a thing) so I focused on making it easy to spin up a new machine and restore a service. Over time, this made OS upgrades immaterial and made it easy to spin up an additional instance. This led to containerization and virtual machines being a good fit for my habits.
- klipklop 4y ago
  Yup. I was working on a migration to CentOS ~8.2 before we got rugpulled. Took the opportunity to move to Ubuntu/Debian. If we have to do all this work, might as well change distro's.
- jaboutboul 4y ago
okl 4y ago
Is CentOS still alive? I thought it had been succeeded by Rocky Linux and Alma Linux.
- yjftsjthsd-h 4y ago
  CentOS 7 is technically still around, and Stream lives on as RHEL's beta channel.
notyourday 4y ago
As of today Google still has not fixed the vulnerability on Pixel 6 a device that Google promised it would provide security fixes for 5 years disclosed by the Project Zero which is a Google suborg.
- rany_ 4y ago
  It has fixed the issue. I got the March update with the fix a few days ago.
  - notyourday 4y ago
    > It has fixed the issue. I got the March update with the fix a few days ago. The last Android fix for Android 13 for Pixel 6 is March 5, 2023. That's before the fix.
    - kkkkkkk 4y ago
      It was patched before the public disclosure, go read the security bulletin [1]. CVE-2023-24033, CVE-2023-26496, CVE-2023-26497, and CVE-2023-26498 are the big modem vulnerabilities. [1] https://source.android.com/docs/security/bulletin/pixel/2023-03-01 https://source.android.com/docs/security/bulletin/pixel/2023...
    - izacus 4y ago
      No, you're wrong: the OTA marked as 5th March security update has the fixes. It's trivially easy to look up the list of fixes for Pixels, c'mon.
- smm11 4y ago
  Maybe this will get Fuchsia going.
_8j50 4y ago
This guy also helped find spectre/meltdown. I hope he writes a book or something to teach everyone his secret sauce
profwalkstr 4y ago
More details here: https://packetstormsecurity.com/files/171409/GS20230321173206.txt https://packetstormsecurity.com/files/171409/GS2023032117320...
mogwire 4y ago
Red Hat doesn’t fix moderate CVEs immediately. Per there RHEL Lifecycle web page: “During the Full Support Phase, Red Hat defined Critical and Important Security errata advisories (RHSAs) and Urgent and Selected (at Red Hat discretion) High Priority Bug Fix errata advisories (RHBAs) may be released as they become available. Other errata advisories may be delivered as appropriate.” Seeing how all of these CVEs are considered Moderate they fall under the “delivered as appropriate”. As usual people over react and try to make companies look like they don’t care about security, back ports, etc when all Red Hat is doing is following its own policy.
- carlwgeorge 4y ago
  Absolutely agree, but one small point of clarification. One of the referenced CVEs (CVE-2023-1249) is rated low. The other two (CVE-2023-0590 and CVE-2023-1252) are rated moderate.
qalmakka 4y ago
LTS is a dangerous concept, really, especially in the way Debian or Red Hat do it, that is, by freezing versions at a completely random point and then attempt to backport fixes. This approach is outright dangerous, because in my experience a distro maintainer is often not as accustomed with the codebase as an upstream maintainer. I understand the need to keep versions stable, but I would rather use a real long term support version from an upstream maintainer than random patches from Red Hat. That's why in my experience ironically rolling releases tend to be less finicky to use than long term support distros.

159 points by jaboutboul 4y ago

This is such a poorly written article. There is an enormous difference between a vulnerability in CentOS Stream, and RHEL. The article title is about CentOS, but the body says RHEL is affected too.

misnome 4y ago
Exactly, I followed the CVE link through, and all affected RHEL8/9. Soo…… Red Hat isn’t patching their live, currently supported distributions? That seems bigger news than their approach to CentOS, which they are clearly trying to kill.
- carlwgeorge 4y ago
  CVE-2023-0590 is already patched in C9, meaning the fix will likely will be shipped in RHEL 9.2. The other CVEs will probably get fixed as well (in CentOS first!), but when the RHEL maintainers are ready to, not based on some arbitrary deadline from a third party. Lower severity CVE fixes are routinely delayed until future minor versions, so this is nothing new, just an example of a security researcher not understanding how RHEL works.
  - awill 4y ago
    You're obviously a Red Hat employee. It might be worth disclosing it. I don't quite agree though. Sure, RH can decide when to patch, but a researcher isn't wrong just because they say "Hey, RHEL isn't patched". Should RHEL be patching sooner? Maybe. Though I get patches can have unintended consequences. However, I like the idea of a third part scrutinizing this stuff. Otherwise companies will do the wrong thing and claim their security posture is perfect.

jaboutboul 4y ago

From the project zero posting [1] it would seem like most of these would be relatively low scoring CVEs and hence maybe less of a reason to prioritize a fix. [1] https://bugs.chromium.org/p/project-zero/issues/detail?id=2439&can=2&q=&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary&cells=ids https://bugs.chromium.org/p/project-zero/issues/detail?id=24...

hannob 4y ago

It's a not so well guarded secret that the claims by many linux distributions that they support old systems with security fixes for many years are not really true. The number of security flaws constantly found and fixed is just too large to make this even remotely feasibile. This is just another instance of this.

xxpor 4y ago
OTOH, a lot of customers probably aren't too worried about low severity, local attack vector bugs.
77AA777 4y ago
Can confirm this is a very real problem with a long history. Quoting from a sort of Arch-specific security hardening page[1]: > A common misconception about the Linux kernel is that it's secure, or that users can go a long time without worrying about security updates. Neither of these are even remotely true. New versions of Linux are released almost every week, often containing important security fixes among the other changes. These releases typically don't make explicit mention of which commits have security implications. As a result, many "stable" or "LTS" distributions don't know which commits should be backported to their old kernels, or even that something needs backporting at all. If the problem has a CVE assigned to it, maybe your distribution will pick it up. Maybe not. Even if a CVE exists, at least in the case of Ubuntu and Debian especially, users are often left with kernels full of known holes for months at a time. Red Hat and similar "enterprise" distros have the same problem and have been called out publicly about it on more than one occasion. Moreover, the Linux kernel security team doesn't request CVEs for any vulnerabilities, partly because there are just too many to track. Downstream's culture of trying to cherrypick security fixes in the name of stability does not work. Arch doesn't play the backporting game, instead opting to provide the newest stable kernels shortly after their upstream release. [1]: https://vez.mrsk.me/linux-hardening.html https://vez.mrsk.me/linux-hardening.html (lots of linked sources in the actual paragraph there)
- deafpolygon 4y ago
  This is one reason why I don't mainline a Linux desktop anymore. It's just too much sysadmin work to stay on top of it, in addition to all of the desktop issues. When even the creator of the Linux kernel has a very lax approach to security, and so the culture of Linux is the same way - I consider it an issue.

kps 4y ago

There are many parts of Google that I won't rise to defend, but to preempt the inevitable: Project Zero does disclose Google issues on the same basis as anyone else's. https://bugs.chromium.org/p/project-zero/issues/list?q=label%3ADeadline-Exceeded%20vendor%3AGoogle&can=1 https://bugs.chromium.org/p/project-zero/issues/list?q=label...

tptacek 4y ago
It wouldn't matter if they didn't. Research and disclosure of vulnerabilities is an absolute good; they don't need to earn the right to publish bugs (it's closer to the other way around).
- halJordan 4y ago
  This mentality is becoming passé. And frankly this article/post is a good example of the reason. It was long thought that you could name & shame people into good security, but it turns out they just purchase cyber insurance and retreat deeper into the shadows, which increases exposure to the end user. But the new reality is that malicious uptake on publicized POCs is so great, and the negligent refusal to patch is so great that a widespread culture of reporting has actually increased harm to the public. That is the reality, and until there are laws that hold companies liable for the software they choose it will remain the case.
  - tptacek 4y ago
    I came up in an era of CERT's anti-disclosure regime, with no auto-update anywhere, and there is simply no comparison. No, to all of what you said; I don't think I could disagree with anything more strongly.
wolverine876 4y ago
You don't know what issues they withheld.

tapoxi 4y ago

Did anyone make the jump from 8 to Stream? How has your experience been? What's different?

Root_Denied 4y ago
Converted my homelab media server from CentOS 8 to Stream 8 early last year, haven't noticed an appreciable difference in stability or use-case. Stream 8 is EOL next year though, so I'm considering options of what to move it to. At work an intentional decision was made to avoid migrating any prod/dev systems (previously on CentOS 7/8) to CentOS Stream.

resuresu 4y ago

Local attack vector = nothing burger

aww_dang 4y ago
Mainly because there are endless other local attack vectors.

CameronNemo 4y ago

What I don't see mentioned is that IBM would not have to back port anything from the 5.15 tree if they just used an LTS kernel in the first place. But instead they like to differentiate(?) their product by using non-LTS kernels and handling all the back porting themselves, rather than collaborating with distros like Debian and Ubuntu which use the LTS kernels.

warner25 4y ago
I've wondered about this too. Like, what's the advantage of it? It looks like they've gone back and forth on this. RHEL 7 and 6 used LTS kernels. Before that, RHEL 5 did its own thing instead of using the LTS. Of course, RHEL also supports these kernels for much longer than the original maintainers. RHEL 6 (released in 2010) still has another year of Extended Life-cycle Support into 2024, even though end-of-life for the 2.6.32 LTS kernel was in 2016. Looking at everything now, I see that Ubuntu 18.04 and 14.04 also chose non-LTS kernels. Interesting.
kasabali 4y ago
Reasoning I've heard for this is since they backport complete subsystems and features from mainline kernel over the years, it turns into a frankenstein and it wouldn't resemble the origin version. So it doesn't matter if they'd used LTS version or a non-LTS one.
ladyanita22 4y ago
Ubuntu LTS doesn't always use an LTS kernel. 22.04.02 is in 5.19 I believe.

Shakahs 4y ago

The CVEs are for CentOS Stream 9, not the RHEL derived CentOS 7 or Rocky/Alma 8/9. If the RHEL derived distributions were patched but not Stream it would seem that IBM-RedHat's promises about CentOS Stream being just as good are now provably false.

fweimer 4y ago
I'm not sure if such a promise ever existed. After all, before CentOS Stream, all security fixes went out with RHEL first and were imported into CentOS (non-Stream) only afterwards. And under the Stream development process, the fixes have to be merged into Stream eventually for the next minor RHEL release, otherwise they would be missing from that, too. The CVE tracking pages are here: https://access.redhat.com/security/cve/CVE-2023-0590 https://access.redhat.com/security/cve/CVE-2023-0590 https://access.redhat.com/security/cve/CVE-2023-1249 https://access.redhat.com/security/cve/CVE-2023-1249 https://access.redhat.com/security/cve/CVE-2023-1252 https://access.redhat.com/security/cve/CVE-2023-1252 Based on these data, it seems that the commercially supported versions are still unfixed (if they were impacted in the first place). Bugzilla records show that the corresponding security tracking bugs were filed publicly from the start: https://bugzilla.redhat.com/show_bug.cgi?id=2165741 https://bugzilla.redhat.com/show_bug.cgi?id=2165741 (CVE-2023-0590) https://bugzilla.redhat.com/show_bug.cgi?id=2169719 https://bugzilla.redhat.com/show_bug.cgi?id=2169719 (CVE-2023-1249) https://bugzilla.redhat.com/show_bug.cgi?id=2176140 https://bugzilla.redhat.com/show_bug.cgi?id=2176140 (CVE-2023-1252) So the Neowin headline is a bit misleading because Red Hat disclosed these issues publicly (presumably after consultation with the reporters) even before the 90-day timer expired in the Google bug tracker. (Disclaimer: I work for Red Hat, but are not involved in security anymore.)
- mogwire 4y ago
  Additionally these are moderate CVEs and Red Hat, per their lifecycle page, patches them at their will. During the Full Support Phase, Red Hat defined Critical and Important Security errata advisories (RHSAs) and Urgent and Selected (at Red Hat discretion) High Priority Bug Fix errata advisories (RHBAs) may be released as they become available. Other errata advisories may be delivered as appropriate.

o8o8o8o 4y ago

Personally at my work I've been trying to navigate migrating our CentOS 7 production servers to EL8 (Looking at Rocky Linux) and it's been a bloody nightmare thanks to RedHat prematurely killing CentOS8. It seems like there isn't any kind of tools available on the internet to migrate off CentOS to another RHEL clone, so we may end up having to rebuild of our affected production servers before doomsday in 2024. Rocky has a bash script, but it only supports systems running EL8 or higher.

deafpolygon 4y ago
With RHEL, it has always been recommended to migrate your entire system to a new install of EL. They are rather notorious, historically anyways, for not providing their customers with an easy upgrade path.
- klipklop 4y ago
  This is one of the reasons we migrated away. It's pretty easy to go from 20.04 --> 22.04 without having to reinstall your OS. I have taken long lived machines from 18.04 --> 20.04 --> 22.04. The idea that EL charges money with no in-place upgrade path is madness.
  - deafpolygon 4y ago
    I basically learned to decouple the services from the OS it's running on (back before containers and all were a thing) so I focused on making it easy to spin up a new machine and restore a service. Over time, this made OS upgrades immaterial and made it easy to spin up an additional instance. This led to containerization and virtual machines being a good fit for my habits.
klipklop 4y ago
Yup. I was working on a migration to CentOS ~8.2 before we got rugpulled. Took the opportunity to move to Ubuntu/Debian. If we have to do all this work, might as well change distro's.
jaboutboul 4y ago

okl 4y ago

Is CentOS still alive? I thought it had been succeeded by Rocky Linux and Alma Linux.

yjftsjthsd-h 4y ago
CentOS 7 is technically still around, and Stream lives on as RHEL's beta channel.

notyourday 4y ago

As of today Google still has not fixed the vulnerability on Pixel 6 a device that Google promised it would provide security fixes for 5 years disclosed by the Project Zero which is a Google suborg.

rany_ 4y ago
It has fixed the issue. I got the March update with the fix a few days ago.
- notyourday 4y ago
  > It has fixed the issue. I got the March update with the fix a few days ago. The last Android fix for Android 13 for Pixel 6 is March 5, 2023. That's before the fix.
  - kkkkkkk 4y ago
    It was patched before the public disclosure, go read the security bulletin [1]. CVE-2023-24033, CVE-2023-26496, CVE-2023-26497, and CVE-2023-26498 are the big modem vulnerabilities. [1] https://source.android.com/docs/security/bulletin/pixel/2023-03-01 https://source.android.com/docs/security/bulletin/pixel/2023...
  - izacus 4y ago
    No, you're wrong: the OTA marked as 5th March security update has the fixes. It's trivially easy to look up the list of fixes for Pixels, c'mon.
smm11 4y ago
Maybe this will get Fuchsia going.

_8j50 4y ago

This guy also helped find spectre/meltdown. I hope he writes a book or something to teach everyone his secret sauce

profwalkstr 4y ago

More details here: https://packetstormsecurity.com/files/171409/GS20230321173206.txt https://packetstormsecurity.com/files/171409/GS2023032117320...

mogwire 4y ago

Red Hat doesn’t fix moderate CVEs immediately. Per there RHEL Lifecycle web page: “During the Full Support Phase, Red Hat defined Critical and Important Security errata advisories (RHSAs) and Urgent and Selected (at Red Hat discretion) High Priority Bug Fix errata advisories (RHBAs) may be released as they become available. Other errata advisories may be delivered as appropriate.” Seeing how all of these CVEs are considered Moderate they fall under the “delivered as appropriate”. As usual people over react and try to make companies look like they don’t care about security, back ports, etc when all Red Hat is doing is following its own policy.

carlwgeorge 4y ago
Absolutely agree, but one small point of clarification. One of the referenced CVEs (CVE-2023-1249) is rated low. The other two (CVE-2023-0590 and CVE-2023-1252) are rated moderate.

qalmakka 4y ago

LTS is a dangerous concept, really, especially in the way Debian or Red Hat do it, that is, by freezing versions at a completely random point and then attempt to backport fixes. This approach is outright dangerous, because in my experience a distro maintainer is often not as accustomed with the codebase as an upstream maintainer. I understand the need to keep versions stable, but I would rather use a real long term support version from an upstream maintainer than random patches from Red Hat. That's why in my experience ironically rolling releases tend to be less finicky to use than long term support distros.