[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 30 Jan 2024 19:56:15 -0500
From: Demi Marie Obenour <demi@...isiblethingslab.com>
To: oss-security@...ts.openwall.com
Subject: Re: FWD: Kernel vulnerabilities CVE-2021-33630 &
CVE-2021-33631
On Tue, Jan 30, 2024 at 03:01:24PM -0800, Greg KH wrote:
> On Tue, Jan 30, 2024 at 10:45:00PM +0100, Solar Designer wrote:
> > Thank you Greg for looking into these issues. It's great that most
> > longterm kernel trees appear already fixed.
>
> I've taken the one remaining missing fix into the next round of kernel
> releases, so all should be good now.
>
> > For CVE-2021-33631 (the ext4 BUG), both the distro vendor's and NVD's
> > CVSS input vectors specify AV:L/AC:L/PR:L/UI:N, which means the
> > vulnerability can be triggered by a local system user at will and
> > without additional privileges. I'd say that deliberately getting the
> > kernel to work on a corrupted filesystem requires at least one of:
> > physical access (AV:P) or privileges on the system (PR:H) or user
> > interaction (UI:R). However, there's no way to encode this in one CVSS
> > vector. Also, in the physical access case, at least the availability
> > impact typically does not apply (would be A:N).
>
> The "interesting" thing here is that the project in question (the
> kernel) does not consider "mounting a corrupted filesystem" as a real
> attack vector at all. There's been long discussions about it, the most
> recent being last year on the kernel summit discuss mailing list, and at
> the kernel summit itself.
The kernel itself does not, but there are downstreams of the kernel that
do for at least a subset of filesystems. These include Android and
Chromium OS.
> So while CVSS might consider this a real issue, the developers of the
> project itself do not. The disconnect is one that drives people who use
> sysbot tools to create fancy corrupted filesystem images with the goal
> of getting a CVE for their CV, crazy on a weekly basis when the issues
> they report get constantly ignored.
If someone finds a vulnerability in F2FS or ext4 that can be used to
compromise the kernel by crafting a malicious filesystem, they should
report it to the Android or Chromium OS security teams, respectively.
It’s a verified boot bypass and I expect that it would be in scope for
the respective bounty programs. If Android mounts FAT and exFAT in the
kernel, then vulnerabilities in these filesystems should be reported to
the Android security team.
Google requires that F2FS and ext4 are secure against malicious
filesystem images, so they should be the ones responsible for fixing any
vulnerabilities that require a malicious filesystem image to trigger.
Fortunately, they have the resources to do that, so this should not be a
problem for them.
Could this be documented somehow, so that people know to send reports
against f2fs and ext4 to those who will actually fix them?
--
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
