DT, I am not all arguing that CVE-2022-1184 impact score was incorrect. I can't imagine why you think that.
By itself, CVE-2022-1184 is not a privilege escalation, because it can normally only be exploited by someone with write access to the filesystem boots, that is, root. Only with setuid-root apptainer/singularity does it become a privilege escalation. I have said that I think that CVE-2022-1184's "Privileges Required" was incorrect. It was you who suggested USB automounts being available to users may have been their reason for setting it to "low". If that's what they meant, then I think it makes perfect sense that they don't count that as a privilege escalation because physical access already gives privilege escalation in much easier ways. I said that that's probably why they only counted it as denial of service since that was the only thing new. Dave On Thu, May 04, 2023 at 02:14:08PM +0100, David Trudgian wrote: > Dave, > > On Wed, May 3, 2023, at 10:31 PM, Dave Dykstra via epel-devel wrote: > > On Wed, May 03, 2023 at 02:59:42PM -0500, Carl George wrote: > > > On Thu, Apr 27, 2023 at 10:20 AM Dave Dykstra via epel-devel > > > <epel-devel@lists.fedoraproject.org> wrote: > > > > > > > > On Thu, Apr 27, 2023 at 02:11:46AM -0500, Carl George wrote: > > ... > > > > > The Red Hat CVSS score for CVE-2022-1184 has the same breakdown as the > > > > > NVD CVSS score. Both rate the "privileges required" property as low. > > > > > From what I can tell that property would be rated high if they > > > > > considered root privileges to be required. How does apptainer's use > > > > > of setuid change anything here? > > > > > > > > According to the explanation I received from the ext4 kernel developer, > > > > Red Hat's CVSS rating was incorrect on that property. Without > > > > singularity > > > > or apptainer it does require high privileges to exploit. > > > > > > Red Hat's CVSS score breakdown for CVE-2022-1184 is: > > > > > > CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H > > > > > > You're suggesting that Red Hat's rating should have been higher > > > because they didn't factor in low privileges, but that is objectively > > > false because they did score it with low privileges. If they had > > > scored it for high privileges, that would have dropped the rating down > > > from 5.5 to 4.4. > > > > As DT pointed out, perhaps Red Hat was thinking that low privileges could > > have been used by automounts of a USB device, but since that requires > > physical access and there are much easier ways to get privilege escalation > > with physical access, the only additional capability that would give to > > a user is a crash, a denial of service. > > Impact scoring for a CVE doesn't depend on how it is triggered, though. If > CVE-2022-1184 can provably give privilege escalation then it should be scored > high on the impact (confidentiality/integrity/availability) metrics. It is > not relevant to the impact whether I need physical access. The ease of the > exploit is covered by the exploitability metrics, not the impact metrics. > > https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator > > My comment about automounts etc. was only related to why Red Hat might hve > set the 'Privileges Required' property to low, even though `mount` is usually > a root-only operation. Here you are arguing that CVE-2022-1184 was mis-scored > on impact (confidentiality/integrity/availability). This is not related to my > point about privileges required. > > > > There is no reason to believe that CVE-2022-1184 > > > should have been marked as higher impact than it was, and thus I see > > > no reason to justify the likely duplicate CVE-2023-30549 as high. > > > > Now you seem to be missing the point of CVE-2023-30549. I agree that > > there's no reason to believe that CVE-2022-1184 should have been marked > > as higher impact than it was, but CVE-2023-30549 is about the extra > > impact that setuid-root apptainer (prior to 1.1.8) gives to users. > > It gives any user with a local account write access to the underlying > > bits of a filesystem, and since the filesystem can be easily corrupted > > by the user, and since CVE-2022-1184 is a memory corruption bug and not > > a simple panic, it potentially allows privilege escalation. That's why > > CVE-2023-30549 is high severity. > > Again, this is conflating scoring how difficult it is to exploit the > vulnerability with its impact. > > The impact of a vulnerability is not greater if a vulnerability is easier to > trigger. The impact portion of the score is about what happens if the > vulnerability has been triggered. > > Your argument for the higher scoring of CVE-2023-30549 than CVE-2022-1184 is > completely about the impact (confidentiality/integrity/availability) metrics. > You are suggesting that CVE-2022-1184 was incorrectly scored, and that it has > a privilege escalation impact, not just a denial of service impact. That > claim has nothing to do with the privileges required, or Apptainer having a > setuid component... which would be related to the exploitability metrics. > > If you believe it is true that CVE-2022-1184 allows privilege escalation, > then you should argue that case against CVE-2022-1184, because the extfs > issue should be graded as high severity through increased impact. If it was, > then presumaby it'd be fixed in RHEL7 because of that. Then there would be no > need for an incompatible change to Apptainer. > > DT > > > > > _______________________________________________ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org > > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
