The NVD analysis at
https://nvd.nist.gov/vuln/detail/CVE-2023-30549
is now finished and they agreed with the impact score that I gave it. They
ended up with an even higher rating because they said the attack complexity was
low. I think the complexity is high, but in either case the overall severity
is rated High.
Dave
On Thu, May 04, 2023 at 10:17:42AM -0500, Dave Dykstra wrote:
> 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
