That makes it more clear for epel7.
But it will be strange for epel7 to have a higher version than epel8 and 9.
Would the apptainer maintainers be willing to create an update that has the
--userns option, as well as the original option?
Then for epel7 the rpm's would have the original option turned off, but for
epel8 and 9 the option could be there and update wouldn't be a breaking
update.
That would allow users that have machines on RHEL 7,8 and 9 to use the same
version and secure options.
Users that only have machines on RHEL 8 and 9, would then have the option
to move to the more secure option when the time is good for them.
Troy
On Fri, May 5, 2023 at 3:30 PM Dave Dykstra via epel-devel <
epel-devel(a)lists.fedoraproject.org> wrote:
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(a)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(a)lists.fedoraproject.org
> > To unsubscribe send an email to
epel-devel-leave(a)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.fedoraproj...
> > Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
>
_______________________________________________
epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
To unsubscribe send an email to epel-devel-leave(a)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.fedoraproj...
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue