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
> >
> > 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.
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