7.8 High
CVSS3
Attack Vector
LOCAL
Attack Complexity
LOW
Privileges Required
NONE
User Interaction
REQUIRED
Scope
UNCHANGED
Confidentiality Impact
HIGH
Integrity Impact
HIGH
Availability Impact
HIGH
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
9.3 High
CVSS2
Access Vector
NETWORK
Access Complexity
MEDIUM
Authentication
NONE
Confidentiality Impact
COMPLETE
Integrity Impact
COMPLETE
Availability Impact
COMPLETE
AV:N/AC:M/Au:N/C:C/I:C/A:C
0.001 Low
EPSS
Percentile
50.0%
A memory corruption issue was addressed with improved memory handling. This issue is fixed in iOS 15.0.2 and iPadOS 15.0.2, macOS Monterey 12.0.1, iOS 14.8.1 and iPadOS 14.8.1, tvOS 15.1, watchOS 8.1, macOS Big Sur 11.6.1. An application may be able to execute arbitrary code with kernel privileges. Apple is aware of a report that this issue may have been actively exploitedβ¦
Recent assessments:
gwillcox-r7 at October 12, 2021 3:36pm UTC reported:
Public analysis of this vulnerability is available along with an initial PoC at <https://saaramar.github.io/IOMFB_integer_overflow_poc/>. The bug appears to be a bug in IOMobileFrameBuffer/AppleCLCD which was exploited in the wild. This attack surface is accessible from sandboxes which means that it was likely combined with another vulnerability such as a WebKit vulnerability in the wild to form a complete chain and gain kernel level access. However no information is available from what I can tell on what other vulnerability might have been used in the in the wild exploit chain.
To be more specific the patch appears to affect IOMFB::TableCompensator::BilerpGainTable::new_from_data()
and some related new_from_data
type functions that attempt to allocate a buffer that is used to store table content sent by the user. However most of the operands are fully controlled by the user and the calculation of the buffer size is done in 32 bit not in 64 bits so it is easy to overflow or underflow the buffer size calculation.
Specifically the vulnerable line within the IOMFB::TableCompensator::BilerpGainTable::new_from_data()
function was v_chunk = kalloc_ext((unsigned int)(12 * v15 * v14 + 4 * (v14 + a3)));
which appears to be casting a result to a unsigned 32 bit integer, when the variable v14
is of size int64
, v15
is a int
that is directly controlled by the attacker, and a3
is another int
also controlled by the attacker. By passing this line certain sizes an attacker could cause kalloc_ext
to allocate a undersized buffer which can then be overflowed when data is later copied to it, resulting in a heap overflow in the iOS kernel, which if successfully exploited, would grant the attacker kernel level privileges.
Whilst there is no full exploit out right now, the common opinion in the community is given the evidence of exploitation in the wild and the fact that an existing PoC already exists, it is likely just a matter of time and researcherβs efforts before this vulnerability is made into a public working exploit by some developer. Definitely patch this one if your organization runs iOS devices or if jailbroken iPhones are a concern to your organization, though realize it will likely take some time before a fully working exploit is released to the public.
Assessed Attacker Value: 4
Assessed Attacker Value: 4Assessed Attacker Value: 3
7.8 High
CVSS3
Attack Vector
LOCAL
Attack Complexity
LOW
Privileges Required
NONE
User Interaction
REQUIRED
Scope
UNCHANGED
Confidentiality Impact
HIGH
Integrity Impact
HIGH
Availability Impact
HIGH
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
9.3 High
CVSS2
Access Vector
NETWORK
Access Complexity
MEDIUM
Authentication
NONE
Confidentiality Impact
COMPLETE
Integrity Impact
COMPLETE
Availability Impact
COMPLETE
AV:N/AC:M/Au:N/C:C/I:C/A:C
0.001 Low
EPSS
Percentile
50.0%