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 < [email protected]> 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 > > > > > <[email protected]> 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 -- [email protected] > > > To unsubscribe send an email to > [email protected] > > > 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/[email protected] > > > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > > > _______________________________________________ > epel-devel mailing list -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected] > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue >
_______________________________________________ epel-devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
