Re: Kernel vulnerabilities CVE-2021-33630 & CVE-2021-33631

                							

                <!--X-Body-Begin-->
<!--X-User-Header-->

oss-sec
mailing list archives
<!--X-User-Header-End-->
<!--X-TopPNI-->

By Date

By Thread

</form>

<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
Re: Kernel vulnerabilities CVE-2021-33630 &amp; CVE-2021-33631

<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->

From: Demi Marie Obenour &lt;demi () invisiblethingslab com&gt;

Date: Fri, 2 Feb 2024 18:19:18 -0500

<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->

<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
On Fri, Feb 02, 2024 at 01:24:58PM -0800, Roxana Bradescu wrote:

On Jan 30, 2024, at 4:56 PM, Demi Marie Obenour &lt;demi () invisiblethingslab com&gt; wrote:

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.

ChromeOS Security here, and this is correct.

Good to know, thanks!

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.

Vulnerabilities can be reported to ChromeOS and Android via https://bughunters.google.com
If any questions, can reach out to chromeos-security () chromium org 

Thank you!  I don’t have any to report right now, but I will report any
I do come across.

Could this be documented somehow, so that people know to send reports
against f2fs and ext4 to those who will actually fix them?

We will document something on the ChromeOS side. Thanks for flagging this!

You’re welcome!  Would it be possible for ChromeOS Security to take
responsibility for triaging (and, if the problem is security related,
fixing) ext4 syzbot reports?  My understanding is that this would
address the main complaint of the ext4 maintainers, which is work
required to deal with bug reports that are not from end users.  The
same applies with f2fs and Android Security.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
Attachment:
signature.asc
Description: 

<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->

<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->

By Date

By Thread

Current thread:

FWD: Kernel vulnerabilities CVE-2021-33630 &amp; CVE-2021-33631 Armin Kuster (Jan 30)

Re: FWD: Kernel vulnerabilities CVE-2021-33630 &amp; CVE-2021-33631 Solar Designer (Jan 30)

Re: FWD: Kernel vulnerabilities CVE-2021-33630 &amp; CVE-2021-33631 Greg KH (Jan 30)

Re: FWD: Kernel vulnerabilities CVE-2021-33630 &amp; CVE-2021-33631 Solar Designer (Jan 30)
Re: FWD: Kernel vulnerabilities CVE-2021-33630 &amp; CVE-2021-33631 Greg KH (Jan 30)
Re: FWD: Kernel vulnerabilities CVE-2021-33630 &amp; CVE-2021-33631 Demi Marie Obenour (Jan 31)
Re: Kernel vulnerabilities CVE-2021-33630 &amp; CVE-2021-33631 Roxana Bradescu (Feb 02)
Re: Kernel vulnerabilities CVE-2021-33630 &amp; CVE-2021-33631 Demi Marie Obenour (Feb 02)

Re: FWD: Kernel vulnerabilities CVE-2021-33630 &amp; CVE-2021-33631 Thadeu Lima de Souza Cascardo (Jan 31)

Re: FWD: Kernel vulnerabilities CVE-2021-33630 &amp; CVE-2021-33631 Armin Kuster (Feb 02)

<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->