On Thu, Apr 27, 2023 at 12:00:47PM +0100, David Trudgian wrote: > On Thu, Apr 27, 2023, at 8:11 AM, 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? > > My read of privileges required 'low' on CVE-2022-1184 is that perhaps > it is related to the situation where, although a direct `mount` > command against an extfs filesystem usually requires root, it is > common that a non-root user can initiate mounts of extfs USB drives > etc in 'standard' distro configurations via udisks2. I could be way > off here, but at least on desktop systems there's usually a way for a > non-root user to mount extfs removable drives. It's possible that's what they meant, but as the already referenced article https://lwn.net/Articles/652468/ makes clear, security experts do not worry about that case because it requires physical access to the machine. That's another type of privilege, and there are countless ways for such a user to get root access. > With respect to CVE-2023-30549 scoring, we're going to have quite a > bit of confusion arising from the fact that the CNA suggested score at > the NVD listing is different than on the GitHub GHSA page... > > On https://nvd.nist.gov/vuln/detail/CVE-2023-30549 the CNA provided > vector is CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H > > This results in a higher score than CVE-2022-1184 because it lists > 'Privileges Required: None' .... which is surely incorrect, as you > have to have a user account with enough privileges to run apptainer? That's odd. It only makes a .1 diference in any case, and doesn't change the high severity rating. > On https://github.com/apptainer/apptainer/security/advisories/GHSA-j4rf-7357-f4cg > the vector is CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H > > So... at the GHSA page, the Privleges Required is low (which seems > correct), but compared to CVE-2022-1184: > > 1) attack complexity is now high... which seems odd to change. I think that was because they had a low complexity way to cause denial of service. It's high complexity to do privilege escalation. The ext4 kernel developer was confident that a kernel security expert could cause any use-after-free vulnerability into a privilege escalation, and that's why I set this to be high complexity. > 2) the suggested scoring has bumped Confidentiality and Integrity > impact to 'high', where they are both 'none' in the underlying > CVE-2022-1184. Not clear how this can be correct when CVE-2022-1184 is > a denial of service vuln. That's because of the potential privilege escalation. I based the individual property settings on CVE-2023-0386 which was a low complexity privilege escalation. Red Hat rated that high complexity, which I think was another mistake because I was able to easily reproduce the exploit on a pre-patched kernel. > I'm quite confused looking at this now. I don't know how the GitHub > submited CNA suggest score at the NVD would differ from the score on > the GitHub Security Advisory. Was the scoring on the GHSA edited after > publication, after it had been sent to the NVD? Oh, you're on to something. I did change those settings after the initial creation, after I learned about CVE-2023-0386, but it was before publication. I don't know how to get that corrected, but I will try. > Also, I don't know what the justification is on the GHSA for bumping > confidentiality / integrity impact, nor changing complexity from low > -> high versus CVE-2022-1184. Explained above. Dave _______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
