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